Re: Miscompilation of glibc with CVS mainline

Re: Miscompilation of glibc with CVS mainline

[Robert Dewar]

> Note that the *only* way to subvert this scheme is to use
> inline assembly to force the symbol weak behind gcc's back.
> All I can say here is "Don't Do That".

OK, that seems reasonable to me, and I withdraw my suggestion that a change
is required here :-)

Re: Miscompilation of glibc with CVS mainline

[Robert Dewar]

> If you think about when the "optimization" can be used, it is very
> questionable at best whether it's useful.  Why would anybody add a test
> for a function reference being NULL without the possibility of this
> being the case?  For this reason and the history of code like this gcc
> should never remove the tests and the old behavior should be restored.

One of the most important pieces of documentation is what you did not do
and why you did not do it :-)

In this case, when the optimization is removed (I agree it should be), then
in its place a comment saying why it is not done (perhaps even leaving the
undesirable code commented out) would be helpful to stop people doing this
again!

Re: Miscompilation of glibc with CVS mainline

[John David Anglin]

> > > Here's a small testcase that has the same behaviour:
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > extern void weak_func (void *arg);
> > > asm (".weak weak_func");
> > > 
> > > void
> > > test (void *arg)
> > > {
> > >   if (&weak_func != (void *)0)
> > >     weak_func (arg);
> > >   
> > > }
> > 
> > As GCC is not told in any way that weak_func is actually weak, I think
> > it is glibc's fault.
> 
> This is definitely a gcc problem.  This is the code arising from
> Andreas' testcase for hppa-linux at -O2:
> 
>         stw %r2,-20(%r30)
> 	ldo 64(%r30),%r30
> 	ldw -84(%r30),%r2
> 	bl weak_func,%r0
> 	ldo -64(%r30),%r30
> 
> We have completely lost the `if'.  As a result, weak_func is always
> called.

There is another problem.  The call to weak_func has been turned into
a sibcall.  It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
consulted as we don't allow indirect sibcalls on hppa-linux.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Miscompilation of glibc with CVS mainline

[Jakub Jelinek]

On Thu, Jan 02, 2003 at 12:48:23PM -0500, John David Anglin wrote:
> There is another problem.  The call to weak_func has been turned into
> a sibcall.  It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
> consulted as we don't allow indirect sibcalls on hppa-linux.

The call is not indirect, it is normal direct call
(even if weak_func is marked __attribute__((weak)) or #pragma weak).

	Jakub

Re: Miscompilation of glibc with CVS mainline

[John David Anglin]

> The call is not indirect, it is normal direct call
> (even if weak_func is marked __attribute__((weak)) or #pragma weak).

Sorry, for the net garbage.  My original analysis of the glibc problem
involved an indirect call.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Miscompilation of glibc with CVS mainline

[Daniel Jacobowitz]

On Thu, Jan 02, 2003 at 12:48:23PM -0500, John David Anglin wrote:
> > > > Here's a small testcase that has the same behaviour:
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > extern void weak_func (void *arg);
> > > > asm (".weak weak_func");
> > > > 
> > > > void
> > > > test (void *arg)
> > > > {
> > > >   if (&weak_func != (void *)0)
> > > >     weak_func (arg);
> > > >   
> > > > }
> > > 
> > > As GCC is not told in any way that weak_func is actually weak, I think
> > > it is glibc's fault.
> > 
> > This is definitely a gcc problem.  This is the code arising from
> > Andreas' testcase for hppa-linux at -O2:
> > 
> >         stw %r2,-20(%r30)
> > 	ldo 64(%r30),%r30
> > 	ldw -84(%r30),%r2
> > 	bl weak_func,%r0
> > 	ldo -64(%r30),%r30
> > 
> > We have completely lost the `if'.  As a result, weak_func is always
> > called.
> 
> There is another problem.  The call to weak_func has been turned into
> a sibcall.  It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
> consulted as we don't allow indirect sibcalls on hppa-linux.

This isn't an indirect call, though.  weak_func is not a pointer...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Miscompilation of glibc with CVS mainline

[John David Anglin]

