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

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

[ro at gcc dot gnu.org]

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

            Bug ID: 67419
           Summary: gfortran.dg/large_real_kind_2.F90 FAILs
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: fxcoudert at gcc dot gnu.org
  Target Milestone: ---
              Host: sparc*-sun-solaris2.12
            Target: sparc*-sun-solaris2.12
             Build: sparc*-sun-solaris2.12

The gfortran.dg/large_real_kind_2.F90 testcase FAILs on Solaris 12/SPARC (both
32 and 64-bit):

FAIL: gfortran.dg/large_real_kind_2.F90   -O0  execution test

Solaris 10 and 11 are both fine.

Running it manually and under gdb, I find

Program aborted. Backtrace:
#0  0xFEAEEB37

[New Thread 1 (LWP 1)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xf2bba064 in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0  0xf2bba064 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xf2b07dc8 in raise () from /lib/libc.so.1
#2  0xf2ad6d14 in abort () from /lib/libc.so.1
#3  0xff2effd8 in _gfortrani_sys_abort ()
    at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:180
#4  0xff38e35c in _gfortran_abort ()
    at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:33
#5  0x00013504 in MAIN__ ()
    at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/large_real_kind_2.F90:45

which is

 TEST_FUNCTION(sqrt,789.1356)

  Rainer

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

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |6.0

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

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-09-01
     Ever confirmed|0                           |1

--- Comment #1 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Can you run the following test and paste the output here?

  integer,parameter :: k = selected_real_kind (precision (0.0_8) + 1)
  real(kind=k) :: x
  real(kind=8) :: y

  print *, k
  x = 789.1356
  y = 789.1356
  print *, x
  print *, y
  print *, sqrt(x)
  print *, sqrt(y)
  print *, abs((sqrt(y)-sqrt(x))/sqrt(x))
  end

This should call sqrtl() and sqrt() on the same value, and check that the
results are close enough to one another. But the threshold of the test case is
really generous…
>From gcc-bugs-return-496063-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 01 13:04:37 2015
Return-Path: <gcc-bugs-return-496063-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 90774 invoked by alias); 1 Sep 2015 13:04:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 90721 invoked by uid 55); 1 Sep 2015 13:04:32 -0000
From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs
Date: Tue, 01 Sep 2015 13:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ro at CeBiTec dot Uni-Bielefeld.DE
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67419-4-YeWfNEAsyw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67419-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67419-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-09/txt/msg00041.txt.bz2
Content-length: 693

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg419

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
> Can you run the following test and paste the output here?
[...]

Sure:

          16
   789.135620117187500000000000000000000
   789.13562011718750
                                           NaN
   28.091557808658237
                                           NaN

The result is identical for both the mainline libgfortran.so.3 and the
bundled gcc 4.8 libgfortran.so.3, so this might well be a libm bug
introduced in Solaris 12.

        Rainer

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

[fxcoudert at gcc dot gnu.org]

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

--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2)
> The result is identical for both the mainline libgfortran.so.3 and the
> bundled gcc 4.8 libgfortran.so.3, so this might well be a libm bug
> introduced in Solaris 12.

What if you compile the following C source (with "gcc -lm") and run it?

int main (void)
{
  long double x;
  x = 789.1356;
  __builtin_printf ("%.30Lg\n", x);
  __builtin_printf ("%.30Lg\n", __builtin_sqrtl(x));
}

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2)
>> The result is identical for both the mainline libgfortran.so.3 and the
>> bundled gcc 4.8 libgfortran.so.3, so this might well be a libm bug
>> introduced in Solaris 12.
>
> What if you compile the following C source (with "gcc -lm") and run it?
>
> 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

        Rainer

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
>> --- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
>> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2)
>>> The result is identical for both the mainline libgfortran.so.3 and the
>>> bundled gcc 4.8 libgfortran.so.3, so this might well be a libm bug
>>> introduced in Solaris 12.
>>
>> What if you compile the following C source (with "gcc -lm") and run it?
>>
>> 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

If I drop the __builtin_ and include <stdio.h> and <math.h> instead, I
get the expected

789.13559999999995397956809029
28.0915574505935849505420666378

        Rainer

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

[fxcoudert at gcc dot gnu.org]

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

--- 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?

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

[fxcoudert at gcc dot gnu.org]

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

--- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #5)
> If I drop the __builtin_ and include <stdio.h> and <math.h> instead, I
> get the expected

Then the math.h header is playing tricks and GCC is not aware. This need to be
fixed in the solaris back-end (the same sort of thing happened with darwin in
the past, see darwin_patch_builtin in gcc/config/darwin.c).

Best bet is to check in math.h how sqrtl() is defined. And then check the
assembly code for both the __builtin_sqrtl() and the header-defined sqrtl().

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #5)
>> If I drop the __builtin_ and include <stdio.h> and <math.h> instead, I
>> get the expected
>
> Then the math.h header is playing tricks and GCC is not aware. This need to be
> fixed in the solaris back-end (the same sort of thing happened with darwin in
> the past, see darwin_patch_builtin in gcc/config/darwin.c).
>
> Best bet is to check in math.h how sqrtl() is defined. And then check the
> assembly code for both the __builtin_sqrtl() and the header-defined sqrtl().

That's what I'll do next, together with comparing S11 and S12 and -O0
with -O1.

Thanks.
        Rainer

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
>> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #5)
>>> If I drop the __builtin_ and include <stdio.h> and <math.h> instead, I
>>> get the expected
>>
>> Then the math.h header is playing tricks and GCC is not aware. This need to be
>> fixed in the solaris back-end (the same sort of thing happened with darwin in
>> the past, see darwin_patch_builtin in gcc/config/darwin.c).
>>
>> Best bet is to check in math.h how sqrtl() is defined. And then check the
>> assembly code for both the __builtin_sqrtl() and the header-defined sqrtl().
>
> That's what I'll do next, together with comparing S11 and S12 and -O0
> with -O1.

It's definitively a Solaris 12 bug: gcc creates identical code for the
__builtin_sqrtl case between Solaris 11 and 12.  It works on S11, but
fails on S12.  If I run the S12 binary to an S11 machine, it runs there
just fine.

I'll check with my contacts.

        Rainer