[Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX

[Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX

[dje at gcc dot gnu.org]

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

           Summary: libgfortran references complex long double functions
                    missing on AIX
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dje@gcc.gnu.org


ld: 0711-317 ERROR: Undefined symbol: .__copysignl128
ld: 0711-317 ERROR: Undefined symbol: .__nextafterl128
ld: 0711-317 ERROR: Undefined symbol: .__scalbnl128
ld: 0711-317 ERROR: Undefined symbol: .__cabsl128
ld: 0711-317 ERROR: Undefined symbol: .__cargl128
ld: 0711-317 ERROR: Undefined symbol: .__truncl128

/*
 * There are two forms of long double on AIX.  The default
 * form of long double is the same as a double - 64 bits.  There
 * is a 128-bit form available with some compilers.  If that compiler
 * defines __LONGDOUBLE128, then long doubles are 128-bit instead of
 * 64-bit.  Since the same library routine cannot be used for 128-bit
 * and 64-bit values, the 128-bit routines are renamed and macros are
 * used to manage the name spaces.  It is not necessarily the case that
 * all of the 128-bit versions are available, but the macros are defined
 * intentionally since the 64-bit versions can provide incorrect results
 * when long double values were expected.  If 64-bit versions are required
 * in 128-bit mode, then the code needs to invoke the double routines a
 * rather than the long double routines.
 */

As the comment mentions, not all functions are available(!), but the functions
are redefined to prevent wrong results.

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
          Component|libfortran                  |target

--- Comment #1 from kargl at gcc dot gnu.org 2010-12-21 16:42:29 UTC ---
>From the description of the problem, this appears
to be a target bug not a libgfortran bug.  The
penultimate sentence in the quoted comments even
states that AIX is playing games with the namespace.

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.12.21 17:07:47
     Ever Confirmed|0                           |1

--- Comment #2 from David Edelsohn <dje at gcc dot gnu.org> 2010-12-21 17:07:47 UTC ---
This is an interaction / assumption problem between the target (AIX) and
libgfortran.  libgfortran previously built with GCC 4.4 s, this is a regression
because libgfortran is relying on more OS features without providing an
alternative.  And disabling all long double support (which works in G++) or
disabling libgfortran on AIX because of this issue seems like a bad options.

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-12-21 18:37:21 UTC ---
On Tue, Dec 21, 2010 at 05:07:53PM +0000, dje at gcc dot gnu.org wrote:
> This is an interaction / assumption problem between the target (AIX) and
> libgfortran.  libgfortran previously built with GCC 4.4 s, this is a regression
> because libgfortran is relying on more OS features without providing an
> alternative.  And disabling all long double support (which works in G++) or
> disabling libgfortran on AIX because of this issue seems like a bad options.
> 

libgfortran/configure.ac has lines of the form (note I wrapped the line)

AC_CHECK_LIB([m],[copysignl],[AC_DEFINE([HAVE_COPYSIGNL],[1],\
   [libm includes copysignl])])

So, configure is already checking if libm contains the
the "long double functions".  The problem appears to be
that AC_CHECK_LIB is a compile only test, and these tests
appear to pass on AIX.  AIX rquires a link time test to
either unseti, e.g., HAVE_COPYSIGNL or configure in general
should do a link time tests instead of a compile time tests
to ensure the HAVE_* macros are unset.

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
             Target|                            |powerpc-ibm-aix

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-28 16:09:49 UTC ---
David, does GCC 4.5.x build on AIX?

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn <dje at gcc dot gnu.org> 2011-01-06 18:55:20 UTC ---
(In reply to comment #4)
> David, does GCC 4.5.x build on AIX?

GCC 4.5 libgfortran builds on AIX 5.3, but not AIX 6.1.  GCC 4.4 libgfortran
built on both, so this is a regression, but I had not noticed the regression on
AIX 6.1.

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[michael.haubenwallner at salomon dot at]

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

Michael Haubenwallner <michael.haubenwallner at salomon dot at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael.haubenwallner at
                   |                            |salomon dot at

--- Comment #6 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-01-25 19:56:14 UTC ---
This looks like a dupe of bug#46481.

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[rwild at gcc dot gnu.org]

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

--- Comment #7 from Ralf Wildenhues <rwild at gcc dot gnu.org> 2011-02-04 05:16:15 UTC ---
(In reply to comment #3)
> libgfortran/configure.ac has lines of the form (note I wrapped the line)
> 
> AC_CHECK_LIB([m],[copysignl],[AC_DEFINE([HAVE_COPYSIGNL],[1],\
>    [libm includes copysignl])])
> 
> So, configure is already checking if libm contains the
> the "long double functions".  The problem appears to be
> that AC_CHECK_LIB is a compile only test, and these tests
> appear to pass on AIX.

AC_CHECK_LIB uses a link test, not a compile test.

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[pogma at gcc dot gnu.org]

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

Peter O'Gorman <pogma at gcc dot gnu.org> changed:

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

--- Comment #8 from Peter O'Gorman <pogma at gcc dot gnu.org> 2011-02-08 20:43:18 UTC ---
(In reply to comment #7)
> (In reply to comment #3)
> > libgfortran/configure.ac has lines of the form (note I wrapped the line)
> > 
> > AC_CHECK_LIB([m],[copysignl],[AC_DEFINE([HAVE_COPYSIGNL],[1],\
> >    [libm includes copysignl])])
> > 
> > So, configure is already checking if libm contains the
> > the "long double functions".  The problem appears to be
> > that AC_CHECK_LIB is a compile only test, and these tests
> > appear to pass on AIX.
> 
> AC_CHECK_LIB uses a link test, not a compile test.

As far as I can tell the problem is that the configure tests for long double
functions don't #include <math.h>, changing the AC_CHECK_LIB to AC_LINK_IFELSE
that #includes math.h and uses the symbol should give correct results.

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-02-08 20:49:04 UTC ---
On Tue, Feb 08, 2011 at 08:43:33PM +0000, pogma at gcc dot gnu.org wrote:
> --- Comment #8 from Peter O'Gorman <pogma at gcc dot gnu.org> 2011-02-08 20:43:18 UTC ---
> (In reply to comment #7)
> > (In reply to comment #3)
> > > libgfortran/configure.ac has lines of the form (note I wrapped the line)
> > > 
> > > AC_CHECK_LIB([m],[copysignl],[AC_DEFINE([HAVE_COPYSIGNL],[1],\
> > >    [libm includes copysignl])])
> > > 
> > > So, configure is already checking if libm contains the
> > > the "long double functions".  The problem appears to be
> > > that AC_CHECK_LIB is a compile only test, and these tests
> > > appear to pass on AIX.
> > 
> > AC_CHECK_LIB uses a link test, not a compile test.
> 
> As far as I can tell the problem is that the configure tests for long double
> functions don't #include <math.h>, changing the AC_CHECK_LIB to AC_LINK_IFELSE
> that #includes math.h and uses the symbol should give correct results.
> 

So, for the AC_CHECK_LIB line above, what does the
AC_LINK_IFELSE patch look like.

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[pogma at gcc dot gnu.org]

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

--- Comment #10 from Peter O'Gorman <pogma at gcc dot gnu.org> 2011-02-08 21:03:46 UTC ---
(In reply to comment #9)

> > > > AC_CHECK_LIB([m],[copysignl],[AC_DEFINE([HAVE_COPYSIGNL],[1],\
> > > >    [libm includes copysignl])])

> So, for the AC_CHECK_LIB line above, what does the
> AC_LINK_IFELSE patch look like.

Totally untested - something like:

gcc_save_LIBS="$LIBS"
LIBS="$LIBS -lm"
AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <math.h>],[return
(int)copysignl(-1.0,1.0);])],[AC_DEFINE([HAVE_COPYSIGNL],[1],[libm includes
copysignl])])
LIBS="$gcc_save_LIBS"

AIX's math.h has, conditional on 128 bit longdoubles:
#define copysignl(__x, __y)     __copysignl128((long double) (__x), (long
double) (__y))

And libm does indeed have a copysignl symbol (but it's missing __copysignl128),
so AC_CHECK_LIB says "yes, libm has copysignl", because it just checks if the
symbol exists in the library. #including math.h and then trying a link test
should give correct results because it will fail to find __copysignl128 in libm

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[michael.haubenwallner at salomon dot at]

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

--- Comment #11 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-02-08 22:14:19 UTC ---
(In reply to comment #10)
> #including math.h and then trying a link test
> should give correct results because it will fail to find __copysignl128 in libm

While this is absolutely true, the major problem here is that gcc should not
have switched to 128bit long double at all with AIX 6.1 (bug#46481).
Especially not without linking against libc128.a AIX library and adding the
long double bitwidth as another multilib criterion for
libgcc/libstdc++/libwhatever, to allow for the 64bit long double, where all the
math functions are available, and which is still the default with xlc.

BTW: Using pthread as multilib criterion seems unnecessary these days...

[Bug target/47032] libgfortran references complex long double functions missing on AIX

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-12 15:04:48 UTC ---
(In reply to comment #11)
> While this is absolutely true, the major problem here is that gcc should not
> have switched to 128bit long double at all with AIX 6.1 (bug#46481).

Cf. http://gcc.gnu.org/ml/gcc/2011-02/msg00109.html
and http://gcc.gnu.org/ml/gcc/2011-02/msg00159.html

 * * *

For the libgfortran side: Seems as if one should add a "#include
<math.h>"-based link test (cf. comment 8 and 10).

libgfortran currently only uses the functions if available (configure check).
The effect, if the are not, is the following:

(In reply to comment #0)
> ld: 0711-317 ERROR: Undefined symbol: .__copysignl128
> ld: 0711-317 ERROR: Undefined symbol: .__nextafterl128

Used by Fortran's NEAREST intrinsic (if available; no fall back if not) - thus,
it will fail if a user calls this function but should otherwise be OK.

> ld: 0711-317 ERROR: Undefined symbol: .__scalbnl128

Used for the intrinsics RRSPACING, SPACING and SET_EXPONENT.

> ld: 0711-317 ERROR: Undefined symbol: .__truncl128

Used for Fortran's ERFC_SCALED intrinsic.


> ld: 0711-317 ERROR: Undefined symbol: .__cabsl128
> ld: 0711-317 ERROR: Undefined symbol: .__cargl128

gfortran offers a replacement function in intrinsics/c99_functions.c, if
configure believes that those are not available.

I think most codes/users do not need either of NEAREST, ERFC_SCALED, RRSPACING,
SPACING and SET_EXPONENT. (I do not know whether other math functions are
effected, whose calls are directly generated via the front end.)