> CPP='/opt/gcc/3.3-devel/bin/gcc -E -x c-header'  /builds/glibc/test-libc/elf/ld-linux.so.2 --library-path /builds/glibc/test-libc:/builds/glibc/test-libc/math:/builds/glibc/test-libc/elf:/builds/glibc/test-libc/dlfcn:/builds/glibc/test-libc/nss:/builds/glibc/test-libc/nis:/builds/glibc/test-libc/rt:/builds/glibc/test-libc/resolv:/builds/glibc/test-libc/crypt:/builds/glibc/test-libc/linuxthreads /builds/glibc/test-libc/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /builds/glibc/test-libc/sunrpc/xbootparam_prot.T
> make[2]: *** [/builds/glibc/test-libc/sunrpc/xbootparam_prot.stmp] Segmentation fault
> make[2]: Leaving directory `/cvs/libc/sunrpc'

I hit what appears to be the same error trying to build glibc-2.3.1 on
hppa-linux.  It's hard to debug because the segmentation fault occurs in
a shared library without any debug symbols.  In my particular case, it
seemed as if the code was trying to call an undefined weak (indirect
call to function at address 0x0).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Miscompilation of glibc with CVS mainline

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 3720 bytes --]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

> Andreas Jaeger wrote:
>> GCC CVS mainline miscompiles glibc on i686-linux-gnu.  The actual
>> error I noticed is:

>> CPP='/opt/gcc/3.3-devel/bin/gcc -E -x c-header'  /builds/glibc/test-libc/elf/ld-linux.so.2 --library-path /builds/glibc/test-libc:/builds/glibc/test-libc/math:/builds/glibc/test-libc/elf:/builds/glibc/test-libc/dlfcn:/builds/glibc/test-libc/nss:/builds/glibc/test-libc/nis:/builds/glibc/test-libc/rt:/builds/glibc/test-libc/resolv:/builds/glibc/test-libc/crypt:/builds/glibc/test-libc/linuxthreads /builds/glibc/test-libc/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /builds/glibc/test-libc/sunrpc/xbootparam_prot.T
>> make[2]: *** [/builds/glibc/test-libc/sunrpc/xbootparam_prot.stmp] Segmentation fault
>> make[2]: Leaving directory `/cvs/libc/sunrpc'
>
> I hit what appears to be the same error trying to build glibc-2.3.1 on
> hppa-linux.  It's hard to debug because the segmentation fault occurs in
> a shared library without any debug symbols.  In my particular case, it
> seemed as if the code was trying to call an undefined weak (indirect
> call to function at address 0x0).

I could reproduce this with a simple hello-world program and also with
some smaller program, it is indeed a bug in handling of weak extern
functions.

Here's a small testcase that has the same behaviour:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
extern void weak_func (void *arg);
asm (".weak weak_func");

void
test (void *arg)
{
  if (&weak_func != (void *)0)
    weak_func (arg);
  
}

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Is compiled correctly with GCC 3.3 CVS but with GCC 3.4 the test for
NULL is removed:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arthur:~/tmp:[0]$ /opt/gcc/3.3-devel/bin/gcc -O2 -c weak.c 
arthur:~/tmp:[0]$ objdump -Dr weak.o 

weak.o:     file format elf32-i386

Disassembly of section .text:

00000000 <test>:
   0:   55                      push   %ebp
   1:   b8 00 00 00 00          mov    $0x0,%eax
                        2: R_386_32     weak_func
   6:   85 c0                   test   %eax,%eax
   8:   89 e5                   mov    %esp,%ebp
   a:   74 06                   je     12 <test+0x12>
   c:   5d                      pop    %ebp
   d:   e9 fc ff ff ff          jmp    e <test+0xe>
                        e: R_386_PC32   weak_func
  12:   5d                      pop    %ebp
  13:   c3                      ret    
Disassembly of section .data:
arthur:~/tmp:[0]$ /opt/gcc/3.4-devel/bin/gcc -O2 -c weak.c 
arthur:~/tmp:[0]$ objdump -Dr weak.o 

weak.o:     file format elf32-i386

Disassembly of section .text:

00000000 <test>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   5d                      pop    %ebp
   4:   e9 fc ff ff ff          jmp    5 <test+0x5>
                        5: R_386_PC32   weak_func
Disassembly of section .data:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If I change this line:
asm (".weak weak_func");

to 
#pragma weak weak_func
, GCC 3.4 compiles this correctly with the test for NULL.

This one seems to be fine also:
extern void weak_func (void *arg) __attribute ((weak));

