[Bug rtl-optimization/20242] Pessimizing effects of defining EXTRA_MEMORY_CONSTRAINT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20242 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #7 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #6) > I am not sure if this specific issue applies any more since the move to IRA > and LRA. And even more EXTRA_MEMORY_CONSTRAINT support was removed in > r5-1241-g777e635f1a6cab and memory constraints are handled in the .md file > now. Wow, this is *old*. Right; this is now a WONTFIX.
[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #15 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #14) > > > Why are you all talking about C++? Yes, the docs mention C++ but this is a > > request for C. > > Because Wunterminated-string-initialization was added to warn about a > difference between c and c++ too. Again: yes, the docs mention C++, but this is a request for C.
[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #13 from Hans-Peter Nilsson --- The proposal makes sense to me too, particularly after reading the docs. (Unless there's already a way to silence the warning for particular constructs?) Why are you all talking about C++? Yes, the docs mention C++ but this is a request for C.
[Bug middle-end/116988] Documentation for local register variables with inline-asm could have better example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116988
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #1 from Hans-Peter Nilsson ---
(In reply to Andrew Pinski from comment #0)
>
> It should be :
> ```
> int *t1 = …;
> register int *p1 asm ("r0") = …;
> register int *p2 asm ("r1") = t1;
> register int *r0 asm ("r0");
> asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
> int result = r0;
>
> ```
Typo spotted. Always test-compile your suggestions. ;-)
[Bug middle-end/116920] GCC should warn about fall through from a case to a default (without any expressions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116920 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson --- (In reply to Xi Ruoyao from comment #0) > In this test case "case 1919:" is either redundant, De facto redundant, sure. > or indicating a > programming error. Thus it'd be better if we emit a warning here. That's debatable. A special warning option may be in order, but I can very well see the above as a coding style issue, with arguments for both sides.
[Bug libstdc++/116895] [15 Regression] Many c++ regressions after r15-3859-g63a598deb0c9fc for (non-arm) newlib targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116895 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Hans-Peter Nilsson --- .
[Bug libstdc++/116895] [15 Regression] Many c++ regressions after r15-3859-g63a598deb0c9fc for (non-arm) newlib targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116895 Hans-Peter Nilsson changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Septemb ||er/664105.html Keywords||patch, testsuite-fail Last reconfirmed||2024-09-30
[Bug libstdc++/116895] New: [15 Regression] Many c++ regressions after r15-3859-g63a598deb0c9fc for (non-arm) newlib targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116895
Bug ID: 116895
Summary: [15 Regression] Many c++ regressions after
r15-3859-g63a598deb0c9fc for (non-arm) newlib targets
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: hp at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: cris-elf
There are 100+ regressions when running the g++ testsuite for newlib
targets (probably excepting ARM-based ones) e.g cris-elf after commit
r15-3859-g63a598deb0c9fc "libstdc++: #ifdef out #pragma GCC
system_header", which effectively no longer silences warnings for
gcc-installed system headers. Some of these regressions are fixed by
r15-3928. For the remaining ones, there's in g++.log:
FAIL: g++.old-deja/g++.robertl/eb79.C -std=c++26 (test for excess errors)
Excess errors:
/gccobj/cris-elf/libstdc++-v3/include/cris-elf/bits/ctype_base.h:50:53: \
warning: overflow in conversion from 'int' to 'std::ctype_base::mask' \
{aka 'char'} changes value from '151' to '-105' [-Woverflow]
This is because the _B macro in newlib's ctype.h (from where the
"_" macros come) is bit 7, the sign-bit of 8-bit types:
#define _B 0200
Using it in an int-expression that is then truncated to 8 bits will
"change" the value to negative for a default-signed char. If this
code was created from scratch, it should have been an unsigned type,
however it's not advisable to change the type of mask as this affects
the API. The least ugly option seems to be to silence the warning by
explict casts in the initializer, and for consistency, doing it for
all members.
Patch coming up.
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Hans-Peter Nilsson --- I'm closing this but hope to soon submit follow-up patch adding that dg-final directive, and then I'll tag that with this PR.
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701
--- Comment #5 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #4)
> but if the test fails before the "close"-line is reached
> (consider the multiple "stop"-lines), it wouldn't help.
I think I'll do both: the added close-line has its merits not the least
aesthetically. Also, a
! { dg-final { remote_file target delete "fort.10" } }
(as applicable) needs to go in a lot more test-cases when reasoning as above,
so it serves better as a general clean-up.
(Many other "artefacts" are left in obj/gcc/testsuite/gfortran, but I'll leave
that to Someone Else.)
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 --- Comment #4 from Hans-Peter Nilsson --- (In reply to anlauf from comment #2) > Can you test if adding a line > > close(10, status="delete") > > before the > > end program memain > > fixes the issue? If so, such a fix is pre-approved; you can also ask Thomas. I considered that, and I'm pretty sure that'll help for the case at hand (the unsigned_22 test passes for the first run but fails subsequent runs for the same reason), but if the test fails before the "close"-line is reached (consider the multiple "stop"-lines), it wouldn't help.
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 Hans-Peter Nilsson changed: What|Removed |Added Component|target |testsuite --- Comment #1 from Hans-Peter Nilsson --- This is a testism. You'll only see this test failing when: - Testing for a non-fd_truncate target (usually a simulator that can't chsize or ftruncate, see the effective_target). - Also testing unsigned_22 in the same run. - Testing "serially" or "unlucky" with the parallel test run such that unsigned_22 has run before write_check3. The cause is that the unsigned_22 test (added in the named commit) leaves an output file "fort.10", which is picked up by write_check3 which then calls libgfortran raw_truncate. I guess the gfortran "unit-machinery" wants to clear that file if it exists. Some option is needed to make the "fort.10" file name unique or something to that effect in a way that it isn't picked up by write_check3. A dg- cleanup function might do, perhaps one exists? A "git grep -w fort" in testsuite/lib catches nothing though.
[Bug other/116744] New: RFE: can generated SARIF file be a container for "everything" needed for a bug-report against gcc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116744 Bug ID: 116744 Summary: RFE: can generated SARIF file be a container for "everything" needed for a bug-report against gcc? Product: gcc Version: unknown Status: UNCONFIRMED Keywords: SARIF Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Target Milestone: --- In PR116724, we had this conversation: > The use-case I was thinking of, is for the SARIF output to be > a nice containment of the non-source-code part of bug-reports: "instead of > quoting stderr, use --diagnostics-format=sarif-file and send > sourcename.sarif". To which dmalcolm replied: Sounds like an interesting idea; can you open this as a separate RFE please? Me (still quoting conversation from that "bug"): > But, to fulfill that, more is needed, including the gcc > arguments. (Maybe that's all.) dmalcolm: I've added support for capturing the command-line arguments in GCC 15: https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658206.html though note that it's capturing the arguments as supplied by the driver to e.g. cc1, as opposed to those that the user supplied to the driver. ... FWIW that SARIF can capture embedded copies of source files of interest, and that the GCC SARIF generation code does this for any source file mentioned in a diagnostic. So perhaps the .sarif file could contain everything. me (now continuing the conversation here): (I suppose driver and preprocessor error message don't mention cc1! And then, at least I'm happy with cc1 as long as the contained file is the preprocessed file.) So, what's missing may be for the output-sarif-file to support holding the actual input. I didn't mention it because in the back of my mind I was thinking that could be problematic: what if the user wanted to file a report but not expose his actual source code, instead separately a cut-down derivative? On the other hand, using the option to output this complete-report-contents file is a deliberate action, so we should be good as long as the option has a well-chosen name i.e. not riding along on -diagnostics-format=sarif-file (I amend that part of the request).
[Bug other/116724] RFE: can generated SARIF diagnostics contain untranslated messages (plus translations?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724 --- Comment #4 from Hans-Peter Nilsson --- (In reply to David Malcolm from comment #1) > Perhaps we should try to capture both the untranslated text and the > translated text? SARIF has various abilities for handling translations. Works for me! The use-case I was thinking of, is for the SARIF output to be a nice containment of the non-source-code part of bug-reports: "instead of quoting stderr, use --diagnostics-format=sarif-file and send sourcename.sarif". But, to fulfill that, more is needed, including the gcc arguments. (Maybe that's all.) I don't see that included, right? Sorry for the "creaturization request"!
[Bug target/116701] New: [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701
Bug ID: 116701
Summary: [15 Regression] gfortran.dg/write_check3.f90 suddenly
fails for non-fd_truncate targets
Product: gcc
Version: 15.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: cris-elf
I investigated my autotester signalling a failure appearing between (good)
r15-3525-gbb8dd0980b39cf and (bad) r15-3528-g6749c69ae143ed, with execution
starting to fail for gfortran.dg/write_check3.f90 as follows:
Running
/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp
...
(...other failing tests, but that are not regressions, pruned...)
FAIL: gfortran.dg/write_check3.f90 -O0 execution test
FAIL: gfortran.dg/write_check3.f90 -O1 execution test
FAIL: gfortran.dg/write_check3.f90 -O2 execution test
FAIL: gfortran.dg/write_check3.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/write_check3.f90 -O3 -g execution test
FAIL: gfortran.dg/write_check3.f90 -Os execution test
In the gfortran.log:
PASS: gfortran.dg/write_check3.f90 -O0 (test for excess errors)
spawn cris-elf-run ./write_check3.exe^M
Fortran runtime error: required ftruncate or chsize support not present^M
^M
Error termination. Backtrace:^M
^M
Could not print backtrace: executable file is unexpected ELF class^M
FAIL: gfortran.dg/write_check3.f90 -O0 execution test
I was happy seeing that this was "obviosly" r15-3526 and that I had to change
the first line of write_check3.f90 as "! { dg-do run { target fd_truncate } }"
but doing due diligence I noticed something weird... I can't repeat the
failure!
No matter what I do, this only appears in my autotester. (Trying to replicate
the environment, checking a native build for valgrind-detectable
errors...nothing - at least not yet.) I'll assume PEBKAC, and hope staring at
simulator traces will help, but I need a tracker number. I'll set the
component to target and assign myself so no-one feels compelled to take action.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #260 from Hans-Peter Nilsson --- Random advice that some of you know, but it's also easy to forget: reorg (the delayed-branch-slot-filling pass) is a usual suspect: there be dragons. So, when suspecting wrong-code for DELAY_SLOTS such as sh, also try -fno-delayed-branch.
[Bug middle-end/112985] LOGICAL_OP_NON_SHORT_CIRCUIT unconditionally execute comparison even if it's very expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112985 --- Comment #5 from Hans-Peter Nilsson --- (In reply to Xi Ruoyao from comment #4) > But LOGICAL_OP_NON_SHORT_CIRCUIT=0 is > really not a good thing (see PR116166 where it slows down bootstrapping GCC). It may be true for both loongarch and risc-v, but do you have a reason to think that's true for all targets?
[Bug other/116525] Commit hook allows empty ChangeLog entry description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116525 --- Comment #2 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #1) > I think it is more related the changelog for testsuite rather than anything > else. Can you please elaborate? There are scripts in contrib/gcc-changelog/ yes, common to ChangeLog generation and server-side pre-commit hook, but I can't see that this empty-entry wart is specific to entries for the testsuite. Perhaps the contrib/mklog.py script can be improved too, so it emits e.g. "PLACEHOLDER." instead of leaving the entry empty; more eye-catching. Did you use that script or did you write the entry in the example commit "manually"?
[Bug other/116525] New: Commit hook allows empty ChangeLog entry description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116525 Bug ID: 116525 Summary: Commit hook allows empty ChangeLog entry description Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: pinskia at gcc dot gnu.org Target Milestone: --- Looks like the git commit hook allows empty ChangeLog entry descriptions. Consider r15-3096-gda043f9c7172, which has: ... gcc/testsuite/ChangeLog: * gcc.dg/torture/pr116420.c: ... I'm guessing "Use signed char to handle default-unsigned char targets" or similar was intended, just not an empty line. Perhaps it's as simple as disallowing ChangeLog entry lines that end with ":" in the server-side commit hook.
[Bug rtl-optimization/115883] [15 Regression] late-combine exposing LRA problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115883 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Depends on||116236 --- Comment #5 from Hans-Peter Nilsson --- As per "This PR is about the presumed LRA bug, not about the peephole2 patterns incidentally no longer matching, or of performance for CRIS with late-combine" I'm closing this, see my earlier comments. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236 [Bug 116236] [LRA] [M68K] ICE insn does not satisfy its constraints
[Bug rtl-optimization/115883] [15 Regression] late-combine exposing LRA problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115883 --- Comment #4 from Hans-Peter Nilsson --- The underlying issue was fixed by the commit fixing PR116236, i.e. commit r15-2937-g3673b7054ec268c445620b9c52d25e65bc9a7f96, so I'll close this but refresh the attribute-copying patch (adjusting the commit log).
[Bug target/116236] [LRA] [M68K] ICE insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236 --- Comment #27 from Hans-Peter Nilsson --- (In reply to GCC Commits from comment #23) > The trunk branch has been updated by Richard Sandiford > : > > https://gcc.gnu.org/g:3673b7054ec268c445620b9c52d25e65bc9a7f96 > > commit r15-2937-g3673b7054ec268c445620b9c52d25e65bc9a7f96 I had a hunch, verified by reverting this commit locally: This commit also fixed the underlying LRA bug in PR115883. Nice!
[Bug libstdc++/116362] [15 Regression] libstdc++ assumes newlib is configured to include iconv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116362 Hans-Peter Nilsson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Hans-Peter Nilsson --- fix committed
[Bug libstdc++/116362] [15 Regression] libstdc++ assumes newlib is configured to include iconv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116362 Hans-Peter Nilsson changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hp at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-08-13 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |15.0
[Bug libstdc++/116362] New: [15 Regression] libstdc++ assumes newlib is configured to include iconv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116362 Bug ID: 116362 Summary: [15 Regression] libstdc++ assumes newlib is configured to include iconv Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org Target Milestone: --- For newlib targets, several tests now fail since d63b6d8b4944..e7d88ff8aaa2 due to undefined references to iconv, iconv_open, iconv and/or iconv_close: libstdc++.sum 20_util/duration/io.cc libstdc++.sum std/time/clock/file/io.cc libstdc++.sum std/time/clock/gps/io.cc libstdc++.sum std/time/clock/local/io.cc libstdc++.sum std/time/clock/system/io.cc libstdc++.sum std/time/clock/tai/io.cc libstdc++.sum std/time/clock/utc/io.cc libstdc++.sum std/time/exceptions.cc libstdc++.sum std/time/format.cc libstdc++.sum std/time/hh_mm_ss/io.cc libstdc++.sum std/time/leap_seconds/io.cc libstdc++.sum std/time/time_zone/get_info_local.cc libstdc++.sum std/time/zoned_time/1.cc libstdc++.sum std/time/zoned_time/io.cc Looks like libstdc++-v3 incorrectly assumes support is present for a newlib build. There is iconv support in newlib, but it's optional and default off. I've never built with it configured on, so there may be dragons.
[Bug rtl-optimization/115883] [15 Regression] late-combine exposing LRA problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115883 Hans-Peter Nilsson changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-07-17 Status|UNCONFIRMED |NEW
[Bug rtl-optimization/115932] New: [15 Regression] performance regression after r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115932 Bug ID: 115932 Summary: [15 Regression] performance regression after r15-1619-g3b9b8d6cfdf593 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: jskumari at gcc dot gnu.org Target Milestone: --- Target: cris-elf With r15-1619-g3b9b8d6cfdf593 there was a change in test-suite results for cris-elf that prompted me to run the coremark benchmark test before/after this commit with my usual "-O2 -march=v10" options. See commit r15-1619-g3b9b8d6cfdf593 where I goofed and incorrectly write that there were no changes in results for coremark. However, there *is* a performance regression, from 5179918 to 5181696 cycles i.e. 0.034%. This PR is intended to keep track of similar results for other targets and perhaps a tweak amending r15-1619-g3b9b8d6cfdf593.
[Bug rtl-optimization/115883] [15 Regression] late-combine exposing LRA problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115883 --- Comment #3 from Hans-Peter Nilsson --- >From r15-2024-ga01b40c047334c (disabling late-combine for CRIS), you'll need -flate-combine-instructions to expose the bug.
[Bug rtl-optimization/115883] [15 Regression] late-combine exposing LRA problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115883 Hans-Peter Nilsson changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-July/65 ||7097.html --- Comment #2 from Hans-Peter Nilsson --- (In reply to Eric Botcazou from comment #1) > Are you sure about REG_POINTER though? IIRC the PA port does rely on it for > correctness. Regarding it not being a stable atrtibute? No; see the patch submission (linked now), CC:ed to vmakarov for clarification.
[Bug rtl-optimization/115883] New: [15 Regression] late-combine exposing LRA problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115883
Bug ID: 115883
Summary: [15 Regression] late-combine exposing LRA problems
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
Target Milestone: ---
Since the introduction of the late-combine optimization in
r15-1579-g792f97b44ffc5e, test-results for CRIS have shown regressions for the
following tests, all getting an ICE:
gcc.sum gcc.target/cris/rld-legit1.c
gcc.sum gcc.target/cris/rld-legit2.c
gcc.sum gcc.target/cris/torture/pr24750-2.c
Those are all basically the same code tested from different angles. In the
code, an address, using two registers, is generated as desirable and valid.
While it's valid for hard-registers, there's pressure from an asm clobbering
all hard-regs that can be part of an address, so spills are introduced.
Typically there's one spill to a special register, the other to stack. This
code used to be a coverage test for the CRIS implementation of the reload macro
LEGITIMIZE_RELOAD_ADDRESS. To wit, the RTX for the spilled memory expression
looked like this:
(mem:QI (plus:SI (sign_extend:SI (mem:HI (reg/v/f:SI 32 [ a ]) [1 *a_6(D)+0 S2
A8])) (reg/v/f:SI 33 [ y ])) [0 *_3+0 S1 A8]).
Though, for brevity, let's use the "compact" representation:
[sign_extend([r32:SI])+r33:SI] (sadly the inner mode, HImode is missing in the
compact representation; probably just a bug).
The original reload problem is similar to what happens now (cf. PR24750):
reload (now LRA) splits the address at the mem instead of at the sign_extend,
and
[sign_extend(r32:SI)+r33:SI] is *not* valid, whereas [r32:SI+r33:SI] is, in
addition to the original. The ICE now, is that the former address is generated
by LRA, and later not recognized:
/src/gcc/gcc/testsuite/gcc.target/cris/rld-legit1.c: In function 'f':
/src/gcc/gcc/testsuite/gcc.target/cris/rld-legit1.c:21:1: error: insn does not
satisfy its constraints:
`
(insn 14 21 15 2 (parallel [
(set (reg/i:SI 10 r10)
(sign_extend:SI (mem:QI (plus:SI (sign_extend:SI (reg:HI 9 r9
[39]))
(reg:SI 13 r13 [37])) [0 *_3+0 S1 A8])))
(clobber (reg:CC 19 ccr))
]) "/x/gcc/gcc/testsuite/gcc.target/cris/rld-legit1.c":21:1 52
{extendqisi\
2}
(nil))
during RTL pass: reload
'''''
(The astute reader is aware that LRA identifies as reload in dump files.)
With LRA, there's no mechanism corresponding to LEGITIMIZE_RELOAD_ADDRESS: LRA
seems to split-up spilled parts of the memory address. These tests are instead
now coverage for peephole2 patterns that cobbles together the split-up parts to
emit the same assembly as for reload, for the intended addressing mode. This
transformation is not performance-critical, the peephole2 patterns were added
because failing to do so would have constituted a regression for the
reload-to-LRA transition. These patterns are naturally brittle, matching one
of the possible split-up sequences from LRA. They have remained surprisingly
stable since the LRA transition, up to late-combine. Thankfully, these tests
seem to be the only thing functionally failing with the late-combine
introduction.
This PR is about the presumed LRA bug, not about the peephole2 patterns
incidentally no longer matching, or of performance for CRIS with late-combine.
I've analyzed as far as the difference being due to a lack of REG_POINTER for
the "base" register in the address, which seems to be due to an oversight in
combine.cc, only forward-propagated by the first of the late-combine passes.
It seems this is just exposing a flaw in LRA though; the invalid address should
not have been generated, as REG_POINTER is not a stable attribute (IIUC); its
presence exposes optimization opportunities but its absence should not cause
invalid code or ICE.
[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 --- Comment #28 from Hans-Peter Nilsson --- (In reply to GCC Commits from comment #27) > The releases/gcc-13 branch has been updated by Wilco Dijkstra > : Thanks!
[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 Hans-Peter Nilsson changed: What|Removed |Added Known to fail||13.3.1 CC||hp at gcc dot gnu.org --- Comment #26 from Hans-Peter Nilsson --- (In reply to GCC Commits from comment #25) > The master branch has been updated by Wilco Dijkstra : Are you considering back-porting this to other branches (like gcc-13) or is there another reason this PR is still open? The commit applies cleanly there, but is untested. Asking for a friend. :)
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 --- Comment #14 from Hans-Peter Nilsson --- (In reply to r...@cebitec.uni-bielefeld.de from comment #13) > I've completed the sparc64-linux comparison now: no regressions with a > non-bootstrap build and your patches either, thus the same situation as > on Solaris. Thank you for doing this! I was a bit worried you'd find something, so I'd lose the incentive to get a sparc64 -or general- bootstrap environment working, one way or the other. (j/k :)
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 --- Comment #12 from Hans-Peter Nilsson --- (In reply to r...@cebitec.uni-bielefeld.de from comment #11) > > --- Comment #10 from Hans-Peter Nilsson --- > >> The failure is even earlier here: in a sparc64-unknown-linux-gnu > >> bootstrap, building a libstdc++ .gch file in stage 2 breaks: > > > > Great, thanks! That means that tricking my pc into believing it's a sparc > > by > > means of using the binfmt machinery that Jeff mentioned in the thread where > > I > > mentioned the revert on gcc-patches, would work. (I don't have the details > > and > > don't remember if I'd actually tried it, certainly not recently; I just know > > about the concept.) > > I can't help but wonder if this wouldn't be a total waste of your time: > considering what the qemu wiki docments for SPARC support > > https://wiki.qemu.org/Documentation/Platforms/SPARC > > seems not too encouraging for 64-bit systems. Thanks for the warning, but I'm confused as it doesn't look too bad to me; for example the status field for SPARC64 says "working" at least for non-historic qemu versions. What am I missing? Are you thinking of something specific there? > When I think about what > it took myself to get recent macOS working on qemu-kvm (although the > procedure is resonably well documented, with firmware and all > available), I'd consider such an attempt a positive nightmare. Also, I wouldn't be using qemu-system-sparc64 IIUC: with the binfmt trick I'd be using qemu-user. That "experience" (assuming success) would also lead to a template or identical solution for other targets, which is the most interesting part. The cfarm is nice to have, but the machines are a bit crowded. > When all it takes for you to either get your ssh client working to > access a ready-made and not too slow SPARC system (or in the worst case, > build OpenSSH from source), I know which route I'd take ;-) A different nightmare, leading to a nightmare of chasing a bootstrap failure on a system I'm not familiar with (referring to solaris on the cfarm machine). > > What's not so great is that the described reproducer is a bootstrap, so the > > debug situation is unpleasant. The first step I'd do, would be to just do a > > cross-build (or native --disable-bootstrap) and just run the testsuite > > before/after the patch-set (or just 933ab59c59bdc1) and see if the problem > > manifests there. > I've tried that now on both > > * sparc-sun-solaris2.11 (c and c++ only): no additional testsuite > failures are apparent there, which is not too astonishing given that > the bootstrap failure occurs in stage 3, suggesting a mis-compiled > stage 2 cc1plus, and Oh, too bad. Thanks for doing that! > * sparc64-unknown-linux-gnu (again, c and c++ only): there are testsuite > failures all over the place, but I'd have to perform another bootstrap > with your patches removed to make an exact comparison. Hm, the part where you compare results against a baseline is pretty central. One the one hand, when it doesn't manifest for sparc64-solaris just through the testsuite, the odds are against it manifesting that simple for sparc64-linux. On the other hand, an existing reproducer is so much easier to handle. Thank you and thanks in advance for the last step!
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 --- Comment #10 from Hans-Peter Nilsson --- (In reply to r...@cebitec.uni-bielefeld.de from comment #9) > > --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE > Uni-Bielefeld.DE> --- > >> --- Comment #6 from Hans-Peter Nilsson --- > [...] > >> versions.) BTW, it'd be nice to know it it reproduces for sparc-linux as > >> well. > > > > I happen to have a Linux/sparc64 LDom around: I'll give it a whirl. > > The failure is even earlier here: in a sparc64-unknown-linux-gnu > bootstrap, building a libstdc++ .gch file in stage 2 breaks: Great, thanks! That means that tricking my pc into believing it's a sparc by means of using the binfmt machinery that Jeff mentioned in the thread where I mentioned the revert on gcc-patches, would work. (I don't have the details and don't remember if I'd actually tried it, certainly not recently; I just know about the concept.) What's not so great is that the described reproducer is a bootstrap, so the debug situation is unpleasant. The first step I'd do, would be to just do a cross-build (or native --disable-bootstrap) and just run the testsuite before/after the patch-set (or just 933ab59c59bdc1) and see if the problem manifests there. It's also not great (from the view of gcc targeting architectures with delay-slots) that this isn't at the top of my queue anymore, since the immediate situation was resolved; as mentioned I committed the revert. I'll get to it eventually, but if someone is intrigued enough by the prospect of a 0.36%-ish performance improvement (see commit log for the culprit commit) to do such a --disable-bootstrap regtest, that'd help. :) Thank you for your patience and for the help.
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 --- Comment #6 from Hans-Peter Nilsson --- BTW, I see the target list says sparc*-sun-solaris2.11 which seems a cutnpasto from some ancient template: that particular version is installed on cfarm211 and a build log for a recent gcc checkout says "Configuration sparc-sun-solaris2.11 not supported" for the gcc dir. (Please correct the versions.) BTW, it'd be nice to know it it reproduces for sparc-linux as well.
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 Hans-Peter Nilsson changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Hans-Peter Nilsson --- The bootstrap issue should be resolved with r15-916, which can't appear here because the commit log of a revert must not be edited. Please don't close this PR, the revert is just a band-aid.
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 --- Comment #4 from Hans-Peter Nilsson --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > You should use cfarm216 instead: it's way faster than the others and > runs Solaris 11.4, which is the only OS release supported on trunk. I can't reach cfarm216, something with my ssh setup is too old. :( Also, I just realized it can't be a plain NULL basic_block, because that'd have shown a SEGV in resource.c. All the more interest in a way to reproduce on cfarm210 or cfarm211. > > --- Comment #1 from Hans-Peter Nilsson --- > > Sorry. I bet something in reorg actually uses a barrier insn as a > > reference. > > I'll revert those three patches unless I can fix the problem within 24 hours > > (not counting regtest-time). > > Ok. For this night's bootstrap, I'm using the tree at the revision > before the culprit patch. I tried to revert just that one, but failed > (conflicts and manual resolution failed compiling stage 1 libgcc). There's two other commits after the culprit, that depends on it functionally and contextually, so you have to revert those too. Either way, if you prefer to revert (the failing one and the two after that one obviously in opposite order, I'd be thankful. I'll likely land there myself as I currently have no way to reproduce the problem.
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |hp at gcc dot gnu.org Last reconfirmed||2024-05-29 --- Comment #1 from Hans-Peter Nilsson --- Sorry. I bet something in reorg actually uses a barrier insn as a reference. I'll revert those three patches unless I can fix the problem within 24 hours (not counting regtest-time). Incidentally, can you please post a configure line for cfarm210 or cfarm211 that works? (A no-options line failed to find some library during bootstrap so I originally bailed on sparc testing.)
[Bug rtl-optimization/115182] [15 Regression] gcc.target/cris/pr93372-47.c at r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115182 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Hans-Peter Nilsson --- Final verification: pr93372-47.c again passed in my autotester, at r15-884-ge5fc5d42d25c86.
[Bug rtl-optimization/115182] [15 Regression] gcc.target/cris/pr93372-47.c at r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115182 Hans-Peter Nilsson changed: What|Removed |Added Last reconfirmed||2024-05-25 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 Hans-Peter Nilsson changed: What|Removed |Added Keywords|testsuite-fail | --- Comment #11 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #10) > This should be fixed now. I applied the commit r15-815-g5b9b3bae33cae to r15-518 and built arith-rand-ll.c with -O2 -fno-delayed-branch -fno-ivopts -march=v10 (like above, to avoid ivopts and delayed-branch issues and the simulation numbers are even better than with r15-517: Basic clock cycles, total @: 13653025 Memory source stall cycles: 78259 So, verified. Thanks! ps. I removed the testsuite-fail keyword as that belongs to PR115182.
[Bug rtl-optimization/115182] New: [15 Regression] gcc.target/cris/pr93372-47.c at r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115182 Bug ID: 115182 Summary: [15 Regression] gcc.target/cris/pr93372-47.c at r15-518-g99b1daae18c095 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization, testsuite-fail Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: law at gcc dot gnu.org, pinskia at gcc dot gnu.org, rguenth at gcc dot gnu.org, unassigned at gcc dot gnu.org Depends on: 115144 Target Milestone: --- Target: cris-elf +++ This bug was initially created as a clone of Bug #115144 +++ This bug is only about the unfilled delay-slot that caused gcc.target/cris/pr93372-47.c to fail starting at r15-518-g99b1daae18c095; not about the incidental (possibly generic but at least unrelated to delay-slot-filling) performance regression I noticed. The bug seems to be due to a bug in reorg.cc or actually, in resource.cc. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 [Bug 115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144
--- Comment #7 from Hans-Peter Nilsson ---
(In reply to Richard Biener from comment #6)
> For gcc.c-torture/execute/arith-rand-ll.c, does it help to replace the exit
> (0) call with a return 0 statement?
No. FWIW, it also doesn't help renaming and wrapping main to xmain
__attribute__ noipa.
> Looking at gcc.target/cris/pr93372-47.c what we do here is sink tot_bits +=
> n_bits into the else { of the in-loop conditional, in particular we sink
> it right before the exit conditional in the loop. That's exactly what
> we are supposed to do[...]
Yes; see previous comments. I'd say the changes in random_bitstring are no
longer "interesting". I've also analyzed the unfilled delay-slot signalled by
gcc.target/cris/pr93372-47.c to be because of a bug in that pass. (Not the
same, but events are amusingly parallel to the bug that made me add that
test-case.)
> Note that the sinking doesn't increase register lifetime (one of the reasons
> of the previous heuristic), esp. if we'd go one step further and sink
> to the start of the else { block rather than right before the exit
> conditional. But I'd guess that wouldn't help the delay-slot filling here?
Sorry, I don't follow here, but I'm going to let that be, as random_bitstring
isn't interesting (except regarding the bug).
> I've noticed CRIS doesn't support scheduling at all, so delay slot filling
> (where's that done?) relies purely on our "random" scheduling we do at
> RTL expansion time (via TER) and during GIMPLE optimization?
Delay-slot-filling is unrelated to scheduling. It's in reorg.cc with its own
horribly outdated dataflow analysis in resource.cc (but used to be shared).
> That said, I think sinking now works as expected.
In random_bitstring I agree, but there's fallout in main.
> I do want to play with
> sinking to the start of the else {, but without doing any lifetime analysis
> I fear that's going to be worse in the average as the current location
> at least ensures we're close to the first use of the DEF we sink.
Thank you in advance and for the look this far! I haven't looked closer at
what happens with later passes in main, but looking at the generated assembly
code, the "sinking" of a division has the eventual effect of increasing
register pressure; see the previously attached dumps.
[Bug target/115118] [15 Regression] 5-13% slowdown of 470.lbm on zen4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115118 --- Comment #2 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #1) > Not-so-wild guess: r15-518, for similar-but-unrelated reasons to PR115144. Ah, dyscalculia strikes again. :) Please ignore.
[Bug target/115118] [15 Regression] 5-13% slowdown of 470.lbm on zen4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115118 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson --- Not-so-wild guess: r15-518, for similar-but-unrelated reasons to PR115144.
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 --- Comment #5 from Hans-Peter Nilsson --- Created attachment 58241 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58241&action=edit tree-dump file@518 w. ivopts As above @518 without -fno-ivopts
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 --- Comment #4 from Hans-Peter Nilsson --- Created attachment 58240 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58240&action=edit tree-dump file@517 w. ivopts As above @517, but no -fno-ivopts
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 --- Comment #3 from Hans-Peter Nilsson --- Created attachment 58239 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58239&action=edit tree-dump file @518 arith-rand.c @r15-518 compiled with -fno-ivopts -fdump-tree-optimized -march=v10 -O2
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 --- Comment #2 from Hans-Peter Nilsson --- Created attachment 58238 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58238&action=edit tree-dump file@517 arith-rand.c @r15-517 compiled with -fno-ivopts -fdump-tree-optimized -march=v10 -O2
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144
--- Comment #1 from Hans-Peter Nilsson ---
I also ran a round compiled with -fno-ivopts -fno-delayed-branch: the latter
because it's somewhat non-linear in finding delay-slot-filling opportunities
(lack of "luck" causing improvements to negate) and the former because it was
mentioned in the commit as similarly messing things up.
That "fixed" all of the performance drop for random_bitstring, but still left
an almost-as-large performance drop in main in
gcc.c-torture/execute/arith-rand-ll.c. IOW, the net performance drop is 1.25%:
r15-0517:
Basic clock cycles, total @: 13662157
r15-0518:
Basic clock cycles, total @: 13832953
The focus of this bug was the on subset of arith-rand-ll.c that is in
gcc.target/cris/pr93372-47.c (i.e. no main function), so if I keep that, the
gist of this PR should instead shift to something like 50% "r15-518 doesn't
play nice with ivopts" but I guess that's already known.
So if anyone's interested in improving r15-518 (but not in ivopts interaction),
I'd suggest that'd be in what happens in the main function for
gcc.c-torture/execute/arith-rand-ll.c.
Having said that, I did compile gcc.target/cris/pr93372-47.c adding -fno-ivopts
-fdump-tree-optimized and it shows that the tot_bits computation ("tot_bits_13
= tot_bits_8 + n_bits_12;") is moved later, right before it's used in a
conditional, which makes me think the delay-branch-scheduling has less
"material" to fill the first delays-slots.
I also compiled gcc.c-torture/execute/arith-rand-ll.c with -fno-ivopts
-fdump-tree-optimized (plus the usual -O2 -march=v10) and will attach the
tree-dump files. They show what the pr93372-47.c change *and* that several
division operations are moved forward. This separates them from the modulus
opterations on the same values, so I guess targets where computing these values
together is a win (not CRIS), we'll see a performance loss.
[Bug tree-optimization/115144] New: [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 Bug ID: 115144 Summary: [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: cris-elf ...and also, regresses gcc.target/cris/pr93372-47.c. The actual purpose of that test-case is as a regression-test for a fixed bug with delay-slot-filling, but it also serves as a guard against code quality regression. Following up as per the comment in pr93372-47.c about what to investigate in case it regressed, I see a quite large regression: The commit r15-518-g99b1daae18c095 "tree-optimization/114589 - remove profile based sink heuristics" caused an almost 2% performance regression for certain codes, as measured by simulator output by executing gcc.c-torture/execute/arith-rand-ll.c compiled for cris-elf with -O2 -march=v10. r15-0517: Basic clock cycles, total @: 13025734 r15-0518: Basic clock cycles, total @: 13279004 Also, I inspected simulator output and the bulk is indeed in random_bitstring (i.e. not in div and mod library functions). Perhaps you say that ivopts matters here? The same, adding -fno-ivopts, r15-0517: Basic clock cycles, total @: 13008338 r15-0518: Basic clock cycles, total @: 13330520 ...so the regression is then even larger; almost 2.5%. It may be argued that arith-rand-ll.c is not a reliable performance test, so I also ran r15-0517 and r15-0518 by coremark, which paints a different picture: r15-0517: Basic clock cycles, total @: 5022704 r15-0518: Basic clock cycles, total @: 5021785 So there, it's a win in performance, if only small (~0.02%). Same, with -fno-ivopts: r15-0517: Basic clock cycles, total @: 5641650 r15-0518: Basic clock cycles, total @: 5640721 Still a win in performance, only smaller (still ~0.02%). Judging from coremark, there's no general conclusion regarding performance of r15-518, but I know from other performance investigations that "double register"-heavy code such as arith-rand-ll.c for CRIS has different characteristics than other test-code, here coremark. Maybe something can be done to improve on r15-518 for this type of code or maybe it exposed problems for other ports, so I'm not going to immediately myself close this as WONTFIX. I'll also be using this PR as an anchor when dealing with (likely xfailing) the regression for gcc.target/cris/pr93372-47.c.
[Bug middle-end/115110] [15 regression] several failures after r15-512-g9b7cad5884f21c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115110 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #10 from Hans-Peter Nilsson --- *** Bug 115141 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/115141] [15 Regression] g++.dg/tree-ssa/pr83215.C and gcc.dg/tree-ssa/ssa-lim-15.c since r15-512-g9b7cad5884f21c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115141 Hans-Peter Nilsson changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Hans-Peter Nilsson --- *** This bug has been marked as a duplicate of bug 115110 ***
[Bug tree-optimization/115141] [15 Regression] g++.dg/tree-ssa/pr83215.C and gcc.dg/tree-ssa/ssa-lim-15.c since r15-512-g9b7cad5884f21c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115141 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans-Peter Nilsson --- (In reply to Sam James from comment #1)> Dupe of PR115110? Yep, thanks. It was fixed already, and by default searches don't include fixed issues, that's why my pre-pr-search didn't find it.
[Bug tree-optimization/115141] New: [15 Regression] g++.dg/tree-ssa/pr83215.C and gcc.dg/tree-ssa/ssa-lim-15.c since r15-512-g9b7cad5884f21c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115141 Bug ID: 115141 Summary: [15 Regression] g++.dg/tree-ssa/pr83215.C and gcc.dg/tree-ssa/ssa-lim-15.c since r15-512-g9b7cad5884f21c Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- Since commit r15-512-g9b7cad5884f21c, g++.dg/tree-ssa/pr83215.C and gcc.dg/tree-ssa/ssa-lim-15.c regresses for what appears to be all targets, including cris-elf. See e.g. powerpc64-unknown-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815379.html arm-unknown-eabi: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815354.html x86_64-pc-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815358.html Compare to recent results posted before this commit: powerpc64-unknown-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815200.html arm-unknown-eabi: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815264.html x86_64-pc-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815205.html
[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__>(&foo));
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.
