This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ problem
- To: egcs at cygnus dot com, Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Subject: Re: C++ problem
- From: teunis <teunis at computersupportcentre dot com>
- Date: Wed, 9 Dec 1998 02:18:02 -0700 (MST)
- Reply-To: teunis <teunis at computersupportcentre dot com>
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?