[Bug libstdc++/105681] New: libstdc++-v3 fails to build on msp430

[Bug libstdc++/105681] New: libstdc++-v3 fails to build on msp430

[beagleboard at davidjohnsummers dot uk]

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

            Bug ID: 105681
           Summary: libstdc++-v3 fails to build on msp430
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: beagleboard at davidjohnsummers dot uk
  Target Milestone: ---

Hi, I'm trying to build gcc for an msp430 cpu, using gcc12.1.0 binuitils-2.38
and newlib-4.2.0.20211231. Now I can build c fine, but when I try to build c++
libstdc++-v3 fails, I think becuase the msp430 is only a 16bit processor.

The specific configure command used is:

../../gcc-git/configure --with-sysroot=/home/summers/msp430
--prefix=/home/summers/msp430  --target=msp430-elf --disable-nls
--disable-werror
--with-native-system-header-dir=/home/summers/msp430/msp430-elf/include
--with-newlib --enable-languages=c,c++ --disable-nls --enable-initfini-array
--enable-target-optspace --with-gmp --with-mpfr --with-mpc --with-isl
-enable-newlib-nano-malloc

This has binutils and newlib copied into the gcc source directory. The native
system header is pointed at newlib header files.

The build fails with errors like:

In file included from
/home/summers/msp430/gcc-git/libstdc++-v3/include/precompiled/extc++.h:61:
/home/summers/msp430/src/gcc-binutils-newlib/msp430-elf/libstdc++-v3/include/ext/random:355:69:
error: narrowing conversion of '86243' from 'long int' to 'unsigned int'
[-Wnarrowing]
  355 |                                             0x00000000U, 0xe9528d85U>
      |                                                                     ^

I also tried the build with the git version of gcc, last weekend (14/5/22) and
had exactly the same error.

So is this a bug, or have I configured something wrong. Does libstdc++-v3 just
need to be made 16bit aware?

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Odd, that isn't new code and last time I built for msp430 I thought it worked
ok. I'll look into it.

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[beagleboard at davidjohnsummers dot uk]

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

--- Comment #2 from David Summers <beagleboard at davidjohnsummers dot uk> ---
I suspect its the newlib includes that trigger the problem. As it I did one
compile, where the configure grabbed the host includes (and 64bit system); and
that compile I think worked fine.

My problem though, as my target is a small 16bit cpu, I need the smallest
library, and newlib nano seems to work well - so that will be the library on
the machine where the code is run ..,

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[mikpelinux at gmail dot com]

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

Mikael Pettersson <mikpelinux at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #3 from Mikael Pettersson <mikpelinux at gmail dot com> ---
I can reproduce in a cross to --target=msp430-unknown-elf
--enable-languages=c,c++ with binutils-2.38 and newlib-4.2.0.20211231.
gcc-11.3.0 builds fine, but gcc-12.1.0 build fails with

In file included from
/mnt/scratch/cross/sources/gcc-12.1.0/libstdc++-v3/include/precompiled/extc++.h:61:
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/random:355:69:
error: narrowing conversion of '86243' from 'long int' to 'unsigned int'
[-Wnarrowing]
  355 |                                             0x00000000U, 0xe9528d85U>
      |                                                                     ^
(several more)

and

In file included from
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/hash_policy.hpp:475,
                 from
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/detail/standard_policies.hpp:45,
                 from
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/assoc_container.hpp:47,
                 from
/mnt/scratch/cross/sources/gcc-12.1.0/libstdc++-v3/include/precompiled/extc++.h:72:
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:73:32:
error: narrowing conversion of '116731' from 'long unsigned int' to
'std::size_t' {aka 'unsigned int'} [-Wnarrowing]
   73 |       /* 14    */              116731ul,
      |                                ^~~~~~~~
(many more)

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
possibly the system header diagnostic changes?

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[beagleboard at davidjohnsummers dot uk]

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

--- Comment #5 from David Summers <beagleboard at davidjohnsummers dot uk> ---
Yes I can confirm that going back to gcc-11.2.0 - and it works again, that
being the only change. It explains how I got the headers, on my first build I
used 11.2.0; whilst it was building saw that gcc-12 was available, so
downloaded for a second pass (always like to do two passes - to make sure that
everything knows what else is set up).

So problem is in gcc-12

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Target Milestone|---                         |12.2
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2022-05-26
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think the compiler might have got stricter about diagnosing narrowing
conversions in non-type template arguments (I think I even reported a bug
saying it should do that!)

The problem is that size_t is a 16-bit unsigned int, so too small for the
values we use in the specializations:

  template<typename _UIntType, size_t __m,
           size_t __pos1, size_t __sl1, size_t __sl2,
           size_t __sr1, size_t __sr2,
           uint32_t __msk1, uint32_t __msk2,
           uint32_t __msk3, uint32_t __msk4,
           uint32_t __parity1, uint32_t __parity2,
           uint32_t __parity3, uint32_t __parity4>
    class simd_fast_mersenne_twister_engine

// ...

  typedef simd_fast_mersenne_twister_engine<uint32_t, 86243, 366,
                                            6, 7, 19, 1,
                                            0xfdbffbffU, 0xbff7ff3fU,
                                            0xfd77efffU, 0xbf9ff3ffU,
                                            0x00000001U, 0x00000000U,
                                            0x00000000U, 0xe9528d85U>
    sfmt86243;

