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

2022-05-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 --- Comment #10 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:367740bf6d3a6627798b3955e5d85efc7549ef50 commit r13-787-g367740bf6d3a6627798b3955e5d85efc7549ef50 Author: Jonathan Wakely Date:

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

2022-05-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 --- Comment #9 from Jonathan Wakely --- 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 header. I can now reproduce the build failure, and the patch in co

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

2022-05-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 --- Comment #8 from Jonathan Wakely --- 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 =

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

2022-05-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 --- Comment #7 from Jonathan Wakely --- (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 h

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

2022-05-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|---

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

2022-05-26 Thread beagleboard at davidjohnsummers dot uk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 --- Comment #5 from David Summers --- 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 wa

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

2022-05-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 --- Comment #4 from Richard Biener --- possibly the system header diagnostic changes?

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

2022-05-22 Thread mikpelinux at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Com

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

2022-05-22 Thread beagleboard at davidjohnsummers dot uk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 --- Comment #2 from David Summers --- 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

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

2022-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681 Jonathan Wakely changed: What|Removed |Added Keywords||build --- Comment #1 from Jonathan Wa