Re: MIPS C++ bug

[<gp at qnx dot com>]

Thanks all.  I been told.  :-)

Appreciate the info, as always.  I will check the original testcase to make 
sure I did not invalidate it by stripping it down for posting.  I'm pretty 
sure that there were no global declarations for const int SomeCls::DEF_INST; 
anywhere.

Since the optionally-correct code is allowed for mips with -O0 (and -G0), are 
the other optimization levels misbehaving, or is -O0 right?  I think this is 
what Daniel was getting at.  

All other targets I could test allow it, and sometimes mips allows it.  
Looked at that way, it does seem like the mips optimizations are out of line.

Cheers.
GP

Daniel Jacobowitz <drow@mvista.com> said:

> On Tue, Jun 17, 2003 at 09:56:40PM -0400, Kris Warkentin wrote:
> > > On Jun 17, 2003, <gp@qnx.com> wrote:
> > >
> > > >   ./libsomelib.so: undefined reference to `SomeCls::DEF_INST'
> > >
> > > I'm afraid your program is in error.  Even though SomeCls::DEF_INST is
> > > a public static const int, initialized in place, a global definition
> > > of every static data member is still mandatory.  In case the
> > > initializer in the declaration is given, the definition must not have
> > > an initializer.  I.e., add to one of your translation units the
> > > following line:
> > >
> > >   const int SomeCls::DEF_INST;
> > >
> > > and your program will be well-formed C++ per the current C++ Standard,
> > > and, as a bonus, will likely link correctly too :-)
> > 
> > That's very interesting but then it implies that the mips toolchain is the
> > only one which is correct since this code works fine on all the others.
> > Isn't mips being correct when all the others are wrong one of the signs of
> > the coming apocalypse? *looks up at sky*
> 
> Sounds like an optimization deficiency; I believe the program is
> allowed, but not required, to fail to compile.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 



--