[Bug libgcc/104859] New: [12 regression] liibg++ fails during bootstrap

[Bug libgcc/104859] New: [12 regression] liibg++ fails during bootstrap

[seurer at gcc dot gnu.org]

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

            Bug ID: 104859
           Summary: [12 regression] liibg++ fails during bootstrap
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Seen with g:bded0d549fdfdc1328b2c0189dc5f8593b4cbe42 r12-7566-gbded0d549fdfdc
but that is probably not the source.  I am still bisecting this but as it is
breaking the build I thought I should open it right away.

libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-shared-libgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-m32 -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/../libgcc
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=floating_to_chars.lo -fimplicit-templates -g -O2
-D_GNU_SOURCE -m32 -c
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc 
-fPIC -DPIC -D_GLIBCXX_SHARED -o floating_to_chars.o
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc: In
instantiation of 'std::to_chars_result std::__floating_to_chars_hex(char*,
char*, T, optional<int>) [with T = long double]':
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc:926:37:
  required from 'std::to_chars_result std::__floating_to_chars_shortest(char*,
char*, T, chars_format) [with T = long double]'
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc:1612:40:
  required from here
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc:804:52:
error: cannot convert '{anonymous}::uint128_t' to 'const unsigned int' in
initialization
  804 |         const unsigned nibble = effective_mantissa >>
rounded_mantissa_bits;
      |                                
~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
      |                                                    |
      |                                                   
{anonymous}::uint128_t
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc:856:56:
error: cannot convert '{anonymous}::uint128_t' to 'const unsigned int' in
initialization
  856 |             const unsigned nibble = effective_mantissa >>
nibble_offset;
      |                                     ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
      |                                                        |
      |                                                       
{anonymous}::uint128_t
make[9]: *** [floating_to_chars.lo] Error 1

[Bug libgcc/104859] [12 regression] liibg++ fails during bootstrap

[seurer at gcc dot gnu.org]

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Looks like this is BE only.  And the bisect points here:

commit e32869a17b788bee9ca782b174a546b1db17b5ea
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Mar 9 08:42:32 2022 -0500

    c++: detecting copy-init context during CTAD [PR102137]

[Bug c++/104859] [12 regression] liibg++ fails during bootstrap

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What stage is the bootstrap at while the error happens?

[Bug c++/104859] [12 regression] liibg++ fails during bootstrap

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
stage 1.  It happens on a non-bootstrap, too.

[Bug c++/104859] [12 regression] liibg++ fails during bootstrap

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to seurer from comment #3)
> stage 1.  It happens on a non-bootstrap, too.

I was worried that it was causing wrong code in the front-end.
Can you attach the preprocessed source for floating_to_chars.cc ?

[Bug c++/104859] [12 regression] liibg++ fails during bootstrap

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2022-03-09

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
I think we just need to add some explicit casts:

