This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Committed, libc/machine/cris/libcdtor.c (defaultors): Markartificially as used


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


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