From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jwakely.gcc@gmail.com>
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [IPv6:2a00:1450:4864:20::533])
 by sourceware.org (Postfix) with ESMTPS id 852E7385801C
 for <gcc@gcc.gnu.org>; Thu,  4 Aug 2022 21:14:22 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 852E7385801C
Received: by mail-ed1-x533.google.com with SMTP id b16so1200359edd.4
 for <gcc@gcc.gnu.org>; Thu, 04 Aug 2022 14:14:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=wYRS4sa9mqCd/2njmNITqmIaHvlwD1sY7RIAAJoEO68=;
 b=WoYAk+eQZeyvpfefMmG5enPa6Xx9TX3DhRUvr9nTjMXwIU+kd1RNDXMtPZ3lNzC88l
 QELI8nXyDInuuPM5qv0IiMieAWIpeYsr5TiRTR8elGbpsrbIPnJgUmGHGIdGdKG9Dqqb
 4I+5J6aG1QMj7n0lJBDB7Nxqrp3/EF32YubSQHKMkvLco+s5UK/HwbeZANquVYN7KcGZ
 JoVw3rvK0m1LUfwmr/SmpVFLcsRpeHnknNOjtbI8ACb9EbABQLkE5F75SUcmEd+4rfal
 hTx1e5dK6HjDeya6ZZYBu24Whc1C63wUD+g/SxcccryPz1DxrpXrdixIU9vKEJvhYCXp
 EieA==
X-Gm-Message-State: ACgBeo2RK71MqFBFqz7wWr93WTtGDGMY0ovuHmfJOap0T16a49uHMsao
 yXTpKiHdEll5FQ+aV9x4GzPOEfLWTqtLAk7MyNE=
X-Google-Smtp-Source: AA6agR4SM4gvhUUp8lo4e3rsWKHbqB54VfCiE1OKQba02/l6IS/zTlI94u/n3+9uRKupNqfLzc+IScjHjDNUmSNnq78=
X-Received: by 2002:a05:6402:524a:b0:43d:aa71:33d8 with SMTP id
 t10-20020a056402524a00b0043daa7133d8mr3945780edd.33.1659647661340; Thu, 04
 Aug 2022 14:14:21 -0700 (PDT)
MIME-Version: 1.0
References: <Yur08LUHAfJvQg9l@toto.the-meissners.org>
 <CAAJqyv4_RQ=di2WcDN+n0j4rWQQNtcnaT_6MkyFHie9oDQY1bg@mail.gmail.com>
 <YuwIqy6LxB1KlHLr@toto.the-meissners.org>
In-Reply-To: <YuwIqy6LxB1KlHLr@toto.the-meissners.org>
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Thu, 4 Aug 2022 22:14:10 +0100
Message-ID: <CAH6eHdR8FAnRP4CvDtHHqo3DSk2JrpLUbR3ueHMQPK-Mb35zJg@mail.gmail.com>
Subject: Re: Potential upcoming changes in mangling to PowerPC GCC
To: Michael Meissner <meissner@linux.ibm.com>, Nathan Sidwell <nathan@acm.org>,
 GCC Development <gcc@gcc.gnu.org>,
 Segher Boessenkool <segher@kernel.crashing.org>, 
 "Kewen.Lin" <linkw@linux.ibm.com>, David Edelsohn <dje.gcc@gmail.com>, 
 Peter Bergner <bergner@linux.ibm.com>, Will Schmidt <will_schmidt@vnet.ibm.com>,
 Jason Merrill <jason@redhat.com>, Mike Stump <mikestump@comcast.net>, 
 Iain Sandoe <iain@sandoe.co.uk>, Joseph Myers <joseph@codesourcery.com>, 
 Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>,
 Alan Modra <amodra@gmail.com>, Nick Clifton <nickc@redhat.com>, 
 Jeff Law <jlaw@tachyum.com>, Jakub Jelinek <jakub@redhat.com>,
 Richard Biener <rguenther@suse.de>, 
 "David S. Miller" <davem@redhat.com>, "Carlos O'Donell" <carlos@redhat.com>, 
 GNU C Library <libc-alpha@sourceware.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_MANYTO,
 RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: gcc@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2022 21:14:24 -0000

On Thu, 4 Aug 2022 at 18:58, Michael Meissner via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Thu, Aug 04, 2022 at 10:49:24AM +0200, Nathan Sidwell wrote:
> > Not a problem. I don't think I have anything to add- I presume you've
> > thought about (weak) aliases to deal with the problematic changes you
> > mention towards the end?
>
> I've thought about it.  I know in the past we had weak aliases to do the
> support the same way when we had the last name mangling change.  I know those
> aliases weren't popular back then.
>
> Part of the reason for asking is I don't have a sense for how library
> maintainers use the __float128 and __ibm128 keywords.  Do they treat them as
> full fledged types, or are they just convenient ways to compile code with both
> names rather than building two modules, with the different long double types?


Within libstdc++ it's not just a minor convenience, it's 100%
necessary to refer to both kinds (IEEE 128 and IBM 128) in the same
translation unit. There are C++ classes with member functions taking
both types, e.g.

struct Foo {
  void f(__ibm128);
  void f(__ieee128);
};

You can't do this by "building two modules" because it's a header and
you can't split the definition of a class across two different files.
And in many cases, it's a class template, so you can't even hide the
definition of the function in a .cc file, it has to be defined in the
header. So libstdc++ 100% requires a way to refer to "the type that is
long double" (which is easy, that's 'long double') and "the other
128-bit type that isn't long double" (which is one of __ibm128 or
__ieee128). So we need to refer to *at least* one of __ibm128 or
__ieee128, and in some cases it's simpler to not refer to 'long
double' at all (because its meaning can change) and just refer to
__ibm128 and __ieee128 because those always mean the same thing.

If the names or mangling for either of those types changes, it would
break libstdc++ and require more work just to restore the existing
functionality.