diff --git a/libstdc++-v3/src/c++17/floating_to_chars.cc
b/libstdc++-v3/src/c++17/floating_to_chars.cc
index 5825e661bf4..0ccf2623511 100644
--- a/libstdc++-v3/src/c++17/floating_to_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_to_chars.cc
@@ -801,14 +801,14 @@ template<typename T>
     char leading_hexit;
     if constexpr (has_implicit_leading_bit)
       {
-       const unsigned nibble = effective_mantissa >> rounded_mantissa_bits;
+       const unsigned nibble = unsigned(effective_mantissa >>
rounded_mantissa_bits);
        __glibcxx_assert(nibble <= 2);
        leading_hexit = '0' + nibble;
        effective_mantissa &= ~(mantissa_t{0b11} << rounded_mantissa_bits);
       }
     else
       {
-       const unsigned nibble = effective_mantissa >>
(rounded_mantissa_bits-4);
+       const unsigned nibble = unsigned(effective_mantissa >>
(rounded_mantissa_bits-4));
        __glibcxx_assert(nibble < 16);
        leading_hexit = "0123456789abcdef"[nibble];
        effective_mantissa &= ~(mantissa_t{0b1111} <<
(rounded_mantissa_bits-4));
@@ -853,7 +853,7 @@ template<typename T>
        while (effective_mantissa != 0)
          {
            nibble_offset -= 4;
-           const unsigned nibble = effective_mantissa >> nibble_offset;
+           const unsigned nibble = unsigned(effective_mantissa >>
nibble_offset);
            __glibcxx_assert(nibble < 16);
            *first++ = "0123456789abcdef"[nibble];
            ++written_hexits;

since on targets which lack __int128, effective_mantissa can be the
integer-class uint128_t, which unlike __int128 is only _explicitly_ convertible
to the builtin integer types.   And r12-7563-ge32869a17b788b made us correctly
exclude explicit conversion operators during copy-initialization.

[Bug c++/104859] [12 regression] liibg++ fails during bootstrap

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm more suprised that this ever worked.
For 32-bit libstdc++, there is no unsigned __int128 support, so it uses
uint128_t.h instead, but that class doesn't have conversion operator to
unsigned.
Wonder if
  constexpr explicit
  operator unsigned() const
  { return unsigned(lo); }
shouldn't be added to the header and then spots like
const unsigned nibble = effective_mantissa >> rounded_mantissa_bits;
be replaced with
const unsigned nibble = {effective_mantissa >> rounded_mantissa_bits};

[Bug c++/104859] [12 regression] liibg++ fails during bootstrap

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Oops, sorry, there is
  template<typename T, typename = std::enable_if_t<std::is_integral_v<T>>>
    constexpr explicit
    operator T() const
    {
      static_assert(sizeof(T) <= sizeof(uint64_t));
      return static_cast<T>(lo);
    }
but it is explicit so an explicit cast is needed.

[Bug libstdc++/104859] [12 regression] liibg++ fails during bootstrap

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:65857caee8ccfac5007a9fd0e5f18cce5e5fe934

commit r12-7571-g65857caee8ccfac5007a9fd0e5f18cce5e5fe934
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Mar 9 18:48:52 2022 -0500

    libstdc++: Avoid implicit narrowing from uint128_t [PR104859]

    We need to be explicit about narrowing conversions from uint128_t since,
    on targets that lack __int128, this type is defined as an integer-class
    type that is only _explicitly_ convertible to the builtin integer types.
    This issue was latent until r12-7563-ge32869a17b788b made the frontend
    correctly reject explicit conversion functions during (dependent)
    copy-initialization.

            PR libstdc++/104859

    libstdc++-v3/ChangeLog:

            * src/c++17/floating_to_chars.cc (__floating_to_chars_hex):
            Be explicit when narrowing the shifted effective_mantissa,
            since it may have an integer-class type.

[Bug libstdc++/104859] [12 regression] liibg++ fails during bootstrap

[ppalka at gcc dot gnu.org]

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

--- Comment #9 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Should be fixed now, sorry for the build breakage.

I suppose we might want to also backport this fix to the 11 branch.

[Bug libstdc++/104859] [11 Regression] libg++ fails during bootstrap

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12 regression] liibg++     |[11 Regression] libg++
                   |fails during bootstrap      |fails during bootstrap
   Target Milestone|12.0                        |11.3

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
re-targeting then

[Bug libstdc++/104859] [11 Regression] libg++ fails during bootstrap

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug libstdc++/104859] [11 Regression] libg++ fails during bootstrap

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #9)
> I suppose we might want to also backport this fix to the 11 branch.

Please do so before the 11.3.0 release candidate next week.

[Bug libstdc++/104859] [11 Regression] libg++ fails during bootstrap

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

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

commit r11-9798-gc859c99a85b8743b2c1edc097c6f6406de337f45
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Mar 9 18:48:52 2022 -0500

    libstdc++: Avoid implicit narrowing from uint128_t [PR104859]

    We need to be explicit about narrowing conversions from uint128_t since,
    on targets that lack __int128, this type is defined as an integer-class
    type that is only _explicitly_ convertible to the builtin integer types.
    This issue was latent until r12-7563-ge32869a17b788b made the frontend
    correctly reject explicit conversion functions during (dependent)
    copy-initialization.

            PR libstdc++/104859

    libstdc++-v3/ChangeLog:

            * src/c++17/floating_to_chars.cc (__floating_to_chars_hex):
            Be explicit when narrowing the shifted effective_mantissa,
            since it may have an integer-class type.

    (cherry picked from commit 65857caee8ccfac5007a9fd0e5f18cce5e5fe934)

[Bug libstdc++/104859] [11 Regression] libg++ fails during bootstrap

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

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

--- Comment #13 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Patrick Palka from comment #9)
> > I suppose we might want to also backport this fix to the 11 branch.
> 
> Please do so before the 11.3.0 release candidate next week.

Done, thus fixed for GCC 11.3/12.