Bug 98389 - [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian
Summary: [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 11.0
: P1 normal
Target Milestone: 11.0
Assignee: Jonathan Wakely
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-19 07:09 UTC by seurer
Modified: 2021-03-23 11:14 UTC (History)
7 users (show)

See Also:
Host: powerpc64-linux-gnu
Target: powerpc64-linux-gnu
Build: powerpc64-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2020-12-19 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description seurer 2020-12-19 07:09:00 UTC
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
Comment 1 Andreas Schwab 2020-12-19 09:01:53 UTC
The list just needs to be updated.
Comment 2 Jonathan Wakely 2020-12-19 13:58:44 UTC
(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.
Comment 3 Jonathan Wakely 2021-02-19 15:18:52 UTC
(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.
Comment 4 Jakub Jelinek 2021-02-19 15:37:08 UTC
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
Comment 5 CVS Commits 2021-02-24 17:00:05 UTC
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.
Comment 6 Jonathan Wakely 2021-02-24 17:01:03 UTC
Fixed now.
Comment 7 Jonathan Wakely 2021-03-23 11:12:09 UTC
(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.
Comment 8 Jonathan Wakely 2021-03-23 11:13:53 UTC
(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" :-)
Comment 9 Jakub Jelinek 2021-03-23 11:14:51 UTC
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.