This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: AIX vs long double


On 01/-10/-28163 08:59 PM, David Edelsohn wrote:
> AIX provides two versions of long double and declares all of the C99
> long double symbols in math.h header file.  One implementation aliases
> long double to IEEE double precision type and the other implementation
> aliases long double to IBM's paired double format.  All of the C99
> symbols for IEEE double precision are implemented in libm, but not all
> of the C99 symbols for the IBM long double format are implemented.
> 
> IBM's proprietary XL compiler (cc, xlc) defaults to IEEE double
> precision and provides a special invocation to default to IBM long
> double (cc128, xlc128).
> 
> GNU/Linux and GCC on GNU/Linux default to IEEE quad precision long double.

Just to make sure I got the type names for the different bitwidths right:
IEEE double precision: 64bit
IEEE quad precision:  128bit
IBM's paired double:  128bit, identical to IEEE quad precision?

> Because the long double choice is an ABI change, GCC on AIX switched
> to GNU/Linux compatibility with support for AIX 6.1, before the
> incomplete implementation was noticed.  This mostly worked until

Well, even that change still is incomplete within gcc, as it should link
against libc128 before libc, because even printf("%Lf") is broken right
now when not explicitly adding '-lc128' to the linkline.

Reading bug [target/19115], the reason for that switch seems not to have
been Linux compatibility at all, but AIX libc providing 128bit math functions
frexpl, ldexpl and modfl before they went into C99 standard, and including
<math.h> might have been missing somewhere within libstdc++ to get their
correct implementation for the selected long double bitwidth.

> libgfortran started using additional C99 functions, causing GCC
> Bugzilla
> 
> [target/47032] libgfortran references complex long double functions
> missing on AIX
> 
> libstdc++-v3 on AIX builds with AIX long double support,

IMO, long double bitwidth should be another multilib criterion on AIX,
selected by -mlong-double-64 and -mlong-double-128.

As there are a bunch of multilib criterions on AIX already:
Even on AIX 5.3 I get the impression that there is no need for "pthread"
being a multilib criterion any more, as /usr/lib/threads/libc.a is a symlink
to /usr/ccs/lib/libc.a - but I may be wrong here wrt STARTFILE_SPEC.

> although user
> programs that try to access the missing functions (copysign,
> nextafter, etc.) will experience link-time failures.  libgfortran on
> AIX fails to build with AIX long double support because it accesses
> the missing functions in its implementation.
> 
> I would like to solicit feedback about how to proceed: Should GCC on
> AIX revert back to 64 bit long double size, allowing all libraries to
> build and work, but breaking GCC/G++ ABI on AIX? Or should it continue
> to utilize 128 bit long double, building libstdc++-v3 that works if
> the user program does not utilize the missing symbols and fails to
> build libgfortran?

Please remember that even printf is broken on AIX 6.1 now. I doubt
people (know to) add '-lc128' when building with gcc on AIX 6.1 at all.

And not having the gcc-libraries with long-double-64 support available
prevents mixing gcc-built libraries with xlc-built libraries.

FWIW: For C++, AIX 6.1 <math.h> defines public inline functions to rename math
functions (except frexpl, ldexpl, modfl) to the __FFl128 variant. This does
not work with gcc when building with -O0, as they result in weak symbols, being
ignored at linktime due to static symbols from libm.a with original name and
using 64bit long double. This is reported to IBM and I got confirmation last
week that they're working on how to fix it.

Thank you!
/haubi/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]