GCC changed existing behaviour and miscompiles code that worked before
for ages.

So, how should this miscompilation get fixed? Is this a bug in glibc
or an overoptimizing GCC?

I've CC'ed the libc-alpha list,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Miscompilation of glibc with CVS mainline

[Jakub Jelinek]

On Thu, Jan 02, 2003 at 02:16:01PM +0100, Andreas Jaeger wrote:
> I could reproduce this with a simple hello-world program and also with
> some smaller program, it is indeed a bug in handling of weak extern
> functions.
> 
> Here's a small testcase that has the same behaviour:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> extern void weak_func (void *arg);
> asm (".weak weak_func");
> 
> void
> test (void *arg)
> {
>   if (&weak_func != (void *)0)
>     weak_func (arg);
>   
> }

As GCC is not told in any way that weak_func is actually weak, I think
it is glibc's fault.
Does:
#define weak_extern(x) extern __typeof (x) x __attribute__((weak));
work ok?

	Jakub

Re: Miscompilation of glibc with CVS mainline

[Andreas Jaeger]

Jakub Jelinek <jakub@redhat.com> writes:

> On Thu, Jan 02, 2003 at 02:16:01PM +0100, Andreas Jaeger wrote:
>> I could reproduce this with a simple hello-world program and also with
>> some smaller program, it is indeed a bug in handling of weak extern
>> functions.
>> 
>> Here's a small testcase that has the same behaviour:
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> extern void weak_func (void *arg);
>> asm (".weak weak_func");
>> 
>> void
>> test (void *arg)
>> {
>>   if (&weak_func != (void *)0)
>>     weak_func (arg);
>>   
>> }
>
> As GCC is not told in any way that weak_func is actually weak, I think
> it is glibc's fault.
> Does:
> #define weak_extern(x) extern __typeof (x) x __attribute__((weak));
> work ok?

I'm playing now with:
#    define __pragma_weak(expr) _Pragma(#expr)
#    define _weak_extern(symbol) __pragma_weak("weak " #symbol)

And this works with my small testcase and I've just started
recompiling glibc with it.

I'll try your definition also and let you know about the results,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Miscompilation of glibc with CVS mainline

[Andreas Jaeger]

Andreas Jaeger <aj@suse.de> writes:

> Jakub Jelinek <jakub@redhat.com> writes:
>
>> On Thu, Jan 02, 2003 at 02:16:01PM +0100, Andreas Jaeger wrote:
>>> I could reproduce this with a simple hello-world program and also with
>>> some smaller program, it is indeed a bug in handling of weak extern
>>> functions.
>>> 
>>> Here's a small testcase that has the same behaviour:
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> extern void weak_func (void *arg);
>>> asm (".weak weak_func");
>>> 
>>> void
>>> test (void *arg)
>>> {
>>>   if (&weak_func != (void *)0)
>>>     weak_func (arg);
>>>   
>>> }
>>
>> As GCC is not told in any way that weak_func is actually weak, I think
>> it is glibc's fault.
>> Does:
>> #define weak_extern(x) extern __typeof (x) x __attribute__((weak));
>> work ok?
>
> I'm playing now with:
> #    define __pragma_weak(expr) _Pragma(#expr)
> #    define _weak_extern(symbol) __pragma_weak("weak " #symbol)
>
> And this works with my small testcase and I've just started
> recompiling glibc with it.

Unfortunately my solution didn't work out, it gave a number of these
warnings:

In file included from ../sysdeps/generic/abort.c:19:
../linuxthreads/sysdeps/pthread/bits/libc-lock.h:312: warning: ignoring #pragma "weak " 
../linuxthreads/sysdeps/pthread/bits/libc-lock.h:313: warning: ignoring #pragma "weak " 


> I'll try your definition also and let you know about the results,

With your change in, it looked better but I had to disable the alias
for res_init to fix compilation:

