[Bug libfortran/46584] New: FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[Bug libfortran/46584] New: FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[danglin at gcc dot gnu.org]

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

           Summary: FAIL: gfortran.dg/quad_1.f90  -O  (test for excess
                    errors)
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: danglin@gcc.gnu.org
              Host: hppa64-hp-hpux11.11
            Target: hppa64-hp-hpux11.11
             Build: hppa64-hp-hpux11.11


Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa64
-hp-hpux11.11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/quad_1.
f90   -O   -pedantic-errors 
-B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfo
rtran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/te
st/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir
/hppa64-hp-hpux11.11/./libiberty  -lm   -o quad_1.exe    (timeout = 300)
ld: Unsatisfied symbol "ccosl" in file /var/tmp//ccCzoigS.o
ld: Unsatisfied symbol "csinhl" in file /var/tmp//ccCzoigS.o
ld: Unsatisfied symbol "csinl" in file /var/tmp//ccCzoigS.o
3 errors.
collect2: ld returned 1 exit status

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from John David Anglin <danglin at gcc dot gnu.org> 2010-11-26 01:05:22 UTC ---
I have a patch that adds the hooks to build libquadmath on PA HP_UX targets. 
However, I'm not sure what's the best way to map the 'l' C99 builtins like
those below to the corresponding 'q' functions in the new library.

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-26 08:04:50 UTC ---
The test case quad_1.f90 does not always use quad precision (despite its name)
but it uses the highest available floating point type. Depending on the system
that can be the real kind 8 (64 bits), 10 (80 bits) or 16 (128 bits).

The FE does the following matching for a REAL type matching sizeof(float) ->
"sinf", for double -> "sin", for long double -> "sinl", and for __float128 ->
sinq.

Thus, on HPPA there seems to be a floating point type which is larger than
"double" and which matches "long double" while __float128 does not seem to be
available.

Hence, the issue seems to rather that we have found a C99 math function which
is no implemented in HPUX: A long-double complex cosine (ccosl).
There are some fall-back C99 functions implemented in libgfortran but seemingly
none of the complex trigonometric ones; cf.
http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/intrinsics/c99_functions.c

The muddle over solution is to change the ccosl function to some other -
possibly complex - long double function which is implemented - maybe csqrtl is?


> I have a patch that adds the hooks to build libquadmath on PA HP_UX targets. 
> However, I'm not sure what's the best way to map the 'l' C99 builtins like
> those below to the corresponding 'q' functions in the new library.

