Incompatibility between gcc and glibc

Incompatibility between gcc and glibc

[M.Schimschak]

I already submitted this report to bug-gcc@prep.ai.mit.edu
(gnu.gcc.bug), but didn't get any feedback yet. Since this bug also
applies to egcs-1.0.1 I send it to you as well. 
Here's the program which is compiled with errors by several gcc based
compilers when used with optimization, basically when inlining is
allowed (see below):

-------------------------------------------------------------------------------

#include <stdlib.h>
#include <stdio.h>
#include <math.h>


int main(void)
{
  double     c=0;
  double     d=0;
  double     e[2];


  e[0] = 1.0;
  e[1] = 1.0;

  
  printf("%5g %5g   %10g %10g\n",e[0], e[1], c, d);

  c = atan2(e[0], e[1]);
  d = e[0] * e[0] + e[1] * e[1];

  printf("%5g %5g   %10g %10g\n",e[0], e[1], c, d);

  return 0;
}

-------------------------------------------------------------------------------
This program is supposed to produce the following output:

"    1     1                 0               0
     1     1      0.7853981634               2"

Instead it produces the following output with several compilers and
several optimization levels:

"    1     1                 0               0
     1     1      0.7853981634     1.785398163"
                                   ^^^^^^^^^^^

It seems that there is some kind of incompatibility between gcc and
glibc. I traced the bug down to the inline optimization. On a glibc
(2.0.6) based Red Hat Linux system, gcc-2.7.2.3 produces erroneous
code when used with -O2. On the same system  egcs-2.90.23 980102
(egcs-1.0.1 release) produces erroneous code when used with -O1.
In both cases the compilers produce correct code when used with
-fno-inline. In the case where the -fno-inline flag is used the
linking of libm is necessary, whereas in the case where inlining is
allowed the code for the atan2 function call is taken from
"/usr/include/__math.h" which is included by math.h. Here's the code
block from __math.h, maybe it will help (unfortunately I have no idea
what is going on there ;-)

-----------------------------------------------------------------------

__MATH_INLINE double atan2 (double __y, double __x);
__MATH_INLINE double
atan2 (double __y, double __x)
{
  register double __value;
  __asm __volatile__
    ("fpatan\n\t"
     "fldl %%st(0)"
     : "=t" (__value) : "0" (__x), "u" (__y));

  return __value;
}

----------------------------------------------------------------------

Systems that I checked so far involve 
   Red Hat 4.2 Linux system (libc 5.3.12, i486) -- no problems
       gcc version 2.7.2.1 -- no problems

  Red Hat 5.0 Linux system (glibc 2.0.6, i586) -- all with erroneous code
       gcc version 2.7.2.3
       gcc version 2.8.0
       gcc version 2.8.1
       egcs-2.90.23 980102 (egcs-1.0.1 release) (erroneous code for
                                                 -O1, save for -O0 or -O2)
       pgcc-2.91.04 980115 (gcc-2.8.0 release)

  Dec Alpha system  (Digital UNIX V4.0B, ?, alpha) -- no problems
       gcc-2.8.0

It would be interesting to know if the error also occurs on Dec Alphas 
when used with Red Hat 5.0 Linux.


Hope this helps for tracing the bug,

        Martin

Re: Incompatibility between gcc and glibc: alphaev5-dec-linux-gnu

[Jochen K"upper]

On Wed, 11 Mar 1998, M.Schimschak wrote:

> Here's the program which is compiled with errors by several gcc based
> compilers when used with optimization, basically when inlining is
> allowed (see below):
> 
> -------------------------------------------------------------------------------
> 
> #include <stdlib.h>
> #include <stdio.h>
> #include <math.h>
> 
> 
> int main(void)
> {
>   double     c=0;
>   double     d=0;
>   double     e[2];
> 
> 
>   e[0] = 1.0;
>   e[1] = 1.0;
> 
>   
>   printf("%5g %5g   %10g %10g\n",e[0], e[1], c, d);
> 
>   c = atan2(e[0], e[1]);
>   d = e[0] * e[0] + e[1] * e[1];
> 
>   printf("%5g %5g   %10g %10g\n",e[0], e[1], c, d);
> 
>   return 0;
> }
> 
> -------------------------------------------------------------------------------
> This program is supposed to produce the following output:
> 
> "    1     1                 0               0
>      1     1      0.7853981634               2"
> 
> Instead it produces the following output with several compilers and
> several optimization levels:
> 
> "    1     1                 0               0
>      1     1      0.7853981634     1.785398163"
>                                    ^^^^^^^^^^^

Results on a RH-5.0 system on alphaev5-dec-linux-gnu, glibc-2.0.6 from
RH-5.0 updates, compilers see below:

I need to link against libm all time, because there is no inline for atan2
in __math.h on my machine !

The foolowing results are achieved by standard gcc and by egcs:
gcc -v
Reading specs from
/usr/share/gcc2/lib/gcc-lib/alphaev5-dec-linux-gnu/2.8.1/specs
gcc version 2.8.1
egcc -v
Reading specs from
/usr/local/share/egcs/lib/gcc-lib/alphaev5-dec-linux-gnu/egcs-2.91.13/specs
gcc version egcs-2.91.13 980308 (gcc-2.8.0 release)
 
gcc inline01.cc -o bug -lm                      correct
gcc -O1 inline01.cc -o bug -lm                  correct
gcc -O2 inline01.cc -o bug -lm                  correct
gcc -O3 inline01.cc -o bug -lm                  correct
gcc -finline -O3 inline01.cc -o bug -lm         correct

Jochen

 


-----------------------------------------------------------------------
  Jochen K"upper

  Heinrich-Heine-Universit"at D"usseldorf   jochen@uni-duesseldorf.de
  Institut f"ur Physikalische Chemie I
  Universit"atsstr. 1, Geb 26.43 Raum 02.29    phone ++49-211-8113681
  40225 D"usseldorf                            fax   ++49-211-8115195
  Germany             http://www-public.rz.uni-duesseldorf.de/~jochen
-----------------------------------------------------------------------

Re: Incompatibility between gcc and glibc

[Jeffrey A Law]

  In message <199803112017.VAA28661@iff077.iff.kfa-juelich.de>you write:
  > I already submitted this report to bug-gcc@prep.ai.mit.edu
  > (gnu.gcc.bug), but didn't get any feedback yet. Since this bug also
  > applies to egcs-1.0.1 I send it to you as well. 
  > Here's the program which is compiled with errors by several gcc based
  > compilers when used with optimization, basically when inlining is
  > allowed (see below):
[ ... ]

  > ---------------------------------------------------------------------------
  > ----
  > This program is supposed to produce the following output:
  > 
  > "    1     1                 0               0
  >      1     1      0.7853981634               2"
  > 
  > Instead it produces the following output with several compilers and
  > several optimization levels:
  > 
  > "    1     1                 0               0
  >      1     1      0.7853981634     1.785398163"
  >                                    ^^^^^^^^^^^
I get the correct results using the egcs-1.1 branch with.  So presumably
this bug has been fixed.
jeff