[Bug libstdc++/98389] New: [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[Bug libstdc++/98389] New: [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[seurer at gcc dot gnu.org]

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

            Bug ID: 98389
           Summary: [11 regression] libstdc++-abi/abi_check fails after
                    r11-6249 on powerpc64 big endian
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:3c57e692357c79ee7623dfc1586652aee2aefb8f, r11-6249: 89 failures

FAIL: libstdc++-abi/abi_check

This only fails on BE.


The output from this is extensive and I am not positive that these are what
cause the failures but they sound like possible failures:


2 undesignated symbols
0
_ZSt11__once_call
std::__once_call
version status: compatible
GLIBCXX_3.4.11
type: tls
type size: 8
status: undesignated

1
_ZSt15__once_callable
std::__once_callable
version status: compatible
GLIBCXX_3.4.11
type: tls
type size: 8
status: undesignated


3 incompatible symbols
0
_ZSt8to_charsPcS_g
std::to_chars(char*, char*, __float128)
version status: incompatible
GLIBCXX_3.4.29
type: function
status: added


1
_ZSt8to_charsPcS_gSt12chars_format
std::to_chars(char*, char*, __float128, std::chars_format)
version status: incompatible
GLIBCXX_3.4.29
type: function
status: added


2
_ZSt8to_charsPcS_gSt12chars_formati
std::to_chars(char*, char*, __float128, std::chars_format, int)
version status: incompatible
GLIBCXX_3.4.29
type: function
status: added


                ==== libstdc++-v3 check-abi Summary ====

# of added symbols:              109
# of missing symbols:            0
# of undesignated symbols:       2
# of incompatible symbols:       3

using: baseline_symbols.txt
FAIL: libstdc++-abi/abi_check

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[schwab@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
The list just needs to be updated.

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-12-19

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #1)
> The list just needs to be updated.

No, those have version GLIBCXX_3.4.29 which is the current version, so new
symbols are allowed there.

The problem is this check in testsuite/util/testsuite_abi.cc:

      // Check that long double compatibility symbols demangled as
      // __float128 and regular __float128 symbols are put into some _LDBL_
      // or _FLOAT128 version name.
      if (added && test.demangled_name.find("__float128") != std::string::npos
          && test.demangled_name.find("std::__cxx11::") != 0)

I need to think about what the right fix is here (to change the test, or the
symbol versions of those symbols). That's unlikely to happen until January.

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
           Priority|P3                          |P1

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to seurer from comment #0)
> 3 incompatible symbols
> 0
> _ZSt8to_charsPcS_g
> std::to_chars(char*, char*, __float128)


It took me a while to realise that these symbols are not __float128, they're
__ibm128, but the demangler turns 'g' into __float128.

Is that still the case for the latest version of the demangler? Because that's
very confusing.

The actual __float128 type mangles as '__u9__ieee128' not 'g', so if I define
"std::to_chars(char*, char*, __float128)" in my code, it doesn't get mangled as
shown above.

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The demangler does the right, although confusing thing.  Because the Itanium
ABI says that g is __float128:
                 ::= f  # float
                 ::= d  # double
                 ::= e  # long double, __float80
                 ::= g  # __float128

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 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:f90027d18a94d02ba8f3b7503c5f0835f432a89e

commit r11-7365-gf90027d18a94d02ba8f3b7503c5f0835f432a89e
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Feb 19 13:36:41 2021 +0000

    libstdc++: Define std::to_chars overloads for __ieee128 [PR 98389]

    This adds overloads of std::to_chars for powerpc64's __ieee128, so that
    std::to_chars can be used for long double when -mabi=ieeelongdouble is
    in used.

    Eventually we'll want to extend these new overloads to work for
    __float128 on all targets that support that type. For now, we're only
    doing it for powerpc64 when the new long double type is supported in
    parallel to the old long double type.

    Additionally the existing std::to_chars overloads for long double
    are given the right symbol version, resolving PR libstdc++/98389.

    libstdc++-v3/ChangeLog:

            PR libstdc++/98389
            * config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Do not match to_chars
            symbols for long double arguments mangled as 'g'.
            * config/os/gnu-linux/ldbl-extra.ver: Likewise.
            * config/os/gnu-linux/ldbl-ieee128-extra.ver: Likewise.
            * src/c++17/Makefile.am [GLIBCXX_LDBL_ALT128_COMPAT_TRUE]:
            Use -mabi=ibmlongdouble for floating_to_chars.cc.
            * src/c++17/Makefile.in: Regenerate.
            * src/c++17/floating_to_chars.cc (floating_type_traits_binary128):
            New type defining type traits of IEEE binary128 format.
            (floating_type_traits<__float128>): Define specialization.
            (floating_type_traits<long double>): Define in terms of
            floating_type_traits_binary128 when appropriate.
            (floating_to_shortest_scientific): Handle __float128.
            (sprintf_ld): New function template for printing a long double
            or __ieee128 value using sprintf.
            (__floating_to_chars_shortest, __floating_to_chars_precision):
            Use sprintf_ld.
            (to_chars): Define overloads for __float128.

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed now.

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> The demangler does the right, although confusing thing.  Because the Itanium
> ABI says that g is __float128:
> 		 ::= f	# float
> 		 ::= d	# double
> 		 ::= e	# long double, __float80
> 		 ::= g	# __float128

So if we had a time machine we could mangle double-double as 'u8__ibm128' and
then 'g' could be used for __float128 aka __ieee128, and the demangled names
would not be wildly confusing. But there's no way to do that now.

You just have to know that when compiler errors talk about __float128 they mean
__ieee128 and when linker errors talk about __float128 they mean __ibm128.

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #7)
> So if we had a time machine we could mangle double-double as 'u8__ibm128'

Or even 'u2dd' for "double double" :-)

[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If we had a time machine, I strongly hope that double double wouldn't exist at
all.  It is a fast but completely useless type without any usable numerical
properties.