This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
RE: Committed, libc/machine/cris/libcdtor.c (defaultors): Markartificially as used
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Dave Korn <dave dot korn at artimi dot com>
- Cc: newlib at sourceware dot org
- Date: Wed, 27 Jul 2005 16:02:55 -0400 (EDT)
- Subject: RE: Committed, libc/machine/cris/libcdtor.c (defaultors): Markartificially as used
- References: <SERRANOFwzyHRUMytZ900000776@SERRANO.CAM.ARTIMI.COM>
On Wed, 27 Jul 2005, Dave Korn wrote:
> ----Original Message----
> >From: Hans-Peter Nilsson
> >Sent: 26 July 2005 21:55
>
> > Sorry for not looking into the possible GCC bug at this time;
> > I'm not sure if the code is supposed to be valid actually.
> > It's playing tricks and alias support has changed a bit in GCC;
> > being more strict for some definition of strict. GCC removing
> > defaultors breaks the build and that's what matters right now.
>
>
> It's an issue I've run into myself with static data tables that aren't
> directly referenced anywhere in the program code and garbage-collecting
> links. FWIW I think gcc is entirely within its rights to not emit
> unreferenced static const objects when optimisation is on. It should
> qualify under the as-if rule, shouldn't it? I can't see any way that a
> program could detect (and thus vary its behaviour according to) the presence
> or absence of an unreferenced static const object, without playing some sort
> of nasty pointer games that would technically mean undefined behaviour.
It's already explicitly referenced through a GCC extension -- as
a weak alias for the variables __CTOR_LIST__ and __DTOR_LIST__.
See the last line in the patch.
I'm leaning more and more towards the worked-around behavior
being a GCC bug.
brgds, H-P