This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #6 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #4)
>>> int main (void)
>>> {
>>>   long double x;
>>>   x = 789.1356;
>>>   __builtin_printf ("%.30Lg\n", x);
>>>   __builtin_printf ("%.30Lg\n", __builtin_sqrtl(x));
>>> }
>> 
>> I get
>> 
>> 789.13559999999995397956809029
>> -NaN
>
> OK, then it's definitely not Fortran-specific. The question is: is it just
> because of GCC's built-in handling (e.g., because the math.h header does
> something weird), or is it simply that the libm's sqrtl() is unusable?

I believe the results for invoking sqrtl instead of __builtin_sqrtl show
that gcc's builtin handling is wrong in some way.  <math.h> and friends
show no weird constructs that might cause this.

        Rainer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]