public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
Date: Tue, 08 Dec 2020 14:09:04 +0000	[thread overview]
Message-ID: <bug-97653-4-f62SOdwB0G@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-97653-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This was committed, but with the wrong PR number so didn't get added here:


The master branch has been updated by Michael Meissner <meissner@gcc.gnu.org>:

https://gcc.gnu.org/g:9f1a6501994a2d18ec4fe2a6664637f48021b210

commit r11-5728-g9f1a6501994a2d18ec4fe2a6664637f48021b210
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Thu Dec 3 14:50:26 2020 -0500

    PowerPC: PR libgcc/97543 and libgcc/97643, fix long double issues

    If you use a compiler with long double defaulting to 64-bit instead of
128-bit
    with IBM extended double, you get linker warnings about mis-matches in the
gnu
    attributes for long double (PR libgcc/97543).  Even if the compiler is
    configured to have long double be 64 bit as the default with the
configuration
    option '--without-long-double-128' you get the warnings.

    You also get the same issues if you use a compiler with long double
defaulting
    to IEEE 128-bit instead of IBM extended double (PR libgcc/97643).

    The issue is the way libgcc.a/libgcc.so is built.  Right now when building
    libgcc under Linux, the long double size is set to 128-bits when building
    libgcc.  However, the gnu attributes are set, leading to the warnings.

    One feature of the current GNU attribute implementation is if you have a
shared
    library (such as libgcc_s.so), the GNU attributes for the shared library is
an
    inclusive OR of all of the objects within the library.  This means if any
    object file that uses the -mlong-double-128 option and uses long double,
the GNU
    attributes for the library will indicate that it uses 128-bit IBM long
    doubles.  If you have a static library, you will get the warning only if
you
    actually reference an object file  with the attribute set.

    This patch does two things:

        1)  All of the object files that support IBM 128-bit long doubles
            explicitly set the ABI to IBM extended double.

        2)  I turned off GNU attributes for building the shared library or for
            building the IBM 128-bit long double support.

    libgcc/
    2020-12-03  Michael Meissner  <meissner@linux.ibm.com>

            PR libgcc/97543
            PR libgcc/97643
            * config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable.
            (IBM128_SHARED_OBJS): New make variable.
            (IBM128_OBJS): New make variable.  Set all objects to use the
            explicit IBM format, and disable gnu attributes.
            (IBM128_CFLAGS): New make variable.
            (gcc_s_compile): Add -mno-gnu-attribute to all shared library
            modules.

  parent reply	other threads:[~2020-12-08 14:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-31  8:57 [Bug target/97653] New: " redi at gcc dot gnu.org
2020-10-31  8:58 ` [Bug target/97653] " redi at gcc dot gnu.org
2020-10-31  9:00 ` redi at gcc dot gnu.org
2020-10-31  9:12 ` redi at gcc dot gnu.org
2020-11-03 19:51 ` meissner at gcc dot gnu.org
2020-11-03 19:58 ` meissner at gcc dot gnu.org
2020-11-04 12:02 ` redi at gcc dot gnu.org
2020-12-08 14:09 ` redi at gcc dot gnu.org [this message]
2021-01-21  1:41 ` meissner at gcc dot gnu.org
2021-01-21  1:44 ` meissner at gcc dot gnu.org
2021-03-23 18:07 ` redi at gcc dot gnu.org
2021-03-23 18:08 ` redi at gcc dot gnu.org
2021-03-30 11:28 ` jakub at gcc dot gnu.org
2021-03-30 11:44 ` redi at gcc dot gnu.org
2021-03-30 11:49 ` redi at gcc dot gnu.org
2021-03-30 12:02 ` jakub at gcc dot gnu.org
2021-03-31 10:58 ` [Bug target/97653] [11 Regression] " jakub at gcc dot gnu.org
2021-03-31 11:59 ` jakub at gcc dot gnu.org
2021-03-31 12:24 ` jakub at gcc dot gnu.org
2021-04-03  8:06 ` cvs-commit at gcc dot gnu.org
2021-04-03  8:16 ` jakub at gcc dot gnu.org
2021-04-20  9:45 ` cvs-commit at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-97653-4-f62SOdwB0G@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).