[Bug c++/114858] [11/12/13/14/15 regression] Compilation Hang and Excessive RAM Consumption in GCC with invalid input since r0-128725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858 --- Comment #3 from Hans-Peter Nilsson --- Looks like it slowly chews up memory. I killed an -O2 run when cc1plus had consumed 110 GiB, x86_64-linux at r14-10114-g09680e3ee7d7.
[Bug sanitizer/114494] false-positive with -O2 -Wstringop-overflow=2 -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #5 from Hans-Peter Nilsson ---
(In reply to Akihiko Odaki from comment #0)
> if (hlen < sizeof(struct ip_header)) {
Is this a typo for "if (hlen > sizeof(struct ip_header)) {" which makes a bot
more sense to me?
(I can't find it in Linux/drivers, so can't check "upstream" status.)
[Bug go/114454] go.test/test/fixedbugs/issue27836.go FAILs with LANG=C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114454 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson --- This reminds me of PR105959, but no, I haven't actually jumped into the rabbithole^W^Wanalyzed the problem to any extent.
[Bug target/114492] Invalid use of gcc_assert (notably in gcc/config/aarch64/aarch64-ldp-fusion.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114492 --- Comment #3 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #1) > >Please be advised that the argument is *not* evaluated with release checking > > Actually it is evaluated with release checking as release checking enables > assert checking. Ah, I should have followed ENABLE_ASSERT_CHECKING. Still worrisome. > The 2 I see which might be an issue is: > gcc_assert (crtl->ssa->verify_insn_changes (changes)); > > gcc_assert (rtl_ssa::restrict_movement_ignoring (*changes[i], > is_changing)); (Four instances, two each of these two.)
[Bug target/114492] New: Invalid use of gcc_assert (notably in gcc/config/aarch64/aarch64-ldp-fusion.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114492 Bug ID: 114492 Summary: Invalid use of gcc_assert (notably in gcc/config/aarch64/aarch64-ldp-fusion.cc) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: acoplan at gcc dot gnu.org Target Milestone: --- Target: aarch64 I've noticed invalid uses of gcc_assert in gcc/config/aarch64/aarch64-ldp-fusion.cc. Please be advised that the argument is *not* evaluated with release checking; I believe most uses can be cured by breaking out the call; i.e. replacing an invalid call: gcc_assert (function_that_needs_to_be_called_but_most_certainly_returns_true()) with: bool x = function_that_needs_to_be_called_but_most_certainly_returns_true (); gcc_assert (x). (Probably not the only file, just the one I've been looking at, for reasons, and I thought better enter a bug report, just not going to fix it myself.) Incidentally, I think "we" ought to add something to gcc that automatically checks and warns for such invalid use. There may be a need to implement a builtin to check that an expression X does not have side-effects, for use both within gcc in gcc_assert and user-visible, for implementations of assert; say __builtin_pure_p (X). (The name is ripe to bike-shedding, just choosing a mix of __builtin_constant_p and the "pure" attribute.)
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 --- Comment #8 from Hans-Peter Nilsson --- There it is! I *knew* I had a PR entered for this, and was a bit surprised when the ipa attribute was introduced, that this PR wasn't cross-referenced. Then again I guess most people don't check in bugzilla for possible entries when they fix something, and this one maybe hasn't got any good terms to look for. (In reply to Andrew Pinski from comment #7) > The noipa attribute is used for this now. It sure is and spot on.
[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108355 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #10 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #9) > gcc.dg/tree-ssa/ssa-fre-104.c has been XFAILed. Any obvious target-specific reason for this to XPASS on cris-elf, m68k-linux and pru-elf? (per recent gcc-testresults posts)
[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143 --- Comment #6 from Hans-Peter Nilsson --- Can --with-multilib-list=aprofile,rmprofile at least be made the default when no colliding --with-* options are specified? Would that blow up "everyone"'s CI due to the extra build time? If so, perhaps then just for release builds? Or do you suggest another solution? (I hope we agree that there *is* a problem.)
[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143 Hans-Peter Nilsson changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Hans-Peter Nilsson --- (In reply to Christophe Lyon from comment #1) > What configure flags did you use? Only --target arm-eabi" ? The exact configure options that were used are (besides --prefix): --target=arm-eabi --with-gnu-ld --with-gnu-as --with-newlib --enable-languages=c,c++,lto --enable-checking=release This particular gcc version was trunk: r14-9089-gb4c88cc717e5 It was built together with newlib as of git 4e77fa9b8bf4 (about 2024-02-13) Binutils as of about 2024-02-21. Also seen with binutils-2.42, gcc-13.2.0, newlib-4.4.0.20231231 so I doubt the exact versions are key. > What does gcc --print-multi-lib say? .; thumb;@mthumb arm/autofp/v5te/fpu;@marm@mfpu=auto@march=armv5te+fp@mfloat-abi=hard thumb/autofp/v7/fpu;@mthumb@mfpu=auto@march=armv7+fp@mfloat-abi=hard > You probably haven't built the correct multilibs. If that suggestion boils down to incorrect configure options or make invocation, for the latter: $ make -j7 then much later $ make install If I can't build a whole-thumb binary then why include the thumb multilibs there at all? If certain --with-* options are a requirement for that, IMO this should at least be documented.
[Bug target/114143] New: Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
Bug ID: 114143
Summary: Non-thumb arm32 code in thumb multilib for libgcc and
in -mthumb build
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
Target Milestone: ---
Target: arm-eabi
Building an arm-eabi newlib toolchain configured simply with --target arm-eabi,
I expect the simplest thumb1 library code in libraries linked in when I compile
and link the main code using e.g. -O2 -mcpu=cortex-m7+nofp -msoft-float. To my
surprise, I get 32-bit ("arm32") code linked in. Needless to say, it crashes
for this reason on the target Cortex-M7 system. On inspection the linked-in
thumb multilib is full of 32-bit code. Ditto some of the newlib code for some
optimized functions implemented in assembly code (like strcmp), but that may be
a separate bug unless the preprocessor macros that newlib uses in the build,
are wrong for the same reason as in this PR.
While I can work around this by adding --with-arch=armv7e-m at configure-time,
I think a "plain" arm-eabi configuration being unusable for thumb-only builds
with -mthumb is a bug or at least a surprising caveat worth being documented.
Example code, for a tool-chain configured with --target arm-eabi as above:
a.c; compile with "-O2 -mthumb" to simulate other library code:
```
unsigned udivide(unsigned a, unsigned b)
{
return a / b;
}'''
b.c; compile with "-msoft-float -mthumb -mcpu=cortex-m7+nofp -O2" simulating
code you care about:
```extern unsigned udivide(unsigned, unsigned);
int main()
{
__builtin_exit (udivide(42, 6));
}'''
Link a.o and b.o producing ab using gcc with e.g. "-msoft-float -mthumb
-mcpu=cortex-m7+nofp" to make sure you get the right multilib. Inspect ab
using arm-eabi-objdump -d. Observe udivide calling __udivsi3, with __udivsi3
containing arm32 code.
[Bug target/113779] Very inefficient m68k code generated for simple copy loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #7 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #6) > The auto-inc pass is well > structured, so it should be possible to extend it. Or just replace it, as it doesn't look far enough to be able to handle all incdec-opportunities.
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 --- Comment #5 from Hans-Peter Nilsson --- Thank you!
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 Hans-Peter Nilsson changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 --- Comment #1 from Hans-Peter Nilsson --- There's a test-suite patch at https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643667.html which is currently in review-ping limbo. I'm unassigning myself from this PR. I won't work on the actual problem, although I'll keep pinging the testsuite patch - which has merits on its own as a guard if this PR is accidentally fixed, which is actually expected given the nature of the underlying bug.
[Bug c++/112737] [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737 --- Comment #10 from Hans-Peter Nilsson --- Looks like this also fixed one of the remaining FAILs logged in PR112580, specifically "FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)".
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 --- Comment #9 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #6) > (In reply to Francois-Xavier Coudert from comment #5) > > Not entirely, xtreme-header_b.C is still failing, as indicated above. See > > recently: > > https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805380.html > > > > FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) > > FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) > > Confirmed for cris-elf @r14-7254-g4f141b051ef4, reopening. But those two are gone. While the "FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)" was logged as PR112737, the "FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)" was covered in this ticket. Both were fixed by r14-8705-g3ba5be16a2be (but which tagged just PR112737).
[Bug libstdc++/113398] no longer usable with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113398 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson --- Huh! I found this out the hard way, and thought it was just another clang++/gcc incompatibility; I had no idea it was this "recent". Cf. https://github.com/ARM-software/ethos-n-driver-stack (at the moment compiling only with ARMs clang-derivate). The code under firmware/control_unit there (targetting a cortex-m7) uses -ffreestanding (the clang option) but makes use of enough to "break" it. FWIW, hacking off the --freestanding for gcc works as long as you also set up enough of a "hosted" environment. (There's also firmware/ple for a cortex-m33, but that code is truly freestanding AFAIU - except for using main.) Interesting that it "worked" with gcc-12. I cooked up something with a recent gcc+binutils+newlib though. Just an example of live freestanding code out there, using , right or wrong.
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-22 Ever confirmed|0 |1
[Bug c++/113545] New: ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545
Bug ID: 113545
Summary: ICE in label_matches with constexpr function with
switch-statement and converted (nonconstant, cast
address) input
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
Target Milestone: ---
For the following test-case, g++ ICEs from at least gcc-10 and forward (i.e.
apparently not a regression):
```
char foo;
constexpr unsigned char bar(__UINTPTR_TYPE__ baz)
{
switch (baz)
{
case 13:
return 11;
case 14:
return 78;
case 2048:
return 13;
default:
return 42;
}
}
__attribute__ ((__noipa__))
void xyzzy(int x)
{
if (x != 42)
__builtin_abort ();
}
int main()
{
unsigned const char c = bar(reinterpret_cast<__UINTPTR_TYPE__>());
xyzzy(c);
}
'''
Example backtrace with -std=c++20 -O3:
../n.cc: In function 'int main()':
../n.cc:27:30: in 'constexpr' expansion of 'bar(((long unsigned int)(&
foo)))'
../n.cc:5:3: internal compiler error: in label_matches, at cp/constexpr.cc:6925
5 | switch (baz)
| ^~
0x63894c label_matches
/gcctop/gcc/cp/constexpr.cc:6925
0xa0bb3d cxx_eval_constant_expression
/gcctop/gcc/cp/constexpr.cc:7319
0xa0d2b2 cxx_eval_statement_list
/gcctop/gcc/cp/constexpr.cc:6969
0xa0d2b2 cxx_eval_constant_expression
/gcctop/gcc/cp/constexpr.cc:8316
0xa1e782 cxx_eval_switch_expr
/gcctop/gcc/cp/constexpr.cc:7115
0xa0cb6b cxx_eval_constant_expression
/gcctop/gcc/cp/constexpr.cc:8412
0xa0aae6 cxx_eval_call_expression
/gcctop/gcc/cp/constexpr.cc:3288
0xa0c2ef cxx_eval_constant_expression
/gcctop/gcc/cp/constexpr.cc:7524
0xa17d9a cxx_eval_outermost_constant_expr
/gcctop/gcc/cp/constexpr.cc:8822
0xa1d28f maybe_constant_value(tree_node*, tree_node*, mce_value)
/gcctop/gcc/cp/constexpr.cc:9110
0xa49e40 cp_fully_fold
/gcctop/gcc/cp/cp-gimplify.cc:2831
0xa49ed9 cp_fully_fold
/gcctop/gcc/cp/cp-gimplify.cc:2825
0xa49ed9 cp_fully_fold_init(tree_node*)
/gcctop/gcc/cp/cp-gimplify.cc:2861
0xc7a204 store_init_value(tree_node*, tree_node*, vec**, int)
/gcctop/gcc/cp/typeck2.cc:926
0xa6ca32 check_initializer
/gcctop/gcc/cp/decl.cc:7810
0xa941be cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
/gcctop/gcc/cp/decl.cc:8842
0xb95477 cp_parser_init_declarator
/gcctop/gcc/cp/parser.cc:23618
0xb6ac98 cp_parser_simple_declaration
/gcctop/gcc/cp/parser.cc:15890
0xb8f830 cp_parser_declaration_statement
/gcctop/gcc/cp/parser.cc:14926
0xb97215 cp_parser_statement
/gcctop/gcc/cp/parser.cc:12882
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/102626] [c++20] compiler crash when invoking constexpr function in the constructor of template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102626 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org Last reconfirmed|2021-10-11 00:00:00 |2024-01-14 0:00 --- Comment #4 from Hans-Peter Nilsson --- Searching for a constexpr-related bug (not this one) I can confirm that (for cris-elf at least) the bug is still there at r14-7232-gb468821eea8d (the test-case in comment #2 with "-std=c++20 -O3")
[Bug other/113336] libatomic (testsuite) regressions on armv6-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113336 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson --- Whoops, sorry! (no, not actually sorry :) I'm glad you have a handle on this, though!
[Bug testsuite/113437] [14 Regression] gcc.dg/tree-ssa/pr95906.c fails on arm since g:6686e16fda4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113437 Hans-Peter Nilsson changed: What|Removed |Added Target|arm, sparc* |arm, sparc*, cris CC||hp at gcc dot gnu.org --- Comment #6 from Hans-Peter Nilsson --- cris-elf too...
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 113038, which changed state. Bug 113038 Summary: [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #10 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #9) > I'm going to reclose this if > I can find support for it being fixed on one more target. So, https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805640.html says it's fixed for power8 too, compared to the previous report, for r14-8195.
[Bug c++/112588] [modules] ICE in make_decl_rtl when returning str literal when string header imported in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112588 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #5 from Hans-Peter Nilsson --- Looks like that commit also fixed the remaining g++.dg/modules/hello-1 execution failure for PR113038!
[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038 --- Comment #9 from Hans-Peter Nilsson --- For cris-elf, a change in the range (known to fail, known to pass] (r14-8193-g3340878009acfc, r14-8200-g9a5e8f9d112adb] seems to have fixed the remaining hello-1 execution failure, so fixed by r14-8196-g3471a61ed0ddef (being a change to the c++ modules code and the only code change outside riscv). Being the person that reopened the PR, I think I'm going to reclose this if I can find support for it being fixed on one more target.
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 Hans-Peter Nilsson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Hans-Peter Nilsson --- (In reply to Francois-Xavier Coudert from comment #5) > Not entirely, xtreme-header_b.C is still failing, as indicated above. See > recently: > https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805380.html > > FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) > FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) Confirmed for cris-elf @r14-7254-g4f141b051ef4, reopening.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 112580, which changed state. Bug 112580 Summary: [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug testsuite/112419] [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419 --- Comment #7 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #6) > Fixed. I guess. Correct; sorry, I should have close it myself after the commit.
[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230 --- Comment #9 from Hans-Peter Nilsson --- By the (In reply to Jonathan Wakely from comment #8) > Although I guess Andrew's qemu setup doesn't match the simulator ET. FWIW, by his uploaded board-info file calling 'load_generic_config "sim"' and a look at what's in my /usr/share/dejagnu/config/sim.exp, and comparing that to what's tested in ET simulator, I'd say it does: use and setting of "set_board_info slow_simulator 1" is key.
[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #6 from Hans-Peter Nilsson --- Exactly the same for cris-elf, newlib, "sim that's colocated with gdb". Baseboard is cris-sim.exp from a standard dejagnu installation *and* (probably the key): LC_ALL=C, which seems to contradict previous comments.
[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038 Hans-Peter Nilsson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Hans-Peter Nilsson --- (In reply to Jason Merrill from comment #6) > But the regression is fixed. Only partially: the "g++.dg/modules/hello-1 -std=c++2b execute" is still there, and was part of the regression; at least introduced at the same time. This both for cris-elf@r14-7217-g444a31f3b354 and powerpc64le-unknown-linux-gnu@r14-7215-g8b447fa89d (https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805221.html). Thus reopening.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 113038, which changed state. Bug 113038 Summary: [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug target/113226] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc fails for cris-elf after r14-6888-ga138b99646a555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113226 Hans-Peter Nilsson changed: What|Removed |Added Component|testsuite |target --- Comment #4 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #3) > (In reply to Patrick Palka from comment #1) > > Huh, how bizarre. > > Indeed. I'm *not* ruling out an actual gcc bug. Whether in the target or > middle-end this time I dare not guess; too few posts. I don't see this FAIL for m68k-unknown-linux-gnu in https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/804595.html so let's change to target component. I'll see if I can revive one of the other *-elf toolchains to the point where the libstdc++-v3 tests are useful before digging in. (But also subject to other priorities and unfortunately not among the highest.)
[Bug testsuite/113226] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc fails for cris-elf after r14-6888-ga138b99646a555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113226 --- Comment #3 from Hans-Peter Nilsson --- (In reply to Patrick Palka from comment #1) > Huh, how bizarre. Indeed. I'm *not* ruling out an actual gcc bug. Whether in the target or middle-end this time I dare not guess; too few posts. JFTR; I already mentioned this in the gcc-patches post: I see only posts on gcc-testresults@ that include r14-6888-ga138b99646a555 for 64-bit-targets with "-m32" multilibs, and I don't trust them to treat that hw_type the same.
[Bug testsuite/113226] New: [14 Regression] testsuite/std/ranges/iota/max_size_type.cc fails for cris-elf after r14-6888-ga138b99646a555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113226
Bug ID: 113226
Summary: [14 Regression]
testsuite/std/ranges/iota/max_size_type.cc fails for
cris-elf after r14-6888-ga138b99646a555
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
Target Milestone: ---
After r14-6888-ga138b99646a555, I see, for cris-elf (32-bit target, no 128bit):
FAIL: std/ranges/iota/max_size_type.cc -std=gnu++20 execution test
FAIL: std/ranges/iota/max_size_type.cc -std=gnu++26 execution test
And in the .log:
spawn cris-elf-run ./max_size_type.exe^
Inconsistency found: 1 0 -100 -100^
/x/gcc/libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc:246: void
test02() [with bool signed_p = true; bool shorten_p = false]: Assertion '0'
failed.
program stopped with signal 6 (Aborted).
FAIL: std/ranges/iota/max_size_type.cc -std=gnu++20 execution test
Changing all s/ok &=/VERIFY/ (plus adding one level of parentheses to one of
the lines) show:
/x/gcc/libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc:217: void
test02() [with bool signed_p = true; bool shorten_p = false]: Assertion 'i*j ==
shorten_type(max_type(i)*j)' failed.
program stopped with signal 6 (Aborted).
Further instrumentation, adding among other lines:
```
if (signed_p && ! shorten_p)
std::cerr << "j == " << int64_t(j) << std::endl;
if (!(i*j == shorten_type(max_type(i)*j)))
{
std::cerr << "i == " << int64_t(i) << ", j == " << j << ", i*j ==
" << int64_t(i*j) << ", max_type(i) == \
" << int64_t(max_type(i));
std::cerr << ", max_type(i)*j == " << int64_t(max_type(i)*j) <<
std::endl;
}
'''
shows that this is (see above for template parameters):
i == 1, j == -100, i*j == 4294967196, max_type(i) == 1, max_type(i)*j == -100
and that large number is as you might guess, (unsigned) -100.
Not sure if this is a bug in the testcase or elsewhere, but I'll start my
guessing with testsuite.
[Bug testsuite/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 --- Comment #5 from Hans-Peter Nilsson --- (In reply to Xi Ruoyao from comment #4) > IIRC the "signed_rep_t = __int128;" case has really detected a compiler bug, > so IMO we shouldn't just disable it. Maybe I should have been explicit: that was just for investigation purposes. > Maybe my memory is flawed though. Please link that PR here if you have it!
[Bug testsuite/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 Hans-Peter Nilsson changed: What|Removed |Added Component|libstdc++ |testsuite --- Comment #3 from Hans-Peter Nilsson --- There's one single regression event, bringing the host runtime to about 1.63 seconds. Then some time later, an additional 0.1 second was added (accumulated). I did not look into that latter regression. The big one is clouded by a large range of commits where max_size_type failed, due to r14-159-g03cebd304955a6. This was fixed in r14-205-g83470a5cd4c3d2, at which time there the big regression is seen for the first time. That is also the "cause" for the commit, because applying that commit to r14-158-g7d115e01411156 shows the same number as for r14-205-g83470a5cd4c3d2. Actually, it's the testsuite part of that patch, because with that reverted the execution time backs down to 0.33 seconds. IOW, this while PR is /testsuites. Not sure what to do to improve the execution time, as plain disabling the using "signed_rep_t = __int128;" by making the first line "+#if 0 && __SIZEOF_INT128__" yields /x/testsuite/std/ranges/iota/max_size_type.cc:36: note: the comparison reduces to '(16 == 8)' Maybe the higher number for the execution time is actually the "right" one and the range should be cut down to -100..100 for *all* targets? HNY!
[Bug libstdc++/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 --- Comment #2 from Hans-Peter Nilsson --- Bisecting (native) has progressed beyond the r13 mark, i.e. this is indeed a "[14 Regression]" only.
[Bug libstdc++/113175] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 Hans-Peter Nilsson changed: What|Removed |Added Target|mmix-knuth-mmixware |mmix-knuth-mmixware, ||x86_64-linux-gnu Summary|[14 Regression] MMIX: |[14 Regression] |testsuite/std/ranges/iota/m |testsuite/std/ranges/iota/m |ax_size_type.cc 5x times|ax_size_type.cc 5x times |slower |slower Component|target |libstdc++ --- Comment #1 from Hans-Peter Nilsson --- I'm afraid this isn't target-specific. I bootstrapped native x86_64-linux-gnu off the both source trees, and ran \time env LD_LIBRARY_PATH=(long curse) ./max_size_type.exe r12-2797-g307e0d40367996: 0.32user 0.00system 0:00.32elapsed 99%CPU (0avgtext+0avgdata 2620maxresident)k 0inputs+0outputs (0major+184minor)pagefaults 0swaps r14-6859-gd1eacedc6d9b: 1.73user 0.00system 0:01.73elapsed 100%CPU (0avgtext+0avgdata 3564maxresident)k 0inputs+0outputs (0major+194minor)pagefaults 0swaps ...which is a factor of about 5.4, consistent with the MMIX observation. Still unknown whether libstdc++ or code-generator of course, but I'm leaning towards the latter, for the same reasons as in the precious comment. Maybe the test-case triggers peculiar details.
[Bug target/113175] New: [14 Regression] MMIX: testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 Bug ID: 113175 Summary: [14 Regression] MMIX: testsuite/std/ranges/iota/max_size_type.cc 5x times slower Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: mmix-knuth-mmixware (Perhaps a "[13 Regression]" as well - haven't checked.) I ran the testsuite for mmix-knuth-mmixware (a 64-bit newlib cross) and found that testsuite/std/ranges/iota/max_size_type.cc times out, despite the timeout-factor increased by a factor 4 (from 360 seconds to 1440 seconds) in r12-2799-ge9b639c4b53221. For a tree at r12-2797-g307e0d40367996 running this test takes 11:43.61 (mm:ss) wall-clock time and now at r14-6859-gd1eacedc6d9b it takes 58:45.78 (on one and the same host and same session within the same hour; no host-side changes and the test itself apparently hasn't changed significantly). I haven't checked whether this affects other targets, but if so, a 5x performance regression should have been picked up by other testers, thus I'm starting with "target" until firther investigated.
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #14 from Hans-Peter Nilsson --- (In reply to GCC Commits from comment #9) > The master branch has been updated by Hans-Peter Nilsson : > > https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0 > > commit r14-6817-g3d03630b123411340e52d05124cb0cacfa1fc8b0 > Author: Hans-Peter Nilsson > Date: Sun Dec 24 00:10:32 2023 +0100 > > I haven't looked into why this problem, that appeared for the PA > already in 2007, was seen for CRIS only recently (with > r14-6674-g4759383245ac97). I should've removed that paragraph before committing. It's obvious from looking at r14-6674-g4759383245ac97 and the history of the expression in that context, and knowing that pa uses hard_frame_pointer_rtx... Still, why not all those other targets? (In reply to Jiu Fu Guo from comment #13) > (In reply to GCC Commits from comment #9) > > Conceptually, it's logical that stores to incoming args are > > optimized out on the return path or if no loads are seen - > > at least before epilogue expansion, when the subsequent load > > isn't seen in the RTL, as is the case for the "dse1" pass. > > The stores to the argp/frame can be eliminated only if they are not used. > While for this case, the store may be used by EH handler, it should not be > optimized out. That use is not seen before the pro/epilogue expansion pass. Maybe the pass should be restricted in what it does prior to that (not do in dse1, do in dse2). > Thanks for catching and handling this quickly. > > Happy holidays. No worries, same to you!
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #12 from Hans-Peter Nilsson --- Writing and doing are different things...
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #11 from Hans-Peter Nilsson --- (In reply to Jiu Fu Guo from comment #8) > I'm wondering if we need to revert r14-6674 to avoid this functionality > issue. And revisit/enhance the patch later. No need, not anymore; not because of this PR anyway. I'm closing the bug, but please don't back-port that commit (or at least, please back-port this commit as well if you do). Happy holidays.
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #10 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #6) > So I did a quick audit of the EH_RETURN_HANDLER_RTX Yeah, me too. > and most are registers > rather than a memory location . And the ones which were memory locations > used either frame or stack pointer directly which seemed to not to be > removed. And those that with an address relative to hard_frame_pointer_rtx, marks the mem as volatile. > I had originally was going to record my findings but then I saw the > volatile for pa risc and deleted what I had wrote up. Ouch, "never delete what you can't undo". Sometimes you turn back another 180 degrees from your 180 turn in the middle of the analysis or bug-hunt. Was it more than a list of targets and their EH macros and patterns? The fun thing is that the dse1 pass (the culprit) works before pro/epilogue expansion, so it sees stores without the matching loads. That is, for targets that just define EH_RETURN_HANDLER_RTX (no eh_return pattern or any fancy extra) and handles EH at epilogue expansion time.
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #5 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #4) > Hmm, see PR 32398 and PR 32769. PR 32769 is interesting because it was > caused by the merge of the df branch where the store was being removed just > like here on cris. > > Oh and reading > https://inbox.sourceware.org/gcc-patches/200707151749.l6FHnXrt010084@hiauly1. > hia.nrc.ca/ (the patch submission for those two PR's) > even mentions this exact issue it seems where dse.cc is removing > the store and such. Thanks for the bug-archive-digging! I decided on trying making the mem volatile and I see PR32769 supports that; exactly the same thing! I just wonder why it was seen with pa *then* and CRIS only *now*.
[Bug c++/112883] FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112883 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson --- Is this different to PR112737 ?
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #3 from Hans-Peter Nilsson ---
It's __builtin_eh_return( that's miscompiled, such that the "handler" isn't
installed and the calling function will return to its caller instead of the
handler.
For the example below:
void f(__UINTPTR_TYPE__ p1, void *p2)
{
__builtin_eh_return(p1, p2);
}
...there's a tell-tale diff between 6673 and 6674 in generated assembly code at
-O2:
@@ -23,7 +23,6 @@ _f:
move.d $r13,[$sp]
.LCFI5:
move.d $r10,$r9
- move.d $r11,[$sp+16]
move.d [$sp+],$r13
move.d [$sp+],$r12
move.d [$sp+],$r11
cris.h defines EH_RETURN_HANDLER_RTX (as a call to cris_return_addr_rtx
yielding) gen_rtx_MEM (Pmode, plus_constant (Pmode, virtual_incoming_args_rtx,
-4)).
I'm "guessing" that the problem with the patch, is that anything any port
stores through a pointer based on virtual_incoming_args_rtx before returning,
is now eliminated.
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #2 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #0) > That > printf-statement is likely not reached, Now confirmed. The assembly output for eh6.s is identical (before/after), but apparently support-libraries (likely the unwind machinery) is miscompiled.
[Bug middle-end/113109] New: [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 Bug ID: 113109 Summary: [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: guojiufu at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: cris-elf After r14-6674-g4759383245ac97, (at least) all tests that "throw", fail for cris-elf at execution time: g++ tests as well as libstdc++ tests. I don't see any other clues from g++.log than execution failing for those tests. Complete before/after example reports at https://gcc.gnu.org/pipermail/gcc-testresults/2023-December/803815.html and https://gcc.gnu.org/pipermail/gcc-testresults/2023-December/803816.html (for r14-6672-g605d21f8ef1f and r14-6750-gf9be3d8faa47; same failures as 6674). An example of a small hopefully-minimal test that fail is gcc/testsuite/g++.old-deja/g++.mike/eh6.C. Like for seemingly all others, execution the test fails, and there's no output from the printf. That printf-statement is likely not reached, but the output *could* possibly still be in an output-buffer (I don't remember how that works in newlib; that could happen for glibc when execution is aborted). I'm initially setting component to "middle-end" because that's what the commit touched and also, I'm biased, but visiting the gcc-testresults archives I don't see other targets fail in the same manner, so it could still be that "target" fits better. Further analysis will show; I'll dig a little deeper. (Commit author CC:ed.)
[Bug tree-optimization/112468] [14 Regression] Missed phi-opt after recent change (phi-opt-24.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112468 --- Comment #11 from Hans-Peter Nilsson --- (In reply to Tamar Christina from comment #10) > Hi, > > It's not forgotten. I've agreed on a fix with the maintainers that should > solve a bunch of other (older) issues with copysign as well. > > Since it's a bug fix it's on my list after my stage3 changes. But I expect > to be able to send the patch next week. > > Sorry for the delay. Fair enough, thanks for the update!
[Bug tree-optimization/112468] [14 Regression] Missed phi-opt after recent change (phi-opt-24.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112468 --- Comment #9 from Hans-Peter Nilsson --- (In reply to Tamar Christina from comment #7) > testing patch A month later: any update on that? I didn't see a patch posted, so perhaps there was more work to it. Please leave a note if you're no longer working on it and/or not expecting progress within, say, another month.
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 --- Comment #3 from Hans-Peter Nilsson --- All mentioned except g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) seem to be fixed. Thanks!
[Bug testsuite/112786] [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Hans-Peter Nilsson --- .
[Bug tree-optimization/96831] gcc.dg/tree-ssa/scev-[345].c FAIL on i?86 and arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96831 Bug 96831 depends on bug 112786, which changed state. Bug 112786 Summary: [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug testsuite/112894] [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112894 Hans-Peter Nilsson changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson --- I've confirmed that it's r14-6198-g5e8a30d8b8f4d7.
[Bug testsuite/112786] [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786 --- Comment #3 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #2) > Note they XPASS on the 13 branch as well IIRC. XPASS without Alex patch? Is that XPASS a typo for FAIL or PASS? Either way, they FAIL, for ia32 say these results from gcc-testresults@: i386-pc-solaris2.11 https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800123.html x86_64-pc-linux-gnu -m32 (but not -mx32 nor default) https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800107.html i686-pc-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800113.html And PASS for these: sparc-sun-solaris2.11 https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800134.html avr-unknown-none https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800623.html pru-unknown-elf https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800630.html
[Bug testsuite/112786] [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786 Hans-Peter Nilsson changed: What|Removed |Added Keywords||patch --- Comment #1 from Hans-Peter Nilsson --- See URL field for patch alternative 1. Alternative 2: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/638863.html
[Bug testsuite/112786] [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |hp at gcc dot gnu.org Last reconfirmed||2023-11-30
[Bug testsuite/112786] New: [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786 Bug ID: 112786 Summary: [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: aoliva at gcc dot gnu.org Blocks: 96831 Target Milestone: --- Target: cris-elf, m68k-linux-gnu, arm-eabi, pru-elf, ft32-elf, c6x-elf, epiphany-elf, lm32-elf, microblaze-linux, m32r-elf, mcore-elf, shle-linux This tracks the three regressions for most ilp32 targets (see target field; default configurations only) that were appearing with r14-5608-g69741355e6dbcf; regressions because they didn't show up before, in particular as a XPASS. For discussing underlying issues, PR96831 is probably a better choice. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96831 [Bug 96831] gcc.dg/tree-ssa/scev-[345].c FAIL on i?86 and arm
[Bug c++/112737] New: [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737 Bug ID: 112737 Summary: [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- Target: cris-elf With r14-5794-g7a6a29c455e775 "libstdc++: Define std::ranges::to for C++23 (P1206R7) [PR111055]" this test-suite regression was introduced for various targets: Running /x/gcc/testsuite/g++.dg/modules/modules.exp ... [...] FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) According to g++.log, for cris-elf: Excess errors: /src/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error: conflicting global module declaration 'template class _Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr1 = decltype (_Cont<...auto...>(declval<_Rg>(), (declval<_Args>)()...))' /src/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error: conflicting global module declaration 'template class _Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr2 = decltype (_Cont<...auto...>(std::from_range, declval<_Rg>(), (declval<_Args>)()...))' /src/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error: conflicting global module declaration 'template class _Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr3 = decltype (_Cont<...auto...>(declval >(), declval >(), (declval<_Args>)()...))' /src/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error: conflicting global module declaration 'using std::ranges::__detail::_DeduceExpr1 = decltype (_Cont<...auto...>(declval<_Rg>(), (declval<_Args>)()...))' /src/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error: conflicting global module declaration 'using std::ranges::__detail::_DeduceExpr2 = decltype (_Cont<...auto...>(std::from_range, declval<_Rg>(), (declval<_Args>)()...))' /src/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error: conflicting global module declaration 'using std::ranges::__detail::_DeduceExpr3 = decltype (_Cont<...auto...>(declval >(), declval >(), (declval<_Args>)()...))' This appears to happen also for "aarch64": https://gcc.gnu.org/pipermail/gcc-regression/2023-November/078616.html and "Linux/x86_64": https://gcc.gnu.org/pipermail/gcc-regression/2023-November/078617.html suggesting that most targets are affected. (Maintainers, please adjust your scripts to include a full gnu target tuple in your autotester messages in those places where the abbreviated quoted ones are found, so that readers can cut-and-paste that key information for e.g. additional targets in bug-reports, QED. Additional steps such as following links should not be necessary.)
[Bug testsuite/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120
--- Comment #11 from Hans-Peter Nilsson ---
(In reply to Rainer Orth from comment #10)
> Since 20230106, this test produces an XPASS, according to gcc-testresults
> postings this happens everywhere:
>
> +XPASS: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++98 pr106120 (test for
> bogus messages, line 144)
>
> The corresponding line is
>
> T (S (2), new int16_t[r_imin_imax + 1]); // { dg-bogus "into a region of
> size" "pr106120" { xfail { c++98_only } } }
>
> I think that xfail should just be removed?
Yes, though I think the date 20230106 is wrong (at least regarding the
"everywhere") and maybe a typo for 20231006, at least according to my own logs
- where I unsurprisingly don't track XPASS. Gotta fix that.
[Bug libstdc++/112630] New: [14 Regression] 19_diagnostics/stacktrace/output.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112630 Bug ID: 112630 Summary: [14 Regression] 19_diagnostics/stacktrace/output.cc execution test Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- Target: cris-elf, m68k-linux-gnu, arm >From r14-5536-g23725aa53bd264, this test started failing for cris-elf and some other targets. The test changed from "dg-compile" to "dg-run" so for once there's a simple cause for the regression, and N.B. I notably disregard the underlying problem that the test actually fails when running; a problem that doesn't seem trivial. Incidentally, for cris-elf as well as (at least) m68k-linux-gnu, the neighboring stacktrace execution tests fail (excerpt for cris-elf at r14-5540-ga671095c208c): Running /x/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++26 execution test FAIL: 23_containers/vector/debug/mutex_association.cc -std=gnu++17 execution test FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc -std=gnu++17 execution test [...] To wit, of those, these are the introduced regressions: FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++26 execution test For the other targets, compare results for m68k-linux: https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/801238.html ...to its earlier results: https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800388.html The "arm" CI bot picked it up too: https://gcc.gnu.org/pipermail/gcc-regression/2023-November/078553.html I'm not sure which component fits best here. It seems there's an exposed bug with libstdc++ or libbacktrace or both. Or, it could just be that the change from dg-compile to dg-run is a testsuite typo; that it shouldn't dg-run.
[Bug c++/112580] New: [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 Bug ID: 112580 Summary: [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration' Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-checking Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- r14-5524-gc7f6537db94f7c exposed this test-suite regression for multiple targets: Running /x/gcc/gcc/testsuite/g++.dg/modules/modules.exp ... [...] FAIL: g++.dg/modules/xtreme-header-4_b.C -std=c++2b (internal compiler error: tree check: expected class 'type', have 'declaration' (template_decl) in get_originating_module_decl, at cp/module.cc:18649) FAIL: g++.dg/modules/xtreme-header-4_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (internal compiler error: tree check: expected class 'type', have 'declaration' (template_decl) in get_originating_module_decl, at cp/module.cc:18649) FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (internal compiler error: tree check: expected class 'type', have 'declaration' (template_decl) in get_originating_module_decl, at cp/module.cc:18649) FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) It happens for cris-elf, as well as other platforms: powerpc64-unknown-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800960.html i686-pc-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800997.html "arm" https://gcc.gnu.org/pipermail/gcc-regression/2023-November/078545.html (where you have to click links to find out --target, though probably not important) Module tests may be nastier to reproduce than the usual ICE needing more than a preprocessed .ii, but I believe one or more of the above targets should be accessible.
[Bug testsuite/112419] [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419 Hans-Peter Nilsson changed: What|Removed |Added Keywords||patch Assignee|uecker at gcc dot gnu.org |hp at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Novembe ||r/636717.html --- Comment #3 from Hans-Peter Nilsson --- (In reply to uecker from comment #1) > Confirmed. I think adding -Wstringop-overflow= to the test might fix it. It > is just some test which is wrong for 32 bit targets and somehow this > problems appeared now due to an unrelated change. > > I will try this and submit a patch. I guess you got side-tracked. I posted a patch hence taking the PR.
[Bug tree-optimization/112468] [14 Regression] Missed phi-opt after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112468 Hans-Peter Nilsson changed: What|Removed |Added Target|moxie-elf |moxie-elf, cris-elf, ||s390x-linux-gnu, ||m68k-linux-gnu, pru-elf CC||hp at gcc dot gnu.org --- Comment #6 from Hans-Peter Nilsson --- This commit caused test-suite regressions not just for moxie-elf but for several other targets; also cris-elf and according to gcc-testresults posts: s390x-ibm-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800481.html m68k-unknown-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800547.html pru-unknown-elf https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800569.html And it's not just gcc.dg/tree-ssa/phi-opt-24.c scan-tree-dump-not phiopt2 "if", but: Running /x/gcc/gcc/testsuite/gcc.dg/dg.exp ... [...] FAIL: gcc.dg/pr55152-2.c scan-tree-dump-times optimized ".COPYSIGN" 1 FAIL: gcc.dg/pr55152-2.c scan-tree-dump-times optimized "ABS_EXPR" 1 Running /x/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ... FAIL: gcc.dg/tree-ssa/abs-4.c scan-tree-dump-times optimized "= ABS_EXPR" 1 FAIL: gcc.dg/tree-ssa/abs-4.c scan-tree-dump-times optimized "= -" 1 FAIL: gcc.dg/tree-ssa/abs-4.c scan-tree-dump-times optimized "= .COPYSIGN" 2 FAIL: gcc.dg/tree-ssa/backprop-6.c scan-tree-dump-times backprop "Deleting[^\\n]* = -" 4 FAIL: gcc.dg/tree-ssa/backprop-6.c scan-tree-dump-times backprop "Deleting[^\\n]* = \\.COPYSIGN" 2 FAIL: gcc.dg/tree-ssa/backprop-6.c scan-tree-dump-times backprop "Deleting[^\\n]* = ABS_EXPR <" 1 FAIL: gcc.dg/tree-ssa/copy-headers-8.c scan-tree-dump-times ch2 "Conditional combines static and invariant" 1 FAIL: gcc.dg/tree-ssa/copy-headers-8.c scan-tree-dump-times ch2 "Will duplicate bb" 2 FAIL: gcc.dg/tree-ssa/copy-sign-2.c scan-tree-dump-times optimized "ABS" 1 FAIL: gcc.dg/tree-ssa/copy-sign-2.c scan-tree-dump-times optimized ".COPYSIGN" 1 FAIL: gcc.dg/tree-ssa/phi-opt-24.c scan-tree-dump-not phiopt2 "if" Summarily: gcc.sum gcc.dg/pr55152-2.c gcc.sum gcc.dg/tree-ssa/abs-4.c gcc.sum gcc.dg/tree-ssa/backprop-6.c gcc.sum gcc.dg/tree-ssa/copy-sign-2.c gcc.sum gcc.dg/tree-ssa/phi-opt-24.c
[Bug testsuite/112419] [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419 Hans-Peter Nilsson changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |uecker at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Hans-Peter Nilsson --- Hah, I missed that there was indeed some deliberate play with overflow-large objects, so testsuite is the right component designation. Perhaps there's even a missing warning or two. Out of scope for this ticket though. I took the liberty of assigning you the ticket, obvious since you say you're in the process already.
[Bug tree-optimization/112419] New: [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419 Bug ID: 112419 Summary: [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: uecker at gcc dot gnu.org Target Milestone: --- This test started failing with r14-5115-g6e9ee44d96e5 thus: Running /x/gcc/testsuite/gcc.dg/dg.exp ... FAIL: gcc.dg/Wnonnull-4.c (test for excess errors) In gcc.log (after all PASS lines): FAIL: gcc.dg/Wnonnull-4.c (test for excess errors) Excess errors: /o/gcc/gcc/testsuite/gcc.dg/Wnonnull-4.c:144:3: warning: 'fda_n_5' specified size 4294967256 exceeds maximum object size 2147483647 [-Wstringop-overflow=] The same happen for all 32-bit targets (including 64-bit targets when testing with a "-m32"-type option), according to posts to gcc-testresults@ around this commit.
[Bug tree-optimization/110755] [13 Regression] Wrong optimization of fabs on ppc64el at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755 Hans-Peter Nilsson changed: What|Removed |Added Target|powerpc64le |powerpc64le, aarch64 CC||hp at gcc dot gnu.org --- Comment #16 from Hans-Peter Nilsson --- As alluded already in comment #3, this bug is generic: I built gcc-13.2 and verified that it also exists (or perhaps more correctly put, existed) for aarch64, for that version.
[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def since r14-5032-ge3da1d7bb288c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112320 Hans-Peter Nilsson changed: What|Removed |Added Keywords||build CC||hp at gcc dot gnu.org Target||cris-elf --- Comment #4 from Hans-Peter Nilsson --- What target? Anyway, cris-elf too, where build of newlib fails. (Same revision pin-pointed, and the apparently-minimal posted test-case exposes the bug there too. It could theoretically be a different bug from the same commit, but I think horses.)
[Bug target/107567] __atomic_test_and_set generates non-atomic code on armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107567 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED CC||hp at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson --- As gcc will, in the next release (gcc-14), with the program and options in the description, emit a call to __atomic_test_and_set along the expectations in the description, I believe this issue is resolved. Thanks for the report, sorry it took so long for someone to fix it.
[Bug target/109166] Built-in __atomic_test_and_set does not seem to be atomic on ARMv4T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166 --- Comment #9 from Hans-Peter Nilsson --- (In reply to Richard Earnshaw from comment #8) > I'm going to close this as WONTFIX. I guess I'll have to find another PR to lean on, for fixing the underlying cause for the nonatomic code.
[Bug target/109166] Built-in __atomic_test_and_set does not seem to be atomic on ARMv4T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166 --- Comment #7 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #6) > The cause I guess, is just a bad fall-through in the arm/sync.md. Or rather, optabs.cc:expand_atomic_test_and_set, which makes this issue somewhat less target-specific. To wit: /* Failing all else, assume a single threaded environment and simply perform the operation. */
[Bug target/109166] Built-in __atomic_test_and_set does not seem to be atomic on ARMv4T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166
Hans-Peter Nilsson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||hp at gcc dot gnu.org
Last reconfirmed||2023-09-22
--- Comment #6 from Hans-Peter Nilsson ---
Confirmed at r14-4210-g94982a6b9cf4 for arm-unknown-eabi cross from x86-linux.
I was about to enter a mostly-identical report. Exactly the same code is still
emitted (as expected with the bug present). It's not just ARMv4T, it's any ARM
architecture variant below ARMv7.
I expect swp *or at least a call to a library function to be emitted, as
happens for all other builtin atomics*. I think this much is hard to dispute.
The cause I guess, is just a bad fall-through in the arm/sync.md.
For reference, compare to the code emitted at -O2 for:
unsigned char f1 (unsigned char *x)
{
unsigned char c = *x;
*x = 1;
return c;
}
(for which the same code is emitted) and also:
unsigned char f2 (volatile unsigned char *x)
{
return __sync_lock_test_and_set (x, 1);
}
(note the call to the __sync_lock_test_and_set_1 library function)
A related issue is that those gcc doesn't provide those library functions - but
that's a whole different bug.
Though, I agree it seems that SWP should be used in preference to library
calls. Not being ARM-literate, I did some digging which indicates that SWP is
present on "V2S" and later, i.e. including armv4t, which happens to be the
default for arm-eabi, see config.gcc entry for arm-eabi, observe
'target_cpu_cname="arm7tdmi"' (and if necessary consult
gcc/config/arm/arm-cpus.in). I don't know what runtime environment caveats
there are for "swp" to work, or why rth's patch was never committed (referring
to the thread pointed to in #c2).
[Bug middle-end/111523] New: Unexpected performance regression with -ftrivial-auto-var-init=zero for e.g. systemctl unmask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111523 Bug ID: 111523 Summary: Unexpected performance regression with -ftrivial-auto-var-init=zero for e.g. systemctl unmask Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: arm-linux-eabi This issue is opened on request from the author of -ftrivial-auto-var-init (https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630894.html) when I mentioned an local observation, that systemd's use of -ftrivial-auto-var-init=zero caused a slowdown of at least 35% observable with a mostly harmless command such as "systemctl unmask x". The performance-regression was identified as corresponding to https://github.com/systemd/systemd.git commit 1a4e392760 (which adds -ftrivial-auto-var-init=zero to build flags). My own belief is that this kind of slowdown is totally expected with -ftrivial-auto-var-init=zero, but there was disagreement, and bugzilla might help with fixing any issues. Please note that I'm sorry but I'm not going to analyze the problem myself to the level yielding a self-contained test-case. The build environment is Poky (OpenEmbedded) mickledore-4.2 or 4.2.1 (the exact version for the observation was probably mickledore-4.2.1, could have been 4.2; there appears to be no related change in-between). From that version, all other version numbers are deducible; specifically gcc-12.2.0. Regarding systemd, matters are somewhat complicated by Poky pulling https://github.com/systemd/systemd-stable.git (note the "-stable" difference to the first quoted repo) with the version seemingly v253.1 (actually, git hash 6c327d74aa0). The commit-hash introducing -ftrivial-auto-var-init=zero is the same, 1a4e392760cb5, so it seems -stable is just some kind of subset repo. According to the target gcc -v option, it was configured as follows. While the quoted version below is 12.3 (per Poky 4.2.3), from the gcc "recipes", it appears the gcc configuration options were the same in mickledore-4.2: Configured with: ../../../../../../work-shared/gcc-12.3.0-r0/gcc-12.3.0/configure --build=x86_64-linux --host=x86_64-linux --target=arm-poky-linux-gnueabi --prefix=/host-native/usr --exec_prefix=/host-native/usr --bindir=/host-native/usr/bin/arm-poky-linux-gnueabi --sbindir=/host-native/usr/bin/arm-poky-linux-gnueabi --libexecdir=/host-native/usr/libexec/arm-poky-linux-gnueabi --datadir=/host-native/usr/share --sysconfdir=/host-native/etc --sharedstatedir=/host-native/com --localstatedir=/host-native/var --libdir=/host-native/usr/lib/arm-poky-linux-gnueabi --includedir=/host-native/usr/include --oldincludedir=/host-native/usr/include --infodir=/host-native/usr/share/info --mandir=/host-native/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/host-native --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-default-pie --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi- --without-local-prefix --disable-install-libiberty --disable-libssp --enable-libitm --enable-lto --disable-bootstrap --with-system-zlib --with-linker-hash-style=sysv --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --without-isl --with-gxx-include-dir=/not/exist/usr/include/c++/12.3.0 --with-sysroot=/not/exist --with-build-sysroot=/host --enable-poison-system-directories=error --with-system-zlib --disable-static --disable-nls --with-glibc-version=2.28 --enable-initfini-array I'm washing my hands; these configure options are a Poky invention. The build options besides -ftrivial-auto-var-init=zero are (quoting from the log for a random command-line building a file in systemd/systemctl): arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/hp/cfp/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/systemd/1_253.4+git999-r0/recipe-sysroot -Isystemctl.p -I. -I../../../../../../workspace/sources/systemd -Isrc/basic -I../../../../../../workspace/sources/systemd/src/basic -Isrc/fundamental -I../../../../../../workspace/sources/systemd/src/fundamental -Isrc/systemd -I../../../../../../workspace/sources/systemd/src/systemd -I../../../../../../workspace/sources/systemd/src/libsystemd/sd-bus -I../../../../../../workspace/sources/systemd/src/libsystemd/sd-device -I../../../../../../workspace/sources/systemd/src/libsystemd/sd-event -I../../../../../../workspace/sources/sys
[Bug bootstrap/111141] Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41 --- Comment #6 from Hans-Peter Nilsson --- Possibly also *gcc-multilib*
[Bug bootstrap/111141] Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #5 from Hans-Peter Nilsson --- ISTR this one is what you get when you miss *linux-libc-dev*; at least it was for Debian, and last I looked Ubuntu was still a derivative. (Noticed last month when building a Docker suitable for gcc.)
[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300 --- Comment #5 from Hans-Peter Nilsson --- (In reply to Jonathan Wakely from comment #2) > The FAIL should be gone after r14-3812-gb96b554592c5cb Also: thanks!
[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300 --- Comment #4 from Hans-Peter Nilsson --- (In reply to Jonathan Wakely from comment #2) > The FAIL should be gone after r14-3812-gb96b554592c5cb Confirmed > but the underlying > g++ problem is latent. So, keeping this PR open is TRT? Should the title then change to reflect a description of the latent error? Suggestion: "Mangling error exposed by ", but I'm unsure.
[Bug c++/111300] New: [14 Regression] g++.dg/modules/xtreme-header-2_b.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300 Bug ID: 111300 Summary: [14 Regression] g++.dg/modules/xtreme-header-2_b.C Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- After commit r14-3615-gfcede95472ceb4 "Make --enable-libstdcxx-backtrace=auto default to yes" there's a regression in test-results for several targets, among them powerpc64le-unknown-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/794895.html x86_64-pc-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/794904.html s390x-ibm-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795017.html m68k-unknown-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795117.html pru-unknown-elf: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795070.html cris-axis-elf: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795124.html >From a build-log for cris-axis-elf: Running /topsrc/gcc/testsuite/g++.dg/modules/modules.exp ... ... FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) >From that g++.log (mind the cut-and-paste-artefacts): /obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: note: a later '-fabi-version=' (or =0) avoids this error with a c\ hange in mangling^M compiler exited with status 1 FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) Excess errors: /obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: error: mangling of 'constexpr std::stacktrace_entry::_M_get_info(\ std::string*, std::string*, int*) constoperator void (*)(void*, std::stacktrace_entry::uintptr_t, const \ char*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)() const' as '_ZZNKSt16stacktrace_entry11_M_g\ et_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_cvPFvS8_mSA_mmEEv' conflicts with a pr\ evious mangle /obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: error: mangling of 'static constexpr void std::stacktrace_entry::\ _M_get_info(std::string*, std::string*, int*) const_FUN(void*, std::stacktrace_entry::uintptr_t, const c\ har*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)' as '_ZZNKSt16stacktrace_entry11_M_get_infoEP\ NSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENUlPvmPKcmmE_4_FUNES8_mSA_mm' conflicts with a previous mangl\ e /obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: error: mangling of 'std::stacktrace_entry::_M_get_info(std::strin\ g*, std::string*, int*) const::' as '_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11\ char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_clES8_mSA_mm' conflicts with a previous mangle A guess as to the cause, is that there's a bug at the C++ level (hence component "c++") exposed by a module test that includes libstdc++ support for libbacktrace.
[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Hans-Peter Nilsson --- .
[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 --- Comment #7 from Hans-Peter Nilsson --- I don't think it's worthwhile to keep this open, as I'm pretty sure I fixed it for all targets, as the cause wasn't target-related. Otherwise, reopen; if adding a sarcastic comment, then preferably also with a humorous twist.
[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 Hans-Peter Nilsson changed: What|Removed |Added Component|analyzer|testsuite Assignee|efric at gcc dot gnu.org |hp at gcc dot gnu.org --- Comment #5 from Hans-Peter Nilsson --- I'm taking it as I'm about to commit the approved patch. Also, changing component to testsuite.
[Bug analyzer/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 --- Comment #4 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #3) > You are mostly correct. > In C++17, Copy elision is guaranteed to be done here while in earlier > versions it is not and earlier versions of C++ require a copy/move > constructor even if copy elision is to be done. See > https://en.cppreference.com/w/cpp/language/copy_elision for more information. So before this "copy elision", there'd be temporaries constructed and then copied into other temporaries, this in an object that is essentially just declared, without initializer? Weird. Thanks for the pointer; I guess that's the general idea, but here there'd be no difference. IOW, sounds like the patch is right. If we move past the difference in semantics of the idioms in the patch, I still don't see why there actually was error for the original syntax. There must be something in the difference between the hash_map and hash_set declarations. Eagerly awaiting comments on the patch. (Probably not the best way to learn recent C++ standards, but believe it or not, I'm exposed to a worse way, on another track... :)
[Bug other/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 Hans-Peter Nilsson changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/629019.html --- Comment #2 from Hans-Peter Nilsson --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629019.html
[Bug other/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson --- Also seen for cris-elf and m68k-linux (https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/794806.html). Some experimentation says that this is a mismatch between the default C++ version for the host/installed gcc (for me, C++11, I think) and the target (C++17, right?). If you add "-std=c++17" to the invocation line in gcc.log, compilation succeeds. Or, change the form of the newly introduced declarations from auto foobar = foo(); to foo foobar; Not sure why the former is used, it seems negate the benefits of auto and just be more typing. Beware: since I know Very Little C++ of the last decades, I could be completely wrong.
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 --- Comment #10 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #9) > (In reply to Jan Hubicka from comment #8) > > patch posted > > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628231.html > > Yay! I stand ready to revert my ugly cover-up. > I'll even give the posted patch a spin for cris-elf! JFTR, as mentioned in a reply to the patch, unfortunately it regresses four tests: gcc.sum gcc.c-torture/execute/pr95731.c gcc.sum gcc.dg/pr46309-2.c gcc.sum gcc.dg/torture/pr63464.c gcc.sum gcc.dg/tree-ssa/pr95731.c
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 --- Comment #9 from Hans-Peter Nilsson --- (In reply to Jan Hubicka from comment #8) > patch posted > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628231.html Yay! I stand ready to revert my ugly cover-up. I'll even give the posted patch a spin for cris-elf!
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 --- Comment #7 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #5) > Not seeing any action for this regression for three weeks, for tracking > purposes I'm considering xfailing this test-case for cris-* after another > week. Now xfailed for cris-*-* by r14-3418-g0c2633dd09f281; unfortunately without a working changelog annotation so it didn't automatically show up here.
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #5 from Hans-Peter Nilsson --- A quick survey of recent test-results show this regression happens for many targets. Besides the reported: powerpc64le-unknown-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793193.html Also fails for: pru-unknown-elf https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/792102.html s390x-ibm-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/792106.html m68k-unknown-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793249.html cris-axis-elf https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793462.html But, curiously not for: x86_64-pc-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/792111.html i686-pc-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/792104.html aarch64-unknown-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793190.html arm-unknown-linux-gnueabihf https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793191.html Not seeing any action for this regression for three weeks, for tracking purposes I'm considering xfailing this test-case for cris-* after another week.
[Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS, ARM, and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021 --- Comment #17 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #12) > I think a "too broad" dependence isn't bad. The cris specific solution also > looks manageable, though I wonder what's special about x-protos.h, knowing > very little of that area. Not very special, it's just that there's a now dependence on tree.h and its generated contents where for tm-protos.h there has been none before. The reasons seem avoidable at this time, but I think it's nominally valid to have that dependency. On the one hand, introducing a new dependency where there has been none before and dealing with the fallout we now see is awkward, but on the other hand pragmatically the dependence on tree.h for $(TM_P) is trivial enough that a parallel build "raced" to fulfill it. IOW, shouldn't affect build time by any measure. (Not closing this PR yet in case maintainers go forward for the other tm-protos.h-affected targets)
[Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS, ARM, and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021 --- Comment #11 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #8) > I might have misunderstood things of course, ...like still having to include tree.h to get the code_helper class definition. Doh!
[Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS, ARM, and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021 --- Comment #9 from Hans-Peter Nilsson --- https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627444.html
[Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS, ARM, and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021 --- Comment #8 from Hans-Peter Nilsson --- (In reply to Kewen Lin from comment #6) > > btw, thanks for the suggestion on "defaulting to NULL or something" in ML, > but I guess a default value like zero rather than ERROR_MARK has to base on > the assertion that the default value is equal to ERROR_MARK, IMHO it isn't > quite maintainable. I believe you could add a code_helper constructor for another type, maybe even "int"? Then the "default" value for the code_helper argument for the legitimate address hook function would just look like "code_helper = 0". Maybe that's too error-prone and a pointer-type or some entirely different type would be better. I might have misunderstood things of course, but that's what I mean by "or something".
[Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS, ARM, and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #7 from Hans-Peter Nilsson ---
(In reply to Kewen Lin from comment #6)
> (In reply to Hans-Peter Nilsson from comment #5)
> [...]
> but the concern is that one day some file just includes tm_p.h but
> not recog.h, the issue will show up again. I'm thinking how to deal with the
> problems on ${port}-protos.h, adding $(TREE_H) in TM_P is an alternative,
> but not sure if people would think it's an overkill since the current
> affected ports are:
> [...]
Exactly; I'm happy that we seem to be on the same page here.
I'm testing a patch for CRIS (making the hook function just a wrapper,
reverting the cris-protos.h change) that may be re-usable for the other targets
similarly affected.
[Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS, ARM, and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021 --- Comment #5 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #4) > (In reply to Andrew Pinski from comment #1) > > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627435.html > > Nope, that just fixes recog.h. See the quoted error; it's the patched > *-protos.h. ...but I'm "guessing" that it will appear to work even for the tm-protos.h-on-tree.h dependency, just incidentally.
[Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS, ARM, and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021 --- Comment #4 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #1) > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627435.html Nope, that just fixes recog.h. See the quoted error; it's the patched *-protos.h.
[Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS, ARM, and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021 --- Comment #3 from Hans-Peter Nilsson --- (In reply to Kewen Lin from comment #2) > Thanks for reporting, I think the culprit is r14-3093 instead of r14-3092? Not for this PR!
[Bug bootstrap/111021] New: [14 Regression] Serial build broken for CRIS, ARM, and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021 Bug ID: 111021 Summary: [14 Regression] Serial build broken for CRIS, ARM, and others Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: linkw at gcc dot gnu.org Target Milestone: --- Since r14-3092-g165b1f6ad1d396 "targhooks: Extend legitimate_address_p with code_helper [PR110248]", build has been broken (at least with "GNU Make 4.3") for *serial* builds (no "-j" option) for those target where that commit added an include of tree.h was added, exposed by building for example cris-elf and arm-eabi (wrapped lines copy-pasted): g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/srctop/gcc -I/srctop/gcc/build -I/srctop/gcc/../include -I/srctop/gcc/../libcpp/include \ -o build/gencondmd.o build/gencondmd.cc In file included from /srctop/gcc/tree.h:23, from /srctop/gcc/config/arm/arm-protos.h:26, from ./tm_p.h:5, from build/gencondmd.cc:29: /srctop/gcc/tree-core.h:145:10: fatal error: all-tree.def: No such file or directory 145 | #include "all-tree.def" | ^~ compilation terminated. make[2]: *** [Makefile:2918: build/gencondmd.o] Error 1 At a glance, (at least) build/gencondmd.o lacks a dependency on the generated all-tree.def. But adding only that dependency leads to a similar error for a missing of tree-check.h; looks like TREE_H contains the right bits. Maybe it's as "simple" as including $(TREE_H) in TM_P (or a new intermediary macro) or add $(TREE_H) to all build/gen*.o rules where the gen*.cc includes "tm_p.h" (but within the filter-out for build/gencondmd.o). I *did* try the latter; simply adding $(TREE_H) (within the filter-out call) for build/gencondmd.o and that seemed to work, but it doesn't seem *right* and may work just by happenstance, as other build/gen*.o seems like they could fail given unfortunate timing or Makefile tweak. It seems proper to leave that headache to the author of that the offending commit. (I'm going to bail out for CRIS with a patch to cris-protos.h, wrapping the function that needs to be prototyped so it doesn't need to refer to ERROR_MARK.)
[Bug libstdc++/108672] [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108672 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #5 from Hans-Peter Nilsson --- Re-fixed and re-closed.