We could change the size_t there to be a type with at least 32 bits to make it
work, but I think the right fix is to simply not defined those typedefs that
don't fit in 16 bits:

--- a/libstdc++-v3/include/ext/random
+++ b/libstdc++-v3/include/ext/random
@@ -346,6 +346,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
                                            0xa3ac4000U, 0xecc1327aU>
     sfmt44497_64;

+#if __SIZE_WIDTH__ >= 32

   typedef simd_fast_mersenne_twister_engine<uint32_t, 86243, 366,
                                            6, 7, 19, 1,
@@ -396,6 +397,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
                                            0xf8000001U, 0x89e80709U,
                                            0x3bd2b64bU, 0x0c64b1e4U>
     sfmt216091_64;
+#endif // __SIZE_WIDTH__ >= 32

 #endif // __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__


Everything in <ext/random> is a non-standard extension, so we're under no
obligation to provide any of it for standard conformance.

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> possibly the system header diagnostic changes?

Yes, the narrowing check here was PR c++/57891 which was fixed for GCC 9. But
it was still allowed in system headers until GCC 12.

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And it was indeed something I asked for, see r12-2355

    c++: Don't hide narrowing errors in system headers

    Jonathan pointed me at this issue where

      constexpr unsigned f() { constexpr int n = -1; return unsigned{n}; }

    is accepted in system headers, despite the narrowing conversion from
    a constant.  I suspect that whereas narrowing warnings should be
    disabled, ill-formed narrowing of constants should be a hard error
    (which can still be disabled by -Wno-narrowing).

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Ah, and I didn't see this when building for msp430 because I used
--disable-libstdcxx-pch and that means the build doesn't depend on the
<ext/random> header.

I can now reproduce the build failure, and the patch in comment 6 fixes the
failures in <ext/random>, but then we fail later:

/tmp/msp430/msp430-elf/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:73:32:
error: narrowing conversion of '116731' from 'long unsigned int' to
'std::size_t' {aka 'unsigned int'} [-Wnarrowing]
   73 |       /* 14    */              116731ul,
      |                                ^~~~~~~~

Those are also non-standard extensions. Maybe we should just not install the
precompiled header for <bits/extc++.h> on 16-bit targets.

As a workaround until I fix all the problems, you can use
--disable-libstdcxx-pch

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 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:367740bf6d3a6627798b3955e5d85efc7549ef50

commit r13-787-g367740bf6d3a6627798b3955e5d85efc7549ef50
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu May 26 21:32:55 2022 +0100

    libstdc++: Fix narrowing conversions for 16-bit size_t [PR105681]

    On a 16-bit target such as msp430 we get errors about narrowing long
    values to size_t, which is only 16-bit. When --enable-libstdcxx-pch is
    used the <bits/extc++.h> header breaks the build because of these
    narrowing errors.

    libstdc++-v3/ChangeLog:

            PR libstdc++/105681
            *
include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:
            Limit ga_sizes array to values that fit in size_t.
            * include/ext/random [__SIZE_WIDTH < 32] (sfmt86243)
            (sfmt86243_64, sfmt132049, sfmt132049_64, sfmt216091)
            (sfmt216091_64): Do not declare.

[Bug libstdc++/105681] [12 Regression] libstdc++-v3 fails to build on msp430

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |11.3.0
            Summary|libstdc++-v3 fails to build |[12 Regression]
                   |on msp430                   |libstdc++-v3 fails to build
                   |                            |on msp430
      Known to fail|                            |12.1.0

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on trunk. Backport to follow.

[Bug libstdc++/105681] [12 Regression] libstdc++-v3 fails to build on msp430

[beagleboard at davidjohnsummers dot uk]

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

David Summers <beagleboard at davidjohnsummers dot uk> changed:

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

--- Comment #12 from David Summers <beagleboard at davidjohnsummers dot uk> ---
Thanks Jonathan,

Yes that all makes sense. And yes I agree with your solution. So happy to mark
as resolved.

Thanks for you work on this.

Regards,

David.

[Bug libstdc++/105681] [12 Regression] libstdc++-v3 fails to build on msp430

[redi at gcc dot gnu.org]

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

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

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

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'll keep it open until it's fixed in the gcc-12 branch too.

[Bug libstdc++/105681] [12 Regression] libstdc++-v3 fails to build on msp430

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 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:6666ca1ab44ad8a61e2b916cf4173fe452b78ed6

commit r12-8464-g6666ca1ab44ad8a61e2b916cf4173fe452b78ed6
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu May 26 21:32:55 2022 +0100

    libstdc++: Fix narrowing conversions for 16-bit size_t [PR105681]

    On a 16-bit target such as msp430 we get errors about narrowing long
    values to size_t, which is only 16-bit. When --enable-libstdcxx-pch is
    used the <bits/extc++.h> header breaks the build because of these
    narrowing errors.

    libstdc++-v3/ChangeLog:

            PR libstdc++/105681
            *
include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:
            Limit ga_sizes array to values that fit in size_t.
            * include/ext/random [__SIZE_WIDTH < 32] (sfmt86243)
            (sfmt86243_64, sfmt132049, sfmt132049_64, sfmt216091)
            (sfmt216091_64): Do not declare.

    (cherry picked from commit 367740bf6d3a6627798b3955e5d85efc7549ef50)

[Bug libstdc++/105681] [12 Regression] libstdc++-v3 fails to build on msp430

[redi at gcc dot gnu.org]

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

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

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

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 12.2 as well.