From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32574 invoked by alias); 15 Nov 2010 11:13:46 -0000 Received: (qmail 32565 invoked by uid 22791); 15 Nov 2010 11:13:45 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Nov 2010 11:12:51 +0000 From: "michael.haubenwallner at salomon dot at" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/46481] New: long double should default to 64bit even for aix6.1 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: michael.haubenwallner at salomon dot at X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 15 Nov 2010 11:22:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-11/txt/msg01864.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46481 Summary: long double should default to 64bit even for aix6.1 Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned@gcc.gnu.org ReportedBy: michael.haubenwallner@salomon.at For AIX6.1, long double was changed from 64 to 128bit by default since gcc-4.2.4 as of bug#19115. It seems the reason to do so was because frexpl() in libc.a expects 128bit. But this is a known bug in libc.a, and thus should not be the reason to switch to 128bit by default. There is a static 64bit frexpl() replacement in math.h (attachment#15004, bug#34794 comment#5) to work around this bug: > /* > * frexpl(), ldexpl(), and modfl() have preexisting shared versions which are > * 128-bit only. 64-bit versions must be made available for C99 for the > * default 64-bit long double. These cannot simply be macros because the > * actual routines will be the incorrect form in 64-bit mode if the user > * forces the actual routines to be used through undef or macro suppression > * per the standard. > */ So the proper fix for bug#19115 would have been to use the working replacement of frexpl() in libstdc++ - but AFAICS this is not a problem any more. Another reason: Passing a 128bit long double to printf("%Lf") breaks subsequent (at least) arguments when not linked against libc128.a. The manpage printf(3) on AIX says: > Library > Standard C Library (libc.a) or the Standard C Library with 128-Bit long > doubles (libc128.a) as well as: > * An optional L specifying that a following e, E, f, > g, or G conversion specifier applies to a long > double parameter. If linked with libc.a, long double > is the same as double (64bits). If linked with > libc128.a and libc.a, long double is 128 bits. Also, there is another important comment in math.h: > /* > * The following interfaces are available only for the > * non-default 128-bit long double mode. By default long > * double is the same as double (64-bit) and should use the > * the double precision versions of these routines. > * > * Many of these routine may not actually exist. The standards interfaces > * are redefined in 128-mode later in this file. The redefinitions are > * are added here to cause link errors rather than runtime errors > * when attempting to use these routines in 128-bit long double mode. > * Without these redefinitions the 64-bit versions in the libraries > * would be invoked at runtime. > */ So for now, I'd say 128bit long double support is still incomplete with gcc (if not with aix at all). Thank you!