[Bug middle-end/19974] incorrect complex division on ia-64 with flag_complex_method = 2

2005-02-16 Thread Thomas dot Koenig at online dot de

--- Additional Comments From Thomas dot Koenig at online dot de  2005-02-16 
12:41 ---
I think I have identified the problem.

The hang itself is probably caused by a Lapack bug, because slarrb is
only fed 0. and NaN as arguments.

The reason why this is so is probably due to a problem in complex
division with flag_complex_method = 2.  Here's a test case:

$ cat c-tst.c
#include stdio.h
#include math.h
#include complex.h

int main()
{
float complex a,b,c;
a = 1.e20-I*1.e12;
b = 1. - I*1.e-8;
c = a/b;
printf(%.5g %.5g\n,creal(c),cimag(c));
return 0;
}

This has flag_complex_medhod = 2:

$ gcc -B ~/gcc-C2/gcc c-tst.c
$ ./a.out
1e+20 18059
  ^^
   wrong

This has flag_complex_method = 1:

$ gcc -B ~/gcc-C1/gcc c-tst.c
$ ./a.out
1e+20 0
  ^^
  correct

Probably a wrong sign when recovering from overflow in the
new complex division routines.

Adding rth to the cc list.

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
OtherBugsDependingO||18902
  nThis||
Summary|Lapack hang in xeigtstc on  |incorrect complex division
   |ia-64   |on ia-64 with
   ||flag_complex_method = 2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974


[Bug middle-end/19974] incorrect complex division on ia-64 with flag_complex_method = 2

2005-02-16 Thread rth at gcc dot gnu dot org

--- Additional Comments From rth at gcc dot gnu dot org  2005-02-16 19:11 
---
I don't reproduce this on amd64.  It was raining in the machine room yesterday,
so I don't have access to my ia64 machine to see if it's something special 
there.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974


[Bug middle-end/19974] incorrect complex division on ia-64 with flag_complex_method = 2

2005-02-16 Thread Thomas dot Koenig at online dot de

--- Additional Comments From Thomas dot Koenig at online dot de  2005-02-16 
20:51 ---
Checking this on i686-unknown-linux-gnu, I find the same
result with flag_complex_method=2 as on ia-64.  I am also
seeing the same result with logarithmic scaling (using frexp and
ldexp). Maybe I'm being bitten by the decimal fractions not being exactly
representable in binary, and the Lapack failure has some other reason.

I'll keep looking.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974