glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ismail Dönmez]

Hi all,

I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day and 
I see 3 tests fail :

math/test-float
math/test-ildoubl
math/test-ifloat

The erorrs are all similar :

Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i
Result:
 is:          0.00000000000000000000e+00   0x0.00000000000000000000p+0
 should be:   1.57079637050628662109e+00   0x1.921fb600000000000000p+0
 difference:  1.57079637050628662109e+00   0x1.921fb600000000000000p+0
 ulp       :  13176795.0000
 max.ulp   :  0.0000

All of the imaginary part checks fail, with the help of GFortran maintainers 
we identified 2 testcases which fail with glibc 2.7 when compiled with gcc 
4.3 trunk [0] .

This problem also causes 32 unexpected failures on gfortran regression tests. 
So I wonder if you guys can help me debug this, I checked out libc sources 
but its mostly assembly stuff for math functions. Maybe Jakub has an idea, 
not sure.

Any help/comment appreciated.

[0] http://sourceware.org/bugzilla/show_bug.cgi?id=5490

Regards,
ismail


-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ismail Dönmez]

Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları yazmıştı:
> Hi all,
>
> I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day
> and I see 3 tests fail :
>
> math/test-float
> math/test-ildoubl
> math/test-ifloat
>
> The erorrs are all similar :
>
> Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i
> Result:
>  is:          0.00000000000000000000e+00   0x0.00000000000000000000p+0
>  should be:   1.57079637050628662109e+00   0x1.921fb600000000000000p+0
>  difference:  1.57079637050628662109e+00   0x1.921fb600000000000000p+0
>  ulp       :  13176795.0000
>  max.ulp   :  0.0000

All these failures are gone when glibc is compiled with -O2 instead of -O3 but 
there are still 4 regressions :

math/test-ildoubl

Usual math problem :

testing long double (inline functions)
Failure: Test: expm1 (1) == M_El - 1.0
Result:
 is:          1.71828182845904523532e+00   0xd.bf0a8b14576953500000p-3
 should be:   1.71828182845904523543e+00   0xd.bf0a8b14576953600000p-3
 difference:  1.08420217248550443401e-19   0x8.00000000000000000000p-66
 ulp       :  1.0000
 max.ulp   :  0.0000
Maximal error of `expm1'
 is      : 1 ulp
 accepted: 0 ulp

libio/tst-fopenloc2
libio/tst-fopenloc

These two seems to be a new gcc regression, they crash when compiled with gcc 
trunk.

elf/check-localplt

These seems to be less harmful, shows memalign is missing from expected 
output.


Any ideas appreciated.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ismail Dönmez]

Friday 28 December 2007 16:20:52 tarihinde Ismail Dönmez şunları yazmıştı:
> libio/tst-fopenloc2
> libio/tst-fopenloc
>
> These two seems to be a new gcc regression, they crash when compiled with
> gcc trunk.

Ok I identified that commit 130788 [0] broke these testcases  , the same 
commit seems to be the cause for PR34465 .

[0] http://gcc.gnu.org/viewcvs?view=rev&revision=130788

Regards,
ismail


-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ismail Dönmez]

Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları yazmıştı:
> Hi all,
>
> I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day
> and I see 3 tests fail :
>
> math/test-float
> math/test-ildoubl
> math/test-ifloat
>
> The erorrs are all similar :
>
> Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i
> Result:
>  is:          0.00000000000000000000e+00   0x0.00000000000000000000p+0
>  should be:   1.57079637050628662109e+00   0x1.921fb600000000000000p+0
>  difference:  1.57079637050628662109e+00   0x1.921fb600000000000000p+0
>  ulp       :  13176795.0000
>  max.ulp   :  0.0000

Replying to myself once again, these failures are due to -fgcse-after-reload 
flag, -O3 -fno-gcse-after-reload cures this. Any tips on how to debug this?

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ian Lance Taylor]

Ismail Dönmez <ismail@pardus.org.tr> writes:

> Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları yazmıştı:
> > Hi all,
> >
> > I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day
> > and I see 3 tests fail :
> >
> > math/test-float
> > math/test-ildoubl
> > math/test-ifloat
> >
> > The erorrs are all similar :
> >
> > Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i
> > Result:
> >  is:          0.00000000000000000000e+00   0x0.00000000000000000000p+0
> >  should be:   1.57079637050628662109e+00   0x1.921fb600000000000000p+0
> >  difference:  1.57079637050628662109e+00   0x1.921fb600000000000000p+0
> >  ulp       :  13176795.0000
> >  max.ulp   :  0.0000
> 
> Replying to myself once again, these failures are due to -fgcse-after-reload 
> flag, -O3 -fno-gcse-after-reload cures this. Any tips on how to debug this?

Generic advice to start: compile with -da to get all the RTL dump
files.  Compare the dump files immediately before and after
gcse-after-reload and see what changed.  Set breakpoints on
validate_change or make_insn_raw as appropriate for the changes.  Walk
up the stack and see what the code is doing.  The file in question is
postreload-gcse.c, which is relatively self-contained.

Of course it is moderately likely that the bug is not in
gcse-after-reload, and is in some other pass generating incorrect
information.  Still, finding the problem in gcse-after-reload is a
good start.

Ian

Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ismail Dönmez]

Saturday 29 December 2007 19:49:13 tarihinde Ian Lance Taylor şunları 
yazmıştı:
> Ismail Dönmez <ismail@pardus.org.tr> writes:
> > Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları 
yazmıştı:
> > > Hi all,
> > >
> > > I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every
> > > day and I see 3 tests fail :
> > >
> > > math/test-float
> > > math/test-ildoubl
> > > math/test-ifloat
> > >
> > > The erorrs are all similar :
> > >
> > > Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i
> > > Result:
> > >  is:          0.00000000000000000000e+00   0x0.00000000000000000000p+0
> > >  should be:   1.57079637050628662109e+00   0x1.921fb600000000000000p+0
> > >  difference:  1.57079637050628662109e+00   0x1.921fb600000000000000p+0
> > >  ulp       :  13176795.0000
> > >  max.ulp   :  0.0000
> >
> > Replying to myself once again, these failures are due to
> > -fgcse-after-reload flag, -O3 -fno-gcse-after-reload cures this. Any tips
> > on how to debug this?
>
> Generic advice to start: compile with -da to get all the RTL dump
> files.  Compare the dump files immediately before and after
> gcse-after-reload and see what changed.  Set breakpoints on
> validate_change or make_insn_raw as appropriate for the changes.  Walk
> up the stack and see what the code is doing.  The file in question is
> postreload-gcse.c, which is relatively self-contained.
>
> Of course it is moderately likely that the bug is not in
> gcse-after-reload, and is in some other pass generating incorrect
> information.  Still, finding the problem in gcse-after-reload is a
> good start.

Thanks I'll try, this is all new to me so its rather likely to be slow 
progress.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.