res_libc.c:95: error: weak declaration of `__res_init_weak' must precede defininition
make[2]: *** [/builds/glibc/main-gcc3.4/resolv/res_libc.os] Error 1

And add declarations in libc-tsd.h.  With these changes everything
compiled but running the testsuite failed directly:

make[2]: *** [/builds/glibc/main-gcc3.4/iconv/tst-iconv1.out] Error 139

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Miscompilation of glibc with CVS mainline

[Andreas Jaeger]

Andreas Jaeger <aj@suse.de> writes:

> Andreas Jaeger <aj@suse.de> writes:
>
>> Jakub Jelinek <jakub@redhat.com> writes:
>> [...]
>>> Does:
>>> #define weak_extern(x) extern __typeof (x) x __attribute__((weak));
>>> work ok?
> [...]
> With your change in, it looked better but I had to disable the alias
> for res_init to fix compilation:
>
> res_libc.c:95: error: weak declaration of `__res_init_weak' must precede defininition
> make[2]: *** [/builds/glibc/main-gcc3.4/resolv/res_libc.os] Error 1
>
> And add declarations in libc-tsd.h.  With these changes everything
> compiled but running the testsuite failed directly:
>
> make[2]: *** [/builds/glibc/main-gcc3.4/iconv/tst-iconv1.out] Error 139

I cannot reproduce that segmentation fault.  I did a complete build
from scratch and now the testsuite passes (at least so far as I've run
it).  I'll investigate further tomorrow and try to come up with a
complete patch,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Miscompilation of glibc with CVS mainline

[John David Anglin]

> On Thu, Jan 02, 2003 at 02:16:01PM +0100, Andreas Jaeger wrote:
> > I could reproduce this with a simple hello-world program and also with
> > some smaller program, it is indeed a bug in handling of weak extern
> > functions.
> > 
> > Here's a small testcase that has the same behaviour:
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > extern void weak_func (void *arg);
> > asm (".weak weak_func");
> > 
> > void
> > test (void *arg)
> > {
> >   if (&weak_func != (void *)0)
> >     weak_func (arg);
> >   
> > }
> 
> As GCC is not told in any way that weak_func is actually weak, I think
> it is glibc's fault.

This is definitely a gcc problem.  This is the code arising from
Andreas' testcase for hppa-linux at -O2:

        stw %r2,-20(%r30)
	ldo 64(%r30),%r30
	ldw -84(%r30),%r2
	bl weak_func,%r0
	ldo -64(%r30),%r30

We have completely lost the `if'.  As a result, weak_func is always
called.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Miscompilation of glibc with CVS mainline

["Martin v. Löwis"]

John David Anglin wrote:
>>As GCC is not told in any way that weak_func is actually weak, I think
>>it is glibc's fault.
> 
> 
> This is definitely a gcc problem.  This is the code arising from
> Andreas' testcase for hppa-linux at -O2:
[...]
> We have completely lost the `if'.  As a result, weak_func is always
> called.

It's not a gcc bug. weak_func is a function, so &weak_func is always 
unequal to null - that is guaranteed by the C programming language. 
That's why the compiler is entitled to eliminate the test, under the 
as-if rule. If you want to declare a function whose address can be zero, 
you need to declare it weak, using the relevant extension in GNU C.

Regards,
Martin

Re: Miscompilation of glibc with CVS mainline

[John David Anglin]

> > We have completely lost the `if'.  As a result, weak_func is always
> > called.
> 
> It's not a gcc bug. weak_func is a function, so &weak_func is always 
> unequal to null - that is guaranteed by the C programming language. 
> That's why the compiler is entitled to eliminate the test, under the 
> as-if rule. If you want to declare a function whose address can be zero, 
> you need to declare it weak, using the relevant extension in GNU C.

I can't seem to find where the standard says &weak_func is always
unequal to null.  I thought the exact details of function
pointers were implementation defined.  If the test is changed to
use a generic function pointer, then no such assumption is made
and the comparison is kept.  The comparison is also present if
`__attribute__ ((weak))' is used.

The gcc-3.2 and 3.3 generated code have the comparison.  I'll leave
it up to the language lawyers to determine whether the current 3.4
behavior is correct.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Miscompilation of glibc with CVS mainline

[Paul Jarc]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> I can't seem to find where the standard says &weak_func is always
> unequal to null.

n869 6.3.2.3p3: "[...] the resulting pointer, called a null pointer,
is guaranteed to compare unequal to a pointer to any object or
function."


paul

Re: Miscompilation of glibc with CVS mainline

[Dale Johannesen]

On Thursday, January 2, 2003, at 10:58  AM, Paul Jarc wrote:

> "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
>> I can't seem to find where the standard says &weak_func is always
>> unequal to null.
>
> n869 6.3.2.3p3: "[...] the resulting pointer, called a null pointer,
> is guaranteed to compare unequal to a pointer to any object or
> function."

