This is the mail archive of the
mailing list for the GCC project.
Re: glibc broken with 3.4...
- From: Jan Hubicka <jh at suse dot cz>
- To: Richard Henderson <rth at redhat dot com>, Jan Hubicka <jh at suse dot cz>,Jan Hubicka <hubicka at ucw dot cz>, Andreas Jaeger <aj at suse dot de>,gcc at gcc dot gnu dot org, zack at codesourcery dot com, geoffk at apple dot com
- Date: Sun, 7 Sep 2003 23:59:16 +0200
- Subject: Re: glibc broken with 3.4...
- References: <20030906185819.GA1599@kam.mff.cuni.cz> <firstname.lastname@example.org> <20030907110551.GL1599@kam.mff.cuni.cz> <email@example.com> <20030907124924.GB14387@kam.mff.cuni.cz> <firstname.lastname@example.org> <20030907135829.GD14387@kam.mff.cuni.cz> <20030907191453.GB14325@redhat.com> <20030907203821.GO14387@kam.mff.cuni.cz> <20030907213208.GB14431@redhat.com>
> On Sun, Sep 07, 2003 at 10:38:21PM +0200, Jan Hubicka wrote:
> > This is what is done in glibc. This would be acceptable, but __typeof
> > (__isinf) counts as used so error fires.
> Ug. I've no idea what to do about this, except to somehow note that
> sizeof, typeof, alignof doesn't actually use the assembler level symbol
> at all. That's pretty sketchy though, cause I'm sure that folks will
> say the same thinga bout __builtin_constant_p or anything else that
> doesn't really depend on some bits of metadata associated with a symbol.
One can do test whether cgraph node has been already created. That
notion of use is extremly lazy and will avoid the problem with updating
hashtables, however it is very implementation specific and will likely
change in future so I am not sure it is good choice.
It also still haves problem with difining body of extern inline function
being an "use" (or use in different extern inline function) and that is
precisely what glibc does.
Perhaps we can go with updating the hashtables and allowing the renaming
after all, but that is nasty as well... (tought I think I got it working
right on hammer branch)
> For C++ I'm sure that it still needs to be a "use" of some sort, since
> it'll require templates to be instantiated, etc.