It is not completely clear what your patch is supposed to do. Seemingly PA has
a hardware >(8 bytes)/double data type. I do not know whether long double is 80
bits long or 128 bits. If it is not 80 bits, you could consider adding
__float128 - but if long double is already 128 bits, I do not see why one
should do so.  If there is no 128 bit type, adding __float128 will
automatically make a REAL(16) available, which will use libquadmath.

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|hppa64-hp-hpux11.11         |hppa64-hp-hpux11.11,
                   |                            |sparc*-sun-solaris2.[89]
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.11.26 08:44:27
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org
               Host|hppa64-hp-hpux11.11         |
     Ever Confirmed|0                           |1
              Build|hppa64-hp-hpux11.11         |

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-26 08:44:27 UTC ---
Same problem on SPARC/Solaris 8 and 9 (but not 10).  SPARC has quad precision
floating point support but Solaris 8 and 9 aren't C99; only Solaris 10 is.

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-26 13:45:31 UTC ---
(In reply to comment #3)
> Same problem on SPARC/Solaris 8 and 9 (but not 10).  SPARC has quad precision
> floating point support but Solaris 8 and 9 aren't C99; only Solaris 10 is.

There is a simple solution: Simply not using a C99 long double math function
... That won't test complex libquadmath functions anymore, but one can defer
that to a libquadmath testsuite, if needed.

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2010-11-26 19:04:56 UTC ---
On Fri, 26 Nov 2010, burnus at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46584
> 
> --- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-26 08:04:50 UTC ---
> The test case quad_1.f90 does not always use quad precision (despite its name)
> but it uses the highest available floating point type. Depending on the system
> that can be the real kind 8 (64 bits), 10 (80 bits) or 16 (128 bits).
> 
> The FE does the following matching for a REAL type matching sizeof(float) ->
> "sinf", for double -> "sin", for long double -> "sinl", and for __float128 ->
> sinq.
> 
> Thus, on HPPA there seems to be a floating point type which is larger than
> "double" and which matches "long double" while __float128 does not seem to be
> available.
> 
> Hence, the issue seems to rather that we have found a C99 math function which
> is no implemented in HPUX: A long-double complex cosine (ccosl).
> There are some fall-back C99 functions implemented in libgfortran but seemingly
> none of the complex trigonometric ones; cf.
> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/intrinsics/c99_functions.c
> 
> The muddle over solution is to change the ccosl function to some other -
> possibly complex - long double function which is implemented - maybe csqrtl is?
> 
> 
> > I have a patch that adds the hooks to build libquadmath on PA HP_UX targets. 
> > However, I'm not sure what's the best way to map the 'l' C99 builtins like
> > those below to the corresponding 'q' functions in the new library.
> 
> It is not completely clear what your patch is supposed to do. Seemingly PA has
> a hardware >(8 bytes)/double data type. I do not know whether long double is 80
> bits long or 128 bits. If it is not 80 bits, you could consider adding
> __float128 - but if long double is already 128 bits, I do not see why one
> should do so.  If there is no 128 bit type, adding __float128 will
> automatically make a REAL(16) available, which will use libquadmath.

PA has hardware float and double.  The architecture has provision
for long double but this was never implemented in hardware.  HP-UX
has a software support for for basic arithmetic and compares using
long doubles.  However, there are now math routines of any kind.

The original testcase failure occured with the existing long double
support because of the lack of long double math routines (cosl, etc).

Given the recent addition of libquadmath, I thought it might be useful
to try and enable it.  Current patch to enable building libquadmath
is attached.  libquadmath appears to have built successfully on
hppa64-hp-hpux11.11 with this change.

I needed to add __float128 type and some builtins.  To do this, I
essentially copied stuff from ia64.  As things stand now, it seems
the fortran front end uses the 'l' math functions in preference to
the 'q' functions in libquadmath.

It appears the configure for libgfortran checks for the presence
of all the 'l' math functions.  However, it might be better to map
'l' to 'q' in a quadmath header, so libquadmath doesn't depend on
libgfortran (i.e., make it usable from C, etc).

Does this make sense?

Dave

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-11-26 21:28:52 UTC ---
On Fri, 26 Nov 2010, dave at hiauly1 dot hia.nrc.ca wrote:

> I needed to add __float128 type and some builtins.  To do this, I

__float128 should only be present where it is distinct from long double; 
it just confuses things to add it on other architectures.

> essentially copied stuff from ia64.  As things stand now, it seems
> the fortran front end uses the 'l' math functions in preference to
> the 'q' functions in libquadmath.
> 
> It appears the configure for libgfortran checks for the presence
> of all the 'l' math functions.  However, it might be better to map
> 'l' to 'q' in a quadmath header, so libquadmath doesn't depend on
> libgfortran (i.e., make it usable from C, etc).
> 
> Does this make sense?

No.  The purpose of libquadmath is to provide functions for the __float128 
type which is not a standard C type, for targets where it is present as a 
fourth floating-point type.  It is not to substitute for deficiencies in 
the system libm regarding functions for the standard three types.

If you wish to create a substitute or add-on libm for standard functions 
for the standard types where system libm is missing them, discuss that on 
the mailing lists, not in a Bugzilla PR.  It should not be libquadmath; it 
should be called something else, although it might share some source 
files.  The source files would in that case be adapted to abstract away 
the name of the type involved, so they can be built for either __float128 
or long double.

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-04 13:08:15 UTC ---
Author: burnus
Date: Sat Dec  4 13:08:12 2010
New Revision: 167455

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167455
Log:
2010-12-04  Tobias Burnus  <burnus@net-b.de>

        PR fortran/46584
        * gfortran.dg/quad_1.f90: Remove some complex
        math checks as they fail on some non-libquadmath
        systems.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/quad_1.f90

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-04 13:13:51 UTC ---
The committed patch removed the complex math functions from the quad_1.f90
test.

I think the PR can be closed after confirmation that the failure is gone.

Regarding hppa64-hp-hpux: I think one could (e.g. with weak alias) consider
building a libquadmath which provides also "long double" names on platforms
where the libm does not provide the required functionality and where __float128
and long double are the same data type. However, I think that's an unrelated
issue, which I want to leave to the maintainers of the relevant platforms
(seemingly only: HPUX on ia64).

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-12-06 20:10:36 UTC ---
> I think the PR can be closed after confirmation that the failure is gone.

OK on the SPARC: http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg00514.html

Thanks.

[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-07 10:09:47 UTC ---
Seems to be also fixed on HPPA, cf.
http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg00536.html

Thus: Close as FIXED.