History:  the 2.95 doc had this in the "Certain Changes We Don't Want 
to Make" section:

> @item
> Assuming (for optimization) that the address of an external symbol is
> never zero.
>
> This assumption is false on certain systems when @samp{#pragma weak} is
> used.

It's not there any more.

Re: Miscompilation of glibc with CVS mainline

[John David Anglin]

> "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > I can't seem to find where the standard says &weak_func is always
> > unequal to null.
> 
> n869 6.3.2.3p3: "[...] the resulting pointer, called a null pointer,
> is guaranteed to compare unequal to a pointer to any object or
> function."

Isn't this going to cause a problem with the gcc weak extension and the
treatment of undefined weak functions in the system V ABI?  Specifically,
it would then appear that weak function pointers need to treated differently.
How can any specific code know whether a function pointer resolves to a weak
function or not when it is extern?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Miscompilation of glibc with CVS mainline

[Paul Jarc]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
>> n869 6.3.2.3p3: "[...] the resulting pointer, called a null pointer,
>> is guaranteed to compare unequal to a pointer to any object or
>> function."
>
> Isn't this going to cause a problem with the gcc weak extension

Any program that uses the weak extension is violating the standard, so
gcc is allowed to also violate the standard in a useful way in such a
case.  AIUI, the example in this thread does not use the weak
extension, despite its name, so (assuming it does not violate the
standard in other ways by using other extensions) its address must not
be null.


paul

Re: Miscompilation of glibc with CVS mainline

[Martin v. Löwis]

prj@po.cwru.edu (Paul Jarc) writes:

> > Isn't this going to cause a problem with the gcc weak extension
> 
> Any program that uses the weak extension is violating the standard, so
> gcc is allowed to also violate the standard in a useful way in such a
> case.  

More precisely, it's not a violation, it is an extension (4p8); a
conforming implementation must document what the extensions are and
must diagnose usage of extensions.

For the GCC weak extension, the relevant clause of the standard does
not apply: in a strictly conforming program, the weak extension cannot
be used. The GCC documentation fails to mention that taking the
address of a weak function may yield a null pointer; this is a
documentation bug.

Regards,
Martin

Re: Miscompilation of glibc with CVS mainline

[Richard Henderson]

On Thu, Jan 02, 2003 at 02:16:03PM -0500, John David Anglin wrote:
> How can any specific code know whether a function pointer resolves to a weak
> function or not when it is extern?

By having it properly declared.


r~

Re: Miscompilation of glibc with CVS mainline

[John David Anglin]

> On Thu, Jan 02, 2003 at 02:16:03PM -0500, John David Anglin wrote:
> > How can any specific code know whether a function pointer resolves to a weak
> > function or not when it is extern?
> 
> By having it properly declared.

Isn't it possible for both a global define and weak defines to occur
when a program is linked without incuring an error in the system V ABI?
How do you properly declare a function in cases where the symbol binding
is not determined until runtime?

I think Ulrich has a point in questioning whether the optimization is
useful.  Being able to track whether a function is weak or not at the
rtl level doesn't justify the change in gcc's behavior for gnu code.
Basically, the default in handling function pointers has changed from
gnu to iso c99.  To get the old behavior users are now forced to use
something like gcc's TARGET_ATTRIBUTE_WEAK macro.  A better approach
might have been to enable the optimization for c99 but leave the previous
treatment (all symbols assumed weak) for gnu code.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Miscompilation of glibc with CVS mainline

[Richard Henderson]

On Thu, Jan 02, 2003 at 08:02:18PM -0500, John David Anglin wrote:
> Isn't it possible for both a global define and weak defines to occur
> when a program is linked without incuring an error in the system V ABI?

Sure.

However, a strong use of a symbol *always* requires the symbol
to be defined.  If GCC sees that a symbol is used, and it is
not declared weak, then it knows that that symbol *must* be
defined.  The weakness of the definition doesn't enter into it.

> I think Ulrich has a point in questioning whether the optimization is
> useful.

On the contrary.  The optimization is *extremely* useful.
Just as useful as exposing the .hidden directives to the
compiler.

> To get the old behavior users are now forced to use
> something like gcc's TARGET_ATTRIBUTE_WEAK macro.

Yes.  IMO code that used inline assembly for this was simply broken.



r~

Re: Miscompilation of glibc with CVS mainline

[Ulrich Drepper]

John David Anglin wrote:
> I can't seem to find where the standard says &weak_func is always
> unequal to null.

Of course you cannot.  Weak functions are nothing ISO C defines.  They
are not even a universally available features which are available on all
platforms which gcc provides.


The problem here is that somebody thought s/he can be very clever and
add one more optimization without knowing the history of gcc.  We had
problems with exactly this situation several times over the last years
and always it has been the case that gcc was adjusted to *not* remove
the test.  Some documentation of this behavior was even added, somewhere.

If you think about when the "optimization" can be used, it is very
questionable at best whether it's useful.  Why would anybody add a test
for a function reference being NULL without the possibility of this
being the case?  For this reason and the history of code like this gcc
should never remove the tests and the old behavior should be restored.

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

Re: Miscompilation of glibc with CVS mainline

[Richard Henderson]

On Thu, Jan 02, 2003 at 11:42:27AM -0800, Ulrich Drepper wrote:
> The problem here is that somebody thought s/he can be very clever and
> add one more optimization without knowing the history of gcc.  We had
> problems with exactly this situation several times over the last years
> and always it has been the case that gcc was adjusted to *not* remove
> the test.

The history is not quite as you remember.

Once upon a time, GCC wasn't able to track whether or not a 
particular symbol is or is not weak at the rtl level, and
thus we had to assume that all symbols were weak.

Now it is the case that we *can* track this, and so we do.

Note that the *only* way to subvert this scheme is to use
inline assembly to force the symbol weak behind gcc's back.
All I can say here is "Don't Do That".


r~

Re: Miscompilation of glibc with CVS mainline

[Fergus Henderson]

On 02-Jan-2003, Ulrich Drepper <drepper@redhat.com> wrote:
> If you think about when the "optimization" can be used, it is very
> questionable at best whether it's useful.  Why would anybody add a test
> for a function reference being NULL without the possibility of this
> being the case?

Inlining, macros, or templates can all lead to situations where the
compiler can optimize one instance of a test, even though the programmer
could not easily make the same optimization because there may be
other instances where the test is needed.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Miscompilation of glibc with CVS mainline

[Andreas Jaeger]

GCC CVS mainline miscompiles glibc on i686-linux-gnu.  The actual
error I noticed is:
CPP='/opt/gcc/3.3-devel/bin/gcc -E -x c-header'  /builds/glibc/test-libc/elf/ld-linux.so.2 --library-path /builds/glibc/test-libc:/builds/glibc/test-libc/math:/builds/glibc/test-libc/elf:/builds/glibc/test-libc/dlfcn:/builds/glibc/test-libc/nss:/builds/glibc/test-libc/nis:/builds/glibc/test-libc/rt:/builds/glibc/test-libc/resolv:/builds/glibc/test-libc/crypt:/builds/glibc/test-libc/linuxthreads /builds/glibc/test-libc/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /builds/glibc/test-libc/sunrpc/xbootparam_prot.T
make[2]: *** [/builds/glibc/test-libc/sunrpc/xbootparam_prot.stmp] Segmentation fault
make[2]: Leaving directory `/cvs/libc/sunrpc'

To track down the failure, I used Janis' script and noticed that it
fails since the merge from the 3_4-basic-improvement branch.
Searching that branch I found this patch as beeing the problem:

+2002-10-07  Richard Henderson  <rth@redhat.com>
+
+       * cse.c (fixed_base_plus_p): Turn FIXED_BASE_PLUS_P into a
+       function; cleanup PLUS case by using recursion.  Update all users.
+       (NONZERO_BASE_PLUS_P): Remove.
+       (find_comparison_args): Use rtx_addr_can_trap_p instead.
+       (fold_rtx): Use nonzero_address_p.
+       * rtl.h (nonzero_address_p): Declare.
+       * rtlanal.c (rtx_varies_p): Handle ADDRESSOF.
+       (rtx_addr_can_trap_p): Likewise.
+       (nonzero_address_p): New.
+       * simplify-rtx.c (NONZERO_BASE_PLUS_P): Remove.
+       (simplify_relational_operation): Use nonzero_address_p.


I haven't been able to figure out which file in glibc is miscompiled
and therefore like to ask for an additional review of that patch
again.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj