From:	mrs AT wrs DOT com (Mike Stump)
Subject:	Re: b20: c++ bug or feature?
20 Nov 1998 11:09:42 -0800 :
Message-ID:	<199811200058.QAA27142.cygnus.gnu-win32@kankakee.wrs.com>
To:	khan AT xraylith DOT wisc DOT edu, lka AT physic DOT ut DOT ee
Cc:	egcs AT cygnus DOT com, gnu-win32 AT cygnus DOT com

> To: Andres Heinloo <lka AT physic DOT ut DOT ee>
> Cc: gnu-win32 AT cygnus DOT com, egcs AT cygnus DOT com
> Date: Wed, 18 Nov 1998 13:53:29 -0600
> From: Mumit Khan <khan AT xraylith DOT wisc DOT edu>

> > OhharaDraw.h:130: sorry, not implemented: object size exceeds normal limit
> > for virtual function table implementation, recompile all source and use
> > -fhuge-objects

> [ I'm copying egcs as well. Hopefully egcs C++ folks will provide some
>   insight into this ]

> The hierarchy looks like this:
>   
> Any target platform that does not use vtable "thunks" is affected by this. 
> For example, HPUX is as affected by it as ix86-win32. ix86-linux uses
> vtable thunks by default, so it works there.

> Solutions? 

> (1) Recompile *everything* with -fvtable-thunks. I don't know if it works
>     for x86-win32 targets.
> (2) Recompile *everything* with -fhuge-objects. Hardly an option for real
>     life code. Also, I don't know how well debugged -fhuge-objects really
>     is, so you might be running into other compiler/library bugs there.

There are 0 known bugs with it.  Last I knew, it worked well.  If
people really don't like the 32K limitation, this is the `right'
solution.

4)  Learn to use new/malloc instead of having tons of stuff in an
    object, learn to make objects smaller.  45K objects seem rather
    large to me.  Show us your code and defend the size, the other
    other person to ever hit this that I know of had very large data
    arrays in their objects that I took one look at and thought to
    myself, boy I wonder just how many static limits on things his
    code has.

But otherwise, your solution list is pretty good.


As to wether this is a bug or feature.  I'd call it a documented
limitation of the compiler.  If you don't like it, change the 0 to a 1
on int huge_objects; and recompile and reinstall the compiler.  We
probably don't want to change the egcs version like this as there is a
size win (and speed win as well?) with the limitation, and in
practice, no one has good code that exceeds this limitation.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -