This is the mail archive of the
mailing list for the glibc project.
Re: gcc bug impacts glibc cvs
- To: drepper at cygnus dot com (Ulrich Drepper)
- Subject: Re: gcc bug impacts glibc cvs
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Mon, 12 Mar 2001 21:01:32 +0100
- Cc: Jack Howarth <howarth at bromo dot med dot uc dot edu>,libc-alpha at sources dot redhat dot com
- References: <Franz Sirl's message of "Mon, 12 Mar 2001 19:52:25 +0100"><Jack Howarth's message of "Mon, 12 Mar 2001 04:02:55 -0800 (PST)"><200103121202.EAA31792@bromo.med.uc.edu><email@example.com>
At 20:06 12.03.2001, Ulrich Drepper wrote:
>Franz Sirl <Franz.Sirlfirstname.lastname@example.org> writes:
> > Well, currently this test is quite simple, every GCC does it
> > potentially wrong so far. Maybe a fix can go into gcc-3.0, but most
> > probably it won't be in gcc-2.95.3.
>On x86 the problem seems not to appear:
>extern void *xyzzy __attribute__ ((__weak__));
> return &xyzzy ? (xyzzy == (void *) 0) : 0;
>This succeeds with -O0, -O1, -O2, -O3. Therefore I do not want a
>work-around to go into glibc unconditionally.
For a small testcase this succeeds, but there is _absolutely no_ guarantee
that it will work under all conditions in all GCC's up to date and on all
platforms, simply because currently GCC has _no_ idea internally about weak
symbols, there are handled like every other symbol reference. And thus GCC
assumes that it can always dereference it (and GCC optimizes accordingly),
which is not true in practice for a weak symbol reference. It might very
well be that someone changes optimizations for x86 in the next weeks before
gcc-3.0 and suddenly your testcase will fail for x86 too. How will you
handle that case then?
IMHO the only safe thing to do is to incorporate some kind of workaround
and unconditionally enable it until GCC is fixed, everthing else is just
depending on pure luck.