[Bug target/47032] libgfortran references complex long double functions missing on AIX
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.)
[Bug target/47032] libgfortran references complex long double functions missing on AIX
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
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 +, 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
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
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
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
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
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
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
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
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
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 +, 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.
