From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 79458385829C for ; Thu, 4 Aug 2022 21:14:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 79458385829C Received: by mail-ed1-x52e.google.com with SMTP id m8so1169513edd.9 for ; 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=HhytPTqH9S+i7KkaSuiBwtQ7p9hbf6v494V4nKo3/kviyLyg8jcbpj/Zcw7GFkOoRX dxVTZ/nqj+LCLe3OAecj4KT8Av1ExCs9ipUq96Zk+eavWw+vyMwORrDjpE85rPkBL9hH UshMQ0V7pKC1r+ILvrtl3R7SR+s+myumNueVIfJi87rE/xUK5W4wsNLBbxkmQwqWkYBa E368Qrb4Erfm6A+GXME2Kl5/mYwES4qeLxx9iRCjYM5PrwoX7LUsUQx6fj3PEE0rbLkO lUnbA6QSfFdpRmHQ5sCVW8rUGADJzRivRCafa2Whr/b46en3s8naHjdYxOBVId8TE4Dr YcwA== X-Gm-Message-State: ACgBeo2MJaKzSWydnKi8o/vn1KP1GaTyXgJTvDIXK6ALmcVbDhHv34cu W7CzdM6LcEsDhbWp/3amBrevu4pvjNnkI+wAbA4= 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: In-Reply-To: From: Jonathan Wakely Date: Thu, 4 Aug 2022 22:14:10 +0100 Message-ID: Subject: Re: Potential upcoming changes in mangling to PowerPC GCC To: Michael Meissner , Nathan Sidwell , GCC Development , Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt , Jason Merrill , Mike Stump , Iain Sandoe , Joseph Myers , Tulio Magno Quites Machado Filho , Alan Modra , Nick Clifton , Jeff Law , Jakub Jelinek , Richard Biener , "David S. Miller" , "Carlos O'Donell" , GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.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=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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.