------- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-21
12:47 -------
Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
> ------- Comment #6 from kargl at gcc dot gnu dot org 2010-06-16 21:51 -------
> (In reply to comment #5)
>> This makes no sense at all. Rainer, I'm really sorry if it seems that I'm
>> shooting questions a bit at random, but I have a hard time imagining how to
>> narrow it down.
>>
>> Can you try the following equivalent C code (at -O0):
Sure: same differences as in the Fortran case:
-4.35483e-08
-4.35483e-08
-1.08095e-16
-1.08095e-16
4.33013e-08
4.33013e-08
4.38018e-17
4.38018e-17
3.05453e-08
3.05453e-08
3.33934e-17
3.33934e-17
2.96684e-08
2.96684e-08
-5.76796e-17
-5.76796e-17
4.87235e-08
4.87235e-08
-9.40003e-17
-9.40003e-17
-1.70395e-08
-1.70395e-08
2.55872e-17
2.55872e-17
1.2215e-09
1.2215e-09
-3.88144e-17
-3.88144e-17
2.30691e-08
2.30691e-08
-2.1684e-18
-2.1684e-18
-1.41206e-08
-1.41206e-08
-8.18573e-18
-8.18573e-18
2.18557e-08
2.18557e-08
-3.06287e-17
-3.06287e-17
>> Right now, the only thing I can see make sense is numerically instability in
>> the libm. Also, how are atan2f and atan2 defined in the system's math.h
>> header?
>> Do they have simple prototypes? Are they actually macros?
The declarations are in <iso/math_c99.h>:
<iso/math_c99.h>:
extern float atanf __P((float));
extern float atan2f __P((float, float));
#if !defined(__cplusplus)
#pragma does_not_read_global_data(acosf, asinf, atanf, atan2f)
#pragma does_not_write_global_data(acosf, asinf, atanf, atan2f)
#if defined(__MATHERR_ERRNO_DONTCARE)
#pragma no_side_effect(acosf, asinf, atanf, atan2f)
> Does -ffloat-store change the outcome? This looks to possibly
> be an excess precision problem and the difference between something
> in a register and main memory.
Indeed: with -ffloat-store, the test program only prints 0s.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44448
