public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX
@ 2010-12-21 16:22 dje at gcc dot gnu.org
2010-12-21 16:42 ` [Bug target/47032] " kargl at gcc dot gnu.org
` (11 more replies)
0 siblings, 12 replies; 13+ messages in thread
From: dje at gcc dot gnu.org @ 2010-12-21 16:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
@ 2010-12-21 16:42 ` kargl at gcc dot gnu.org
2010-12-21 17:08 ` dje at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: kargl at gcc dot gnu.org @ 2010-12-21 16:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
2010-12-21 16:42 ` [Bug target/47032] " kargl at gcc dot gnu.org
@ 2010-12-21 17:08 ` dje at gcc dot gnu.org
2010-12-21 18:37 ` sgk at troutmask dot apl.washington.edu
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: dje at gcc dot gnu.org @ 2010-12-21 17:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
2010-12-21 16:42 ` [Bug target/47032] " kargl at gcc dot gnu.org
2010-12-21 17:08 ` dje at gcc dot gnu.org
@ 2010-12-21 18:37 ` sgk at troutmask dot apl.washington.edu
2010-12-28 16:10 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2010-12-21 18:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
` (2 preceding siblings ...)
2010-12-21 18:37 ` sgk at troutmask dot apl.washington.edu
@ 2010-12-28 16:10 ` rguenth at gcc dot gnu.org
2011-01-06 19:15 ` dje at gcc dot gnu.org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2010-12-28 16:10 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
` (3 preceding siblings ...)
2010-12-28 16:10 ` rguenth at gcc dot gnu.org
@ 2011-01-06 19:15 ` dje at gcc dot gnu.org
2011-01-25 20:34 ` michael.haubenwallner at salomon dot at
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: dje at gcc dot gnu.org @ 2011-01-06 19:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
` (4 preceding siblings ...)
2011-01-06 19:15 ` dje at gcc dot gnu.org
@ 2011-01-25 20:34 ` michael.haubenwallner at salomon dot at
2011-02-04 5:16 ` rwild at gcc dot gnu.org
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: michael.haubenwallner at salomon dot at @ 2011-01-25 20:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
` (5 preceding siblings ...)
2011-01-25 20:34 ` michael.haubenwallner at salomon dot at
@ 2011-02-04 5:16 ` rwild at gcc dot gnu.org
2011-02-08 20:49 ` pogma at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rwild at gcc dot gnu.org @ 2011-02-04 5:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
` (6 preceding siblings ...)
2011-02-04 5:16 ` rwild at gcc dot gnu.org
@ 2011-02-08 20:49 ` pogma at gcc dot gnu.org
2011-02-08 20:55 ` sgk at troutmask dot apl.washington.edu
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pogma at gcc dot gnu.org @ 2011-02-08 20:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
` (7 preceding siblings ...)
2011-02-08 20:49 ` pogma at gcc dot gnu.org
@ 2011-02-08 20:55 ` sgk at troutmask dot apl.washington.edu
2011-02-08 21:04 ` pogma at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2011-02-08 20:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
` (8 preceding siblings ...)
2011-02-08 20:55 ` sgk at troutmask dot apl.washington.edu
@ 2011-02-08 21:04 ` pogma at gcc dot gnu.org
2011-02-08 22:24 ` michael.haubenwallner at salomon dot at
2011-02-12 15:08 ` burnus at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: pogma at gcc dot gnu.org @ 2011-02-08 21:04 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
` (9 preceding siblings ...)
2011-02-08 21:04 ` pogma at gcc dot gnu.org
@ 2011-02-08 22:24 ` michael.haubenwallner at salomon dot at
2011-02-12 15:08 ` burnus at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: michael.haubenwallner at salomon dot at @ 2011-02-08 22:24 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/47032] libgfortran references complex long double functions missing on AIX
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
` (10 preceding siblings ...)
2011-02-08 22:24 ` michael.haubenwallner at salomon dot at
@ 2011-02-12 15:08 ` burnus at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-02-12 15:08 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-02-12 15:05 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-21 16:22 [Bug libfortran/47032] New: libgfortran references complex long double functions missing on AIX dje at gcc dot gnu.org
2010-12-21 16:42 ` [Bug target/47032] " kargl at gcc dot gnu.org
2010-12-21 17:08 ` dje at gcc dot gnu.org
2010-12-21 18:37 ` sgk at troutmask dot apl.washington.edu
2010-12-28 16:10 ` rguenth at gcc dot gnu.org
2011-01-06 19:15 ` dje at gcc dot gnu.org
2011-01-25 20:34 ` michael.haubenwallner at salomon dot at
2011-02-04 5:16 ` rwild at gcc dot gnu.org
2011-02-08 20:49 ` pogma at gcc dot gnu.org
2011-02-08 20:55 ` sgk at troutmask dot apl.washington.edu
2011-02-08 21:04 ` pogma at gcc dot gnu.org
2011-02-08 22:24 ` michael.haubenwallner at salomon dot at
2011-02-12 15:08 ` burnus at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).