This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C++ problem


On 28 Nov 1998, Alexandre Oliva wrote:

> On Nov 28, 1998, teunis <teunis@computersupportcentre.com> wrote:
> 
> > On 25 Nov 1998, Alexandre Oliva wrote:
> 
> >> That's the point.  You modified what egcs took as the first non-inline 
> >> non-abstract member function.
> 
> > This doesn't make any sense.
> > Unless someone gives me a good reason for why this is breaking I'd
> > consider it a bug... REGARDLESS of workaround.
> 
> I bet your program doesn't provide a definition for every non-inline
> non-abstract virtual member function.  This is explicitly required in
> the C++ Standard, and that's why this optimization made by gcc is
> correct. 

Nope - I -do-!!!!

This is why I consider it a bug.

again, egcs-2.92.23; glibc-2.0.7; binutils-2.9.1; linux-2.1.125+ (up to
.130 source now)

[update for those who missed. I'm having problem with -sometimes- a
compiler erroring out on a constructor that's placed at the beginning of a
class definition.  It's never in a class with undefined virtual functions
FWIW.  A workaround is to move the constructor definition to the end of
the class description.  IMHO this isn't as attractive...  (and non-obvious
too - it had me stopped for a week trying to figure it out).
All classes in question -do- contain virtual functions, just no pure
virtual ones.

> > I've managed to trigger a few other cute ones too...  creating a string
> > from a function
> > 	(ie string(typeid(object).name)
> > causes an internal compile error...  Now this -is- an error so... 
> 
> Yep, if you submit a bug report about this one *to the list*, I (or
> someone else) will take a look at it.  This problem is probably fixed
> in recent development snapshots (unrelated from the 1.1 branch), so
> you may want to give them a try before reporting the bug.

This -is- a recent devel snapshot. (1998-11-09)

> BTW, you probably know typeid::name is a member function, so you need
> parens to invoke it.

Yep.  Means it should provide an informative error message rather than an
"internal compiler error" though. Could cause future crashes.

> > oh, binutils 980325 ... could this be my problem?
> 
> Quite old, it might cause problems with exception handling.

Updated, no change.
Unless 2.9.1 is still old... it's the newest on ftp.gnu.org...

G'day, eh? :)
	- Teunis

PS: anything more needed?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]