[Bug libstdc++/105417] New: [11/12 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[Bug libstdc++/105417] New: [11/12 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[jakub at gcc dot gnu.org]

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

            Bug ID: 105417
           Summary: [11/12 Regression] powerpc64le-linux abilist changes
                    based on --with-long-double-format=
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

If I build on glibc 2.34 powerpc64le-linux gcc with
--enable-languages=c,c++ --disable-libsanitizer --disable-multilib
--with-long-double-format=ibm --with-long-double-128 --disable-bootstrap
vs.
--enable-languages=c,c++ --disable-libsanitizer --disable-multilib
--with-long-double-format=ieee --with-long-double-128 --disable-bootstrap
I get a different set of exported symbols.
In current releases/gcc-11 (i.e. 11.3.1) the difference from the former to the
latter is:
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
-_ZSt8to_charsPcS_u9__ieee128@@GLIBCXX_IEEE128_3.4.29 FUNC GLOBAL DEFAULT
-_ZSt8to_charsPcS_u9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29 FUNC
GLOBAL DEFAULT
-_ZSt8to_charsPcS_u9__ieee128St12chars_formati@@GLIBCXX_IEEE128_3.4.29 FUNC
GLOBAL DEFAULT

and on latest trunk the difference is just:
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT

The removed symbols for the ieee configuration in 11.3 got fixed on the trunk,
they are exported in both, but the extra symbols are only present in the ieee
builds.
I think we should make sure they are exported also in the ibm builds (of course
only if glibc is new enough, for old glibc there are no @@GLIBCXX_IEEE128* and
no @@CXXABI_IEEE128* symbols.

[Bug libstdc++/105417] [11/12 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-04-28
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Target Milestone|---                         |11.4

[Bug libstdc++/105417] [11/12 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #0)
> The removed symbols for the ieee configuration in 11.3 got fixed on the
> trunk,

That was r12-7225-g813415650235b8

[Bug libstdc++/105417] [11/12 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So I think we want that backported to 11.4.  And I think we just should export
the other symbols with the 3.4.29 version, adding 3.4.30 aliases for those
wouldn't improve things.

[Bug libstdc++/105417] [11/12 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>From what I can see, the --with-long-double-format=ibm libstdc++.a has
following _M_extract_int symbols (for simplicity only listing Ij symbols,
I[lmtxy] are present/absent next to it:
compatibility-ldbl-alt128.o:
0000000000000000 W
_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
0000000000000000 W
_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
cxx11-locale-inst.o:
0000000000000000 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
cxx11-wlocale-inst.o:
0000000000000000 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
locale-inst.o:
0000000000000000 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
0000000000000000 W
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_
wlocale-inst.o:
0000000000000000 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
0000000000000000 W
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_

while --with-long-double-format=ieee libstdc++.a has:
compatibility-ldbl-alt128.o:
0000000000000000 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
0000000000000000 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
0000000000000000 W
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_
0000000000000000 W
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_
cxx11-locale-inst.o:
0000000000000000 W
_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
cxx11-wlocale-inst.o:
0000000000000000 W
_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
locale-inst.o:
0000000000000000 W
_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
wlocale-inst.o:
0000000000000000 W
_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_

Now, the symbols in compatibility-ldbl-alt128.o and {,w}locale-inst.o match
between the 2 builds, basically for each narrow and wide we export all of
std::num_get, std::__gnu_cxx_ldbl128::num_get and
std::__gnu_cxx_ieee128::num_get symbols.
But the cxx11 ABI symbols are not.
On x86_64, I see we have
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_
in cxx11-locale-inst.o and
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_
in cxx11-wlocale-inst.o, but we don't export those, similarly we don't export
those
_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
and
_ZNKSt17__gnu_cxx_ldbl1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
on targets which switched long double from double to something wider in the
past (including powerpc64*), but we do export the __gnu_cxx_ieee128 ones, which
is
why we get those extra symbols on --with-long-double-format=ieee builds.
Are those cxx11 symbols never needed and so it was a mistake that they've been
exported?
Or is it an omission that they are not exported?

[Bug libstdc++/105417] [11/12/13 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> Are those cxx11 symbols never needed and so it was a mistake that they've
> been exported?

I thought they were needed, but I've now convinced myself they aren't. The
public headers do not declare explicit instantiations for those symbols, so
user code doesn't know that they're (sometimes) defined in libstdc++.so and so
user code will contain implicit instantiations of them. So the definitions
exported from the library are never needed outside the library itself.

[Bug libstdc++/105417] [11/12/13 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 52905
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52905&action=edit
Add alias symbols for the missing exports

[Bug libstdc++/105417] [11/12/13 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Comment on attachment 52905
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52905
Add alias symbols for the missing exports

Shouldn't the #if 1 be wropped?
On the other side, perhaps wrap the wchar_t stuff in
#ifdef _GLIBCXX_USE_WCHAR_T
just for consistency?

[Bug libstdc++/105417] [11/12/13 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> Shouldn't the #if 1 be wropped?

Yeah, that's gone in the real patch I'm testing.

> On the other side, perhaps wrap the wchar_t stuff in
> #ifdef _GLIBCXX_USE_WCHAR_T
> just for consistency?

Yes, I suppose it should. That macro should always be defined for
powerpc64le-*-linux-gnu because we know we have a Glibc that isn't from the
last millennium, but it's possible somebody wants to use --disable-wchar_t for
some reason.

[Bug libstdc++/105417] [11/12/13 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:bb7cf39b05a216431a431499d0c36a6034f6acc4

commit r13-45-gbb7cf39b05a216431a431499d0c36a6034f6acc4
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Apr 29 12:17:13 2022 +0100

    libstdc++: Add missing exports for ppc64le --with-long-double-format=ibm
[PR105417]

    The --with-long-double-abi=ibm build is missing some exports that are
    present in the --with-long-double-abi=ieee build. Those symbols never
    should have been exported at all, but now that they have been, they
    should be exported consistently by both ibm and ieee.

    This simply defines them as aliases for equivalent symbols that are
    already present. The abi-tag on num_get::_M_extract_int isn't really
    needed, because it only uses a std::string as a local variable, not in
    the return type or function parameters, so it's safe to define the
    _M_extract_int[abi:cxx11] symbols as aliases for the corresponding
    function without the abi-tag.

    This causes some new symbols to be added to the GLIBCXX_3.4.29 version
    for the ibm long double build mode, but there is no advantage to adding
    them to 3.4.30 for that build. That would just create more
    inconsistencies.

    libstdc++-v3/ChangeLog:

            PR libstdc++/105417
            * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt:
            Regenerate.
            * src/c++11/compatibility-ldbl-alt128.cc [_GLIBCXX_USE_DUAL_ABI]:
            Define __gnu_ieee128::num_get<C>::_M_extract_int[abi:cxx11]<I>
            symbols as aliases for corresponding symbols without abi-tag.

[Bug libstdc++/105417] [11/12/13 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:621650f64fb6679c457c33abf27c925f28bddc62

commit r12-8321-g621650f64fb6679c457c33abf27c925f28bddc62
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Apr 29 12:17:13 2022 +0100

    libstdc++: Add missing exports for ppc64le --with-long-double-format=ibm
[PR105417]

    The --with-long-double-abi=ibm build is missing some exports that are
    present in the --with-long-double-abi=ieee build. Those symbols never
    should have been exported at all, but now that they have been, they
    should be exported consistently by both ibm and ieee.

    This simply defines them as aliases for equivalent symbols that are
    already present. The abi-tag on num_get::_M_extract_int isn't really
    needed, because it only uses a std::string as a local variable, not in
    the return type or function parameters, so it's safe to define the
    _M_extract_int[abi:cxx11] symbols as aliases for the corresponding
    function without the abi-tag.

    This causes some new symbols to be added to the GLIBCXX_3.4.29 version
    for the ibm long double build mode, but there is no advantage to adding
    them to 3.4.30 for that build. That would just create more
    inconsistencies.

    libstdc++-v3/ChangeLog:

            PR libstdc++/105417
            * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt:
            Regenerate.
            * src/c++11/compatibility-ldbl-alt128.cc [_GLIBCXX_USE_DUAL_ABI]:
            Define __gnu_ieee128::num_get<C>::_M_extract_int[abi:cxx11]<I>
            symbols as aliases for corresponding symbols without abi-tag.

    (cherry picked from commit bb7cf39b05a216431a431499d0c36a6034f6acc4)

[Bug libstdc++/105417] [11 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13 Regression]       |[11 Regression]
                   |powerpc64le-linux abilist   |powerpc64le-linux abilist
                   |changes based on            |changes based on
                   |--with-long-double-format=  |--with-long-double-format=

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for trunk and 12, backport to 11 still needed.

[Bug libstdc++/105417] [11 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.