[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #61 from Segher Boessenkool --- (In reply to Sarah Julia Kriesch from comment #60) > I have to agree with Richard. This problem has been serious for a long time > but has been ignored by IBM based on distribution choices. What? What does IBM have to do with this? Yes, they are my employer, but what I decide is best for combine to do is not influenced by them *at all* (except some times they want me to spend time doing paid work, distracting me from things that really matter, like combine!) > Anyway, we want to live within the open source community without any Linux > distribution priorities (especially in upstream projects like here). No idea what that means either. > Segher, can you specify the failed test cases? Then, it should be possible > to reproduce and improve that all. In such a collaborative way, we can also > achieve a solution. What failed test cases? You completely lost me. We used to do the wrong thing in combine. Now that my fix was reverted, we still do. This should be undone soonish, so that I can commit an actual UNCSE implementation, which fixes all "regressions" (quotes, because they are not!) caused by my previous patch, and does a lot more too. It also will allow us to remove a bunch of other code from combine, speeding up things a lot more (things that keep a copy of a set if the dest is used more than once). There has been talk of doing an UNCSE for over twenty years now, so annoying me enough to get this done is a good result of this whole thing :-)
[Bug c++/114928] #pragma packed(push, 1) should give the same warning as __attribute__((packed))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114928 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=60972 --- Comment #1 from Eric Gallager --- There are a number of other bugs open regarding inconsistencies between #pragma pack and __attribute__((packed)); see for instance bug 60972 and related bugs (not sure if this is a dup or even fully related, but it's at least worth putting under "See Also"...)
[no subject]
สัมหรับเจ้าของกิจการ ที่มี Project เพื่อต่อยอดเพิ่มกำไรให้ธุรกิจ แต่ยังหาทุนทรัพย์ไม่ทัน (เราช่วยคุณได้) ✔️สัมหรับเจ้าของธุรกิจที่มีการจดทะเบียน ใบประกอบกิจการ ✔️เรายินดีอนุมัติเงินด่วน 30,000-5,000,000 บ. ✔️ไม่เช็คเครดิต บูโรเอกสารไม่ยุ่งยาก ไม่ต้องมีบุคคลค้ำประกัน ✔️อัตราดอกเบี้ยเริ่มต้นที่ 1.5% ตัดต้นลดดอกเบี้ยทันที ✔️อนุมัติไวภายใน 1 วัน (หลังส่งเอกสารครบถ้วน) ถ้าท่านสนใจบริการของเรา โทรด่วนหาเรา ☎️ 083-4968834 คุณเอก 📲 LINE ID : esc.credit (ให้เราเป็นส่วนหนึ่งในครอบครับท่านนะครับ)
[Bug libbacktrace/114941] libbacktrace build is broken for FDPIC uclibc targets by r14-5173-g2b64e4a54042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114941 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #2 from Ian Lance Taylor --- What is the correct way to get the address at which the shared library was loaded when using FDPIC?
[Bug modula2/114929] for loop fails to iterate down to zero if a cardinal type (unsigned type) is used with a step of -1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114929 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Gaius Mulley --- Closing now the patch has been applied and back ported.
[Bug target/114942] [14/15 Regression] ICE on valid code at -O1 with "-fno-tree-sra -fno-guess-branch-probability": in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-05-03 Target Milestone|--- |14.0 Summary|ICE on valid code at -O1|[14/15 Regression] ICE on |with "-fno-tree-sra |valid code at -O1 with |-fno-guess-branch-probabili |"-fno-tree-sra |ty": in |-fno-guess-branch-probabili |extract_constrain_insn, at |ty": in |recog.cc:2713 |extract_constrain_insn, at ||recog.cc:2713 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Version|unknown |15.0 --- Comment #1 from Andrew Pinski --- Confirmed. Looks like it was introduced with r14-5456-gb42a09b258c3ed .
[Bug rtl-optimization/114942] New: ICE on valid code at -O1 with "-fno-tree-sra -fno-guess-branch-probability": in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
Bug ID: 114942
Summary: ICE on valid code at -O1 with "-fno-tree-sra
-fno-guess-branch-probability": in
extract_constrain_insn, at recog.cc:2713
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it doesn't reproduce with 13.2 and
earlier.
Compiler Explorer: https://godbolt.org/z/av9hr4933
[648] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240503 (experimental) (GCC)
[649] %
[649] % gcctk -O1 -c -fno-tree-sra -fno-guess-branch-probability small.c
small.c: In function ‘main’:
small.c:21:1: error: insn does not satisfy its constraints:
21 | }
| ^
(insn 39 56 57 6 (parallel [
(set (strict_low_part (reg:QI 2 cx [orig:108 f ] [108]))
(ior:QI (subreg:QI (zero_extract:HI (reg/v:HI 2 cx [orig:108 f
] [108])
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)
(reg:QI 0 ax [orig:121 _7 ] [121])))
(clobber (reg:CC 17 flags))
]) "small.c":19:7 626 {*iorqi_exthi_1_slp}
(nil))
during RTL pass: reload
small.c:21:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2713
0x83dea6 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-trunk/gcc/rtl-error.cc:108
0x83ded2 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-trunk/gcc/rtl-error.cc:118
0x83c10c extract_constrain_insn(rtx_insn*)
../../gcc-trunk/gcc/recog.cc:2713
0xf55a67 check_rtl
../../gcc-trunk/gcc/lra.cc:2189
0xf5aef1 lra(_IO_FILE*, int)
../../gcc-trunk/gcc/lra.cc:2610
0xf0b1ff do_reload
../../gcc-trunk/gcc/ira.cc:5973
0xf0b1ff execute
../../gcc-trunk/gcc/ira.cc:6161
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.
[650] %
[650] % cat small.c
extern void a();
struct b {
char c;
char d;
} e;
int main() {
struct b f = e;
char i = 0;
L1:
if (!f.c)
goto L2;
if (e.c)
a();
else
return 0;
f.d = 0;
i = 1 % ((1 & f.c) - 2);
L2:
f.c = ~(i & ~f.d);
goto L1;
}
[Bug middle-end/23872] .original dump weirdness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872 --- Comment #12 from Andrew Pinski --- Note only the `;` issue has been resolved, the other 2 issues I have to rework.
[Bug middle-end/23872] .original dump weirdness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872 --- Comment #11 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:04f24e44fb14a22516444f70503719f3fda15d6c commit r15-139-g04f24e44fb14a22516444f70503719f3fda15d6c Author: Andrew Pinski Date: Tue Apr 16 17:43:36 2024 -0700 Fix printing COMPOUND_EXPR in .original [PR23872] Starting with the merge of the openmp branch into the trunk (r0-73077-g953ff28998b59b), COMPOUND_EXPR started to be printed as `expr; , expr` which is wrong. This was due to the wrong conversion of dumping_stmts into `!(flags & TDF_SLIM)`. That is wrong as we are not dumping stmts at this point (`!(flags & TDF_SLIM)` was always true for this case as TDF_SLIM case was handled before hand). So switch it to be always false. Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: PR middle-end/23872 * tree-pretty-print.cc (dump_generic_node ): Fix calls to dump_generic_node and also remove unreachable code that is testing `flags & TDF_SLIM`. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/atomic-21.f90: Update testcase for the removal of `;`. Signed-off-by: Andrew Pinski
[Bug modula2/114929] for loop fails to iterate down to zero if a cardinal type (unsigned type) is used with a step of -1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114929 --- Comment #6 from GCC Commits --- The releases/gcc-14 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:d811080341adf9d805e3f79a8fd9be2e13bd9848 commit r14-10166-gd811080341adf9d805e3f79a8fd9be2e13bd9848 Author: Gaius Mulley Date: Fri May 3 22:58:11 2024 +0100 [PATCH] PR modula2/114929 for loop fails to iterate down to zero There is a bug in the for loop control code which is exposed when an unsigned type is used in the iterator variable. See gm2/pim/run/pass/testforloopzero[234].mod. The bug is in the calculation of the last iterator value. The bug fix is to avoid using negative expressions when calculating the last iterator value with a negative step value. This patch detects if e1, e2, step value are all constant, in which case the ztype is used internally and there is no overflow. If the last iterator value is held in a variable then it uses a different method to calculate the last iterator depending upon the sign of the step value. gcc/m2/ChangeLog: PR modula2/114929 * gm2-compiler/M2Quads.mod (ForLoopLastIteratorVariable): New procedure. (ForLoopLastIteratorConstant): Ditto. (ForLoopLastIterator): Ditto. (BuildForToByDo): Remove LastIterator calculation and call ForLoopLastIterator instead. (FinalValue): Replace with ... (LastIterator): ... this. gcc/testsuite/ChangeLog: PR modula2/114929 * gm2/pim/run/pass/testforloopzero.mod: New test. * gm2/pim/run/pass/testforloopzero2.mod: New test. * gm2/pim/run/pass/testforloopzero3.mod: New test. * gm2/pim/run/pass/testforloopzero4.mod: New test. (cherry picked from commit a561dc0f6c7085e102fe9e9b6abd7f2138512576) Signed-off-by: Gaius Mulley
[Bug middle-end/114855] ICE: Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 --- Comment #7 from Andrew Macleod --- LOoks like the primary culprits now are: dominator optimization : 666.73 ( 7%) 0.77 ( 2%) 671.76 ( 7%) 170M ( 4%) backwards jump threading :7848.77 ( 85%) 21.04 ( 65%)7920.05 ( 85%) 1332M ( 29%) TOTAL :9250.99 32.58 9341.40 4619M
[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114860 --- Comment #5 from Andrew Pinski --- (In reply to prathamesh3492 from comment #4) > To check for any > possible icache misses I used L1I_CACHE_REFILL counter, and turns out that > there are 64% more L1 icache misses for above adrp instruction with > a2f4be3dae0 compared to 82d6d385f97, which may (partially) explain the > performance difference ? Although perf stat shows there are around 7% more > L1 icache misses for whole program run with 82d6d385f97 compared to > a2f4be3dae0. This makes it sound like there is some code alignment issue going on or a branch misprediction issue going on. bad alignment: 4aeae4 good alignment 4aec44 The good alignment case is at the (almost) start at an icache line while the bad alignment case is in the middle. (I am assuming 64byte cache lines which I think is correct) Maybe look at mispredicted branches too. It might be the branch leading to this code is being mispredicted more due to the address of the branch is now interfeeing with another branch. It might just have been bad luck that caused this regression in both cases really; alignment differences and/or address differences can be bad luck.
[Bug c/114938] Function argument column info seems to have been lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114938
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |c
Summary|Basic blocks in generated |Function argument column
|CFG referencing the |info seems to have been
|incorrect source token |lost
|column |
--- Comment #2 from Andrew Pinski ---
Take the reduced testcase we get using the C front-end:
```
int proc_dostring (struct ctl_table * table, int write, void * buffer, int *
lenp, int * ppos)
[/app/example.cpp:13:1] {
int D.2793;
[/app/example.cpp:14:5] if (write != 0) goto ; else goto ;
:
[/app/example.cpp:15:3] proc_first_pos_non_zero_ignore (ppos, table);
:
[/app/example.cpp:17:9] _1 = [/app/example.cpp:17:9] table->maxlen;
[/app/example.cpp:17:9] _2 = [/app/example.cpp:17:9] table->data;
[/app/example.cpp:17:9] D.2793 = _proc_do_string (_2, _1, write, buffer,
lenp, ppos);
[/app/example.cpp:17:9] return D.2793;
}
```
The column 9 is the start of the call. But really the first statement should
have a column of 24.
Note with the C++ FE we get:
[/app/example.cpp:17:24] _1 = [/app/example.cpp:17:24] table->maxlen;
[/app/example.cpp:17:24] _2 = [/app/example.cpp:17:24] table->data;
[/app/example.cpp:17:24] D.2822 = _proc_do_string (_2, _1, write, buffer,
lenp, ppos);
[/app/example.cpp:17:24 discrim 1] D.2820 = D.2822;
the :24 is the column after `(`.
But _2 statement really should be the column after the first `,`.
I remember seeing this before ...
[Bug c++/114933] [15 Regression] mcfgthread-1.6.1 typecheck failure: error: explicit specializations are not permitted here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933 --- Comment #9 from Sergei Trofimovich --- The mcfgthread change fixed the full gcc build for me. Thank you!
[Bug middle-end/111111] omnetpp: ICEs with dump flags, PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 Christoph Müllner changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from Christoph Müllner --- This can't be reproduced anymore (retested with master and releases/gcc-14).
[Bug middle-end/114938] Basic blocks in generated CFG referencing the incorrect source token column
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114938 --- Comment #1 from Andrew Pinski --- Created attachment 58102 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58102&action=edit reduced
[Bug testsuite/114939] [15 regression] c-c++-common/torture/strub-run3.c fails after r15-125-g7117e1f6bf6de2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114939 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||testsuite-fail Component|other |testsuite Ever confirmed|0 |1 Target Milestone|--- |15.0 Last reconfirmed||2024-05-03 --- Comment #2 from Andrew Pinski --- So confirmed and a testsuite issue ...
[Bug libbacktrace/114941] libbacktrace build is broken for FDPIC uclibc targets by r14-5173-g2b64e4a54042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114941 --- Comment #1 from Andrew Pinski --- So a patch like what was done in r0-56719-g34208acf14fa02 needs to be done to libbacktrace . Basically this has always been broken.
[Bug libbacktrace/114941] New: libbacktrace build is broken for FDPIC uclibc targets by gcc-14-5173-g2b64e4a54042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114941
Bug ID: 114941
Summary: libbacktrace build is broken for FDPIC uclibc targets
by gcc-14-5173-g2b64e4a54042
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: jcmvbkbc at gcc dot gnu.org
CC: ian at gcc dot gnu.org
Target Milestone: ---
A fix for the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315 turned on the
use of the dl_iterate_phdr interface in the libbacktrace, but since the type of
the dl_phdr_info::dlpi_addr on FDPIC targets using uclibc is not compatible
with uintptr_t the libstdc++-v3 build breaks for these targets with the
following message:
elf.c:7372:62: error: incompatible type for argument 6 of ‘elf_add’
7372 | if (elf_add (pd->state, filename, descriptor, NULL, 0,
info->dlpi_addr,
|
^~~
| |
| struct
elf32_fdpic_loadaddr
elf.c:6504:20: note: expected ‘uintptr_t’ {aka ‘unsigned int’} but argument is
of type ‘struct elf32_fdpic_loadaddr’
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 --- Comment #4 from Timothy Liu Xuefeng --- (In reply to Jonathan Wakely from comment #2) > It's not optional, it's a required feature in C++14 and later. Failing to > provide it is non-conforming, although GCC can be requested to be > non-conforming the same way with -fno-sized-deallocation. Using that, the > same error happens with GCC. > > We should either disable __cpp_lib_generator when __cpp_sized_deallocation > is not defined, or change to not depend on it unconditionally. Yeah, I agree. Since -fsized-deallocation is not the default behavior of clang++, reporting errors in seems strange.
[Bug c++/114935] [14/15 regression] Miscompilation of initializer_list in presence of exceptions since r14-1705-g2764335bd336f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114935 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jason Merrill --- Fixed.
[Bug c++/114935] [14/15 regression] Miscompilation of initializer_list in presence of exceptions since r14-1705-g2764335bd336f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114935 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:3b4d6b6ecd79df790bf0938dab1f51094f94d777 commit r14-10165-g3b4d6b6ecd79df790bf0938dab1f51094f94d777 Author: Jason Merrill Date: Fri May 3 09:52:46 2024 -0400 c++: initializer_list and EH [PR114935] When we initialize an array of a type with a non-trivial destructor, such as the backing array for the initializer_list, we have a cleanup to destroy any constructed elements if a later constructor throws. When the array being created is a variable, the end of that EH region naturally coincides with the beginning of the EH region for the cleanup for the variable as a whole. But if the array is a temporary, or a subobject of one, the array cleanup region lasts for the rest of the full-expression, along with the normal cleanup for the TARGET_EXPR. As a result, when tata throws we clean it up twice. Before r14-1705 we avoided this by disabling the array cleanup in split_nonconstant_init, but after that we don't go through split_nonconstant_init, so let's handle it in cp_genericize_target_expr. PR c++/114935 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_genericize_init): Add flags parm. (cp_genericize_init_expr): Pass nullptr. (cp_genericize_target_expr): Handle cleanup flags. * typeck2.cc (build_disable_temp_cleanup): Factor out of... (split_nonconstant_init): ...here. * cp-tree.h (build_disable_temp_cleanup): Declare. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-eh1.C: New test. (cherry picked from commit 8f3afb83c879f1bfa722a963a07c06aaf174ef72)
[Bug c++/114935] [14/15 regression] Miscompilation of initializer_list in presence of exceptions since r14-1705-g2764335bd336f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114935 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8f3afb83c879f1bfa722a963a07c06aaf174ef72 commit r15-138-g8f3afb83c879f1bfa722a963a07c06aaf174ef72 Author: Jason Merrill Date: Fri May 3 09:52:46 2024 -0400 c++: initializer_list and EH [PR114935] When we initialize an array of a type with a non-trivial destructor, such as the backing array for the initializer_list, we have a cleanup to destroy any constructed elements if a later constructor throws. When the array being created is a variable, the end of that EH region naturally coincides with the beginning of the EH region for the cleanup for the variable as a whole. But if the array is a temporary, or a subobject of one, the array cleanup region lasts for the rest of the full-expression, along with the normal cleanup for the TARGET_EXPR. As a result, when tata throws we clean it up twice. Before r14-1705 we avoided this by disabling the array cleanup in split_nonconstant_init, but after that we don't go through split_nonconstant_init, so let's handle it in cp_genericize_target_expr. PR c++/114935 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_genericize_init): Add flags parm. (cp_genericize_init_expr): Pass nullptr. (cp_genericize_target_expr): Handle cleanup flags. * typeck2.cc (build_disable_temp_cleanup): Factor out of... (split_nonconstant_init): ...here. * cp-tree.h (build_disable_temp_cleanup): Declare. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-eh1.C: New test.
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 --- Comment #3 from Jonathan Wakely --- P.S. what's optional is whether the compiler chooses to use that overload or not. But its presence is required for conformance.
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-03 CC||arsen at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- It's not optional, it's a required feature in C++14 and later. Failing to provide it is non-conforming, although GCC can be requested to be non-conforming the same way with -fno-sized-deallocation. Using that, the same error happens with GCC. We should either disable __cpp_lib_generator when __cpp_sized_deallocation is not defined, or change to not depend on it unconditionally.
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 --- Comment #1 from Timothy Liu Xuefeng --- It seems that passing -fsized-deallocation to clang++ can resolve this problem. But it seems that it's not the default behavior.
[Bug modula2/114929] for loop fails to iterate down to zero if a cardinal type (unsigned type) is used with a step of -1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114929 --- Comment #5 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:c943d7b5c40f447b12431df9ad27a47dad95026d commit r15-137-gc943d7b5c40f447b12431df9ad27a47dad95026d Author: Gaius Mulley Date: Fri May 3 20:48:01 2024 +0100 PR modula2/114929 extra for loop iteration count regression tests This patch introduces three more for loop tests checking the iteration count using the CHAR and enumeration data types. gcc/testsuite/ChangeLog: PR modula2/114929 * gm2/pim/run/pass/testforloopchar.mod: New test. * gm2/pim/run/pass/testforloopchar2.mod: New test. * gm2/pim/run/pass/testforloopenum.mod: New test. Signed-off-by: Gaius Mulley
[Bug libstdc++/77704] Data race on std::ctype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
--- Comment #10 from Jonathan Wakely ---
(In reply to Boris Kolpackov from comment #5)
> For anyone interested, here is the workaround we came up with:
>
> // A data race happens in the libstdc++ (as of GCC 7.2) implementation of the
> // ctype::narrow() function (bug #77704). The issue is easily
> triggered
> // by the testscript runner that indirectly (via regex) uses ctype
> facet
> // of the global locale (and can potentially be triggered by other locale-
> // aware code). We work around this by pre-initializing the global locale
> // facet internal cache.
> //
> #ifdef _GLIBCXX_
> {
> const ctype& ct (use_facet> (locale ()));
>
> for (size_t i (0); i != 256; ++i)
> ct.narrow (static_cast (i), '\0');
> }
> #endif
It would be better to call ct.narrow(0, 0, 0, 0) as that will populate the
_M_narrow array and also set the _M_narrow_ok flag. Otherwise you can still get
later races on the flag.
[Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
Bug ID: 114940
Summary: std::generator relies on an optional overload of
operator delete
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: liuxf19 at 163 dot com
Target Milestone: ---
The bug report #114891 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
discussed the impact of is_pointer_interconvertible_base_of_v on using
std::generator with clang++ and libstdc++. There's another issue when
std::generator in libstdc++ is used by other compilers such as clang++.
In the header , an overload of operator delete:
void operator delete ( void* ptr, std::size_t sz ) noexcept;
However, this is an OPTIONAL feature whose feature test macro is
__cpp_sized_deallocation macro. Some compilers especially clang++, even the
newest clang trunk (which is avaiable at https://godbolt.org, and the version
is 19.0.0) didn't implement this macro. For example, the code below:
#include
int main() {
#ifndef __cpp_sized_deallocation
static_assert(false, "no __cpp_sized_deallocation");
#endif
}
compiled with: clang++ -std=c++23 -stdlib=libstdc++
will cause the following errors:
:5:19: error: static assertion failed: no __cpp_sized_deallocation
5 | static_assert(false, "no __cpp_sized_deallocation");
| ^
1 error generated.
ASM generation compiler returned: 1
:5:19: error: static assertion failed: no __cpp_sized_deallocation
5 | static_assert(false, "no __cpp_sized_deallocation");
| ^
1 error generated.
See https://gcc.godbolt.org/z/MocWxMKz6 for details.
And thus there's no this overload with clang++.
But the std::generator in libstdc++ relies on this overload, which also causes
clang++ cannot use std::generator in libstdc++ (even after clang++ 19 provided
is_pointer_interconvertible_base_of discussed in #114891).
The following code:
#include
#include
std::generator iota(int n) {
for (int i = 0; i < n; ++i) {
co_yield i;
}
}
int main() {
for (auto i : iota(10)) {
}
return 0;
}
compiled with: clang++ -std=c++23 -stdlib=libstdc++
And the compilation errors:
In file included from main.cpp:16:
/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/generator:606:6:
error: no matching function for call to 'operator delete'
606 | ::operator delete(__ptr, _M_alloc_size(__sz));
| ^
See https://gcc.godbolt.org/z/xjMGaq36a for details.
Note that there's no restrictions that std::generator must depends on this
overload of operator delete in ISO C++. This may cause clang++ or other
compilers cannot use std::generator in libstdc++.
[Bug other/114939] [15 regression] c-c++-common/torture/strub-run3.c fails after r15-125-g7117e1f6bf6de2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114939 Jakub Jelinek changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- To me this looks like that test is depending on the invalid assumption that alloca in always_inline calls should behave like it behaved before (which was incorrect).
[Bug other/114939] New: [15 regression] c-c++-common/torture/strub-run3.c fails after r15-125-g7117e1f6bf6de2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114939
Bug ID: 114939
Summary: [15 regression] c-c++-common/torture/strub-run3.c
fails after r15-125-g7117e1f6bf6de2
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:7117e1f6bf6de25c1ff26c4d7abcc79b407ca221, r15-125-g7117e1f6bf6de2
I am seeing this on powerpc64 BE systems.
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
dg-torture.exp=c-c++-common/torture/strub-run3.c"
FAIL: c-c++-common/torture/strub-run3.c -O0 execution test
FAIL: c-c++-common/torture/strub-run3.c -O0 execution test
(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-test/strub-run3.exe
...
Program received signal SIGABRT, Aborted.
0x0fd73360 in ?? () from /lib32/libc.so.6
(gdb) where
#0 0x0fd73360 in ?? () from /lib32/libc.so.6
#1 0x0fd151e4 in raise () from /lib32/libc.so.6
#2 0x0fcfa128 in abort () from /lib32/libc.so.6
#3 0x16e0 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/torture/strub-run3.c:75
commit 7117e1f6bf6de25c1ff26c4d7abcc79b407ca221 (HEAD)
Author: Jakub Jelinek
Date: Fri May 3 09:44:30 2024 +0200
tree-inline: Add __builtin_stack_{save,restore} pair about inline calls
with calls to alloca [PR113596]
[Bug c++/114934] Error message for expected unqualified-id could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114934 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-05-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug libstdc++/77704] Data race on std::ctype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #9 from Jonathan Wakely ---
There's a related data race in std::basic_ios::fill() because of these mutable
members:
mutable char_type _M_fill;
mutable bool _M_fill_init;
char_type
fill() const
{
if (!_M_fill_init)
{
_M_fill = this->widen(' ');
_M_fill_init = true;
}
return _M_fill;
}
That one's easier to fix.
[Bug c++/114935] [14/15 regression] Miscompilation of initializer_list in presence of exceptions since r14-1705-g2764335bd336f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114935
--- Comment #1 from Jason Merrill ---
Without :
#include
int as;
struct A {
A(const char *) { ++as; }
A(const A&) { ++as; }
~A() { --as; }
};
void __attribute__((noipa))
tata(std::initializer_list init)
{
throw 1;
}
int
main()
{
try { tata({ "foo","bar" }); }
catch (...) { }
if (as != 0) __builtin_abort ();
}
The problem is with the array EH cleanup handling: when we initialize an array
of a type with a non-trivial destructor, such as the backing array for the
initializer_list, we have a cleanup to destroy any constructed elements if a
later constructor throws. But in this case the call to tata is still in that
region. Without the r14-1705 change, we deal with that by disabling the array
cleanup in split_nonconstant_init, but with the change we don't go through
split_nonconstant_init and so we miss disabling the cleanup.
[Bug rtl-optimization/114938] New: Basic blocks in generated CFG referencing the incorrect source token column
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114938
Bug ID: 114938
Summary: Basic blocks in generated CFG referencing the
incorrect source token column
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: 0xd at tutamail dot com
Target Milestone: ---
Created attachment 58101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58101&action=edit
reprocessed intermediate, original source, and CFG output with line number,
basic blocks
I'm currently working with gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04),
the official package for the repo using the following options to dump the
intermediate and cfg files:
-save-temps=obj -Wa,-adhn -g -fdump-tree-cfg-blocks-lineno
I've noticed though the line numbers are correct in the CFG, the column numbers
don't seem to correspond to the referenced location in the original C file. As
an example:
CFG:
;; basic block 2, loop depth 0
...
[kernel/sysctl.c:372:5] if (write != 0)
...
;; basic block 3, loop depth 0
...
[kernel/sysctl.c:373:3] proc_first_pos_non_zero_ignore (ppos, table);
...
;; basic block 4, loop depth 0
[kernel/sysctl.c:375:9] _1 = [kernel/sysctl.c:375:9] table->maxlen;
[kernel/sysctl.c:375:30] _2 = [kernel/sysctl.c:375:30] table->data;
[kernel/sysctl.c:375:9] D.100751 = _proc_do_string (_2, _1, write, buffer,
lenp, ppos);
[kernel/sysctl.c:375:9] return D.100751;
C source:
int proc_dostring(struct ctl_table *table, int write,
void *buffer, size_t *lenp, loff_t *ppos)
{
372:if (write)
--->^ "if" token starts at column 5, this is CORRECT in the CFG
373:proc_first_pos_non_zero_ignore(ppos, table);
--->^ starts at column 9, this is INCORRECT in CFG (3)
375:return _proc_do_string(table->data, table->maxlen, write, buffer, lenp,
ppos);
--->^ this starts at column 41 (CFG, 9)
^this starts at column 28 (CFG, 30)
}
// column 9 is referenced 3 times for line 375, but this is just corresponds to
// the second "r" in "return" in the original source.
// the dereference assignment, function call, and return.
I'm confused where these column numbers in the output CFG are coming from. For
the moment I'm only referencing the line number but it would much more
beneficial to get the exact column of the original token, especially when
dealing with compound/conditional statements which will branch off to multiple
basic blocks.
Also of note, I haven't tested any of the newer gcc versions since the source
I'm working with won't compile with newer features added in 12+.
[Bug tree-optimization/114937] [11 regression] -ftree-vrp optimizes out range check before conditional increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114937
--- Comment #3 from Mital Ashok ---
My real code looks more like:
void sat_inc(int& y) {
if (y < __INT_MAX__)
++y;
}
template
void f(int& x, F&&... functions) {
int copy = x;
(functions(copy), ...);
if (copy > x)
x = copy;
}
void g(int& x) {
f(x, sat_inc);
}
... Where `g(x)` became `++x` unconditionally
[Bug gcov-profile/114715] Gcov allocates branches to wrong row for nested switches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114715 Richard Biener changed: What|Removed |Added Known to work||13.2.1 --- Comment #6 from Richard Biener --- Fixed for GCC 13+ sofar. Probably never worked correctly?
[Bug middle-end/114733] [13 Regression] Miscompile with -march=rv64gcv -O3 on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114733 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||13.2.1 Known to fail||13.2.0 Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/114485] [13 Regression] Wrong code with -O3 -march=rv64gcv on riscv or `-O3 -march=armv9-a` for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485 Richard Biener changed: What|Removed |Added Known to fail|13.1.0 |13.2.0 Resolution|--- |FIXED Known to work||13.2.1 Status|ASSIGNED|RESOLVED --- Comment #15 from Richard Biener --- Fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 114485, which changed state. Bug 114485 Summary: [13 Regression] Wrong code with -O3 -march=rv64gcv on riscv or `-O3 -march=armv9-a` for aarch64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/114749] [13 Regression] RISC-V rv64gcv ICE: in vectorizable_load, at tree-vect-stmts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed as far as I am concerned. If you can reproduce on older branches please re-open, the backport is of course trivial.
[Bug gcov-profile/114715] Gcov allocates branches to wrong row for nested switches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114715 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:5a3cc62dbb45185dd1ca32caec80d57a320ec5a0 commit r13-8682-g5a3cc62dbb45185dd1ca32caec80d57a320ec5a0 Author: Richard Biener Date: Mon Apr 15 11:09:17 2024 +0200 gcov-profile/114715 - missing coverage for switch The following avoids missing coverage for the line of a switch statement which happens when gimplification emits a BIND_EXPR wrapping the switch as that prevents us from setting locations on the containing statements via annotate_all_with_location. Instead set the location of the GIMPLE switch directly. PR gcov-profile/114715 * gimplify.cc (gimplify_switch_expr): Set the location of the GIMPLE switch. * gcc.misc-tests/gcov-24.c: New testcase. (cherry picked from commit 9d573f71e80e9f6f4aac912fc8fc128aa2697e3a)
[Bug tree-optimization/114736] [13 Regression] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114736 Richard Biener changed: What|Removed |Added Known to fail|13.2.1 |13.2.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||13.2.1 Priority|P3 |P2 --- Comment #13 from Richard Biener --- Fixed then.
[Bug tree-optimization/114749] [13 Regression] RISC-V rv64gcv ICE: in vectorizable_load, at tree-vect-stmts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:704b15e277a8792ac4cd6008ee08bec4b047a3e6 commit r13-8684-g704b15e277a8792ac4cd6008ee08bec4b047a3e6 Author: Richard Biener Date: Wed Apr 17 10:40:04 2024 +0200 tree-optimization/114749 - reset partial vector decision for no-SLP retry The following makes sure to reset LOOP_VINFO_USING_PARTIAL_VECTORS_P to its default of false when re-trying without SLP as otherwise analysis may run into bogus asserts. PR tree-optimization/114749 * tree-vect-loop.cc (vect_analyze_loop_2): Reset LOOP_VINFO_USING_PARTIAL_VECTORS_P when re-trying without SLP. (cherry picked from commit bf2b5231312e1cea45732cb8df6ffa2b2c9115b6)
[Bug middle-end/114733] [13 Regression] Miscompile with -march=rv64gcv -O3 on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114733 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:b3f9f10e03c570074a517dcfe9df8d3eeddd6aca commit r13-8680-gb3f9f10e03c570074a517dcfe9df8d3eeddd6aca Author: Richard Biener Date: Tue Apr 16 10:46:03 2024 +0200 tree-optimization/114733 - neg induction fails for 1 element vectors The neg induction vectorization code isn't prepared to deal with single element vectors. PR tree-optimization/114733 * tree-vect-loop.cc (vectorizable_nonlinear_induction): Reject neg induction vectorization of single element vectors. * gcc.dg/vect/pr114733.c: New testcase. (cherry picked from commit 45a41ace55d0ffb1097e374868242329788ec82a)
[Bug tree-optimization/114736] [13 Regression] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114736 --- Comment #12 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:0624852a3ea684f6b9dabea864bcb45e31304728 commit r13-8683-g0624852a3ea684f6b9dabea864bcb45e31304728 Author: Richard Biener Date: Tue Apr 16 11:33:48 2024 +0200 tree-optimization/114736 - SLP DFS walk issue The following fixes a DFS walk issue when identifying to be ignored latch edges. We have (bogus) SLP_TREE_REPRESENTATIVEs for VEC_PERM nodes so those have to be explicitly ignored as possibly being PHIs. PR tree-optimization/114736 * tree-vect-slp.cc (vect_optimize_slp_pass::is_cfg_latch_edge): Do not consider VEC_PERM_EXPRs as PHI use. * gfortran.dg/vect/pr114736.f90: New testcase. (cherry picked from commit f949481a1f7ab973608a4ffcc0e342ab5a74e8e4)
[Bug target/114936] [14/15 Regression] Typo in aarch64-ldp-fusion.cc:combine_reg_notes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114936 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.2 Target||aarch64
[Bug lto/114655] [12/13 Regression] -flto=4 at link time does not override -flto=auto from compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114655 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:d040606257a579f120271dcd2af62a3458a7856e commit r13-8681-gd040606257a579f120271dcd2af62a3458a7856e Author: Richard Biener Date: Tue Apr 9 14:25:57 2024 +0200 lto/114655 - -flto=4 at link time doesn't override -flto=auto at compile time The following adjusts -flto option processing in lto-wrapper to have link-time -flto override any compile time setting. PR lto/114655 * lto-wrapper.cc (merge_flto_options): Add force argument. (merge_and_complain): Do not force here. (run_gcc): But here to make the link-time -flto option override any compile-time one. (cherry picked from commit 32fb04adae90a0ea68e64e8fc3cb04b613b2e9f3)
[Bug tree-optimization/114485] [13 Regression] Wrong code with -O3 -march=rv64gcv on riscv or `-O3 -march=armv9-a` for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485 --- Comment #14 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:a676581ddc49a6ead8edced7bb4b92aeceebde56 commit r13-8679-ga676581ddc49a6ead8edced7bb4b92aeceebde56 Author: Richard Biener Date: Thu Apr 4 10:00:51 2024 +0200 tree-optimization/114485 - neg induction with partial vectors We can't use vect_update_ivs_after_vectorizer for partial vectors, the following fixes vect_can_peel_nonlinear_iv_p accordingly. PR tree-optimization/114485 * tree-vect-loop-manip.cc (vect_can_peel_nonlinear_iv_p): vect_step_op_neg isn't OK for partial vectors but only for unknown niter. * gcc.dg/vect/pr114485.c: New testcase. (cherry picked from commit 85621f98d245004a6c9787dde21e0acc17ab2c50)
[Bug tree-optimization/114937] [11 regression] -ftree-vrp optimizes out range check before conditional increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114937
Richard Biener changed:
What|Removed |Added
Known to fail||10.5.0, 11.4.1
Known to work||12.1.0, 9.5.0
Priority|P3 |P2
--- Comment #2 from Richard Biener ---
int __attribute__((noipa))
f(int x)
{
const int y = x;
if (x != __INT_MAX__)
++x;
return (x > y) ? x : 0;
}
int z = __INT_MAX__;
int main()
{
if (f(z) != 0)
__builtin_abort ();
return 0;
}
Did you run into this for real-world code?
[Bug tree-optimization/114937] [11 regression] -ftree-vrp optimizes out range check before conditional increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114937 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.5 Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-03 Keywords||wrong-code Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. This is the ifcombine bug still not fixed on the 11 branch, aka PR105142 I think.
[Bug tree-optimization/114937] New: [11 regression] -ftree-vrp optimizes out range check before conditional increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114937
Bug ID: 114937
Summary: [11 regression] -ftree-vrp optimizes out range check
before conditional increment
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mital at mitalashok dot co.uk
Target Milestone: ---
https://godbolt.org/z/fdMGWa4nq
int f(int x) {
const int y = x;
if (x != INT_MAX) {
++x;
}
return (x > y) ? x : 0;
}
int z = INT_MAX;
int main(void) {
// Prints INT_MIN when it should print 0
__builtin_printf("%d\n", f(z));
}
`f` is miscompiled at `-O1 -ftree-vrp` (also `-O2`) in GCC10/11 to return `x+1`
unconditionally.
The same happens with `if (x != INT_MIN) --x; return (x < y) ? x : 0;`.
This does not happen in GCC9 or GCC12+
[Bug fortran/114922] fsyntax-only need the modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- (In reply to Axel Ehrich from comment #3) > In my understanding, the intention of the option -fsyntax-only is to > construct the module files needed to compile the code. A build process > would involve two steps: Step 1: construct all module files with gfortran > -fsyntax only. Step 2: construct the object files without this option, while > relying on the presence of all module files. (I have found this recipe on > the internet and consider it valuable.) > The normal process is to compile directly the files (without -fsyntax-only) in the right order, in a single step. Some people prefer to do it in two steps, depending on their needs. > Alternatively, the purpose of -fsyntax-only could be to save compile time by > a doing quick first check before entering the time consuming parts of the > compilation. Yes, that's the main purpose. > If this syntax check goes so far that it requires the module > files already, the goal mentioned above cannot be reached. Yes, it can. The files have to be compiled in the right order. Keep in mind that the compiler processes one file at a time and doesn't have a global knowledge of all the files together. Consider this example: module m2 use m1 end module m2 What symbols should be made available in the module file for m2? Don't you think that the knowledge of the content of m1 is needed?
[Bug analyzer/111475] [14 regression] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 David Malcolm changed: What|Removed |Added Target Milestone|14.0|14.2 Summary|[14/15 regression] Many C++ |[14 regression] Many C++ |analyzer tests FAIL |analyzer tests FAIL --- Comment #14 from David Malcolm --- Testing the above patch on sparc-sun-solaris2.11 (cfarm216) shows this improvement to the results of 'gmake check-g++ RUNTESTFLAGS="analyzer.exp=*"': # of expected passes 11395 -> 12043 # of unexpected failures684 -> 0 # of unexpected successes 4 -> 0 # of expected failures 443 -> 447 So I believe this is fixed on trunk; waiting until after GCC 14.1 to backport to gcc 14.
[Bug analyzer/97111] Support for exception-handling within -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5219414f3cde3c1037e289a6654cd722cfa75dea commit r15-131-g5219414f3cde3c1037e289a6654cd722cfa75dea Author: David Malcolm Date: Fri May 3 09:05:29 2024 -0400 testsuite: fix analyzer C++ failures on Solaris [PR111475] As part of PR analyzer/96395, these patches moved testcases from gcc.dg/analyzer to c-c++-common/analyzer: - r14-3503-g55f6a7d949abc7 - r14-3823-g50b5199cff6908 - r14-6564-gae034b9106fbdd Unfortunately this led to numerous g++ testsuite failures on Solaris, tracked as PR analyzer/111475. Almost all of the failures are due to standard library differences where including a C standard library on C++ e.g. leads to the plain symbols referencing the symbols "std::" via a "using" declaration, whereas I had written the code expecting them to use symbols in the root namespace. The analyzer has special-case handling of many functions by name. This patch generalizes such handling to also match against functions in "std::" for all of the cases I found in the testsuite (via manual inspection of the preprocessed test cases against Solaris headers). This fixes cases where the analyzer was failing to "know about" the behavior of such functions. Other such failures are due to "std::" prefixes appearing in names of functions in the output, leading to mismatches against expected output. The patch adds regexes to some cases, and moves some other cases back from c-c++-common to gcc.dg where the dg-multiline syntax isn't expressive enough. Various "fd-*.c" failures relate to Solaris's socket-handling functions not being marked with "noexcept", where due to PR analyzer/97111 we mishandle the exception-handling edges in the CFG, leading to leak false positives. The patch works around this by adding -fno-exceptions to these cases, pending a proper fix for PR analyzer/97111. gcc/analyzer/ChangeLog: PR analyzer/111475 * analyzer.cc (is_special_named_call_p): Add "look_in_std" param. (is_std_function_p): Make non-static. * analyzer.h (is_special_named_call_p): Add optional "look_in_std" param. (is_std_function_p): New decl. * engine.cc (stmt_requires_new_enode_p): Look for both "signal" and "std::signal". * kf.cc (register_known_functions): Add various "std::" copies of the known functions. * known-function-manager.cc (known_function_manager::~known_function_manager): Clean up m_std_ns_map_id_to_kf. (known_function_manager::add_std_ns): New. (known_function_manager::get_match): Also look for known "std::" functions. (known_function_manager::get_by_identifier_in_std_ns): New. * known-function-manager.h (known_function_manager::add_std_ns): New decl. (known_function_manager::get_by_identifier_in_std_ns): New decl. (known_function_manager::m_std_ns_map_id_to_kf): New field. * sm-file.cc (register_known_file_functions): Add various "std::" copies of the known functions. * sm-malloc.cc (malloc_state_machine::on_stmt): Handle "std::realloc". * sm-signal.cc (signal_unsafe_p): Consider "std::" copies of the functions as also being async-signal-unsafe. (signal_state_machine::on_stmt): Consider "std::signal". gcc/testsuite/ChangeLog: PR analyzer/111475 * c-c++-common/analyzer/fd-glibc-byte-stream-socket.c: Add -fno-exceptions for now. * c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c: Likewise. * c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c: Rename to... * c-c++-common/analyzer/fd-manpage-getaddrinfo-server.c: ...this, and add -fno-exceptions for now. * c-c++-common/analyzer/fd-socket-meaning.c: Add -fno-exceptions for now. * c-c++-common/analyzer/fd-symbolic-socket.c: Likewise. * c-c++-common/analyzer/flexible-array-member-1.c: Use regexp to handle C vs C++ differences in spelling of function name, which could have a "std::" prefix on some targets. * c-c++-common/analyzer/pr106539.c: Likewise. * c-c++-common/analyzer/malloc-ipa-8-unchecked.c: Move back to... * gcc.dg/analyzer/malloc-ipa-8-unchecked.c: ...here, dropping attempt to generalize output for C vs C++. * c-c++-common/analyzer/signal-4a.c: Move back to... * gcc.dg/analyzer/signal-4a.c: ...here, dropping attempt to generalize output for C vs C++. * c-c++-common/analyzer/signal-4b.c: M
[Bug target/114936] [14/15 Regression] Typo in aarch64-ldp-fusion.cc:combine_reg_notes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114936 Alex Coplan changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org Last reconfirmed||2024-05-03 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug analyzer/96395] Generalize gcc.dg/analyzer tests to be run with both C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395 --- Comment #9 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5219414f3cde3c1037e289a6654cd722cfa75dea commit r15-131-g5219414f3cde3c1037e289a6654cd722cfa75dea Author: David Malcolm Date: Fri May 3 09:05:29 2024 -0400 testsuite: fix analyzer C++ failures on Solaris [PR111475] As part of PR analyzer/96395, these patches moved testcases from gcc.dg/analyzer to c-c++-common/analyzer: - r14-3503-g55f6a7d949abc7 - r14-3823-g50b5199cff6908 - r14-6564-gae034b9106fbdd Unfortunately this led to numerous g++ testsuite failures on Solaris, tracked as PR analyzer/111475. Almost all of the failures are due to standard library differences where including a C standard library on C++ e.g. leads to the plain symbols referencing the symbols "std::" via a "using" declaration, whereas I had written the code expecting them to use symbols in the root namespace. The analyzer has special-case handling of many functions by name. This patch generalizes such handling to also match against functions in "std::" for all of the cases I found in the testsuite (via manual inspection of the preprocessed test cases against Solaris headers). This fixes cases where the analyzer was failing to "know about" the behavior of such functions. Other such failures are due to "std::" prefixes appearing in names of functions in the output, leading to mismatches against expected output. The patch adds regexes to some cases, and moves some other cases back from c-c++-common to gcc.dg where the dg-multiline syntax isn't expressive enough. Various "fd-*.c" failures relate to Solaris's socket-handling functions not being marked with "noexcept", where due to PR analyzer/97111 we mishandle the exception-handling edges in the CFG, leading to leak false positives. The patch works around this by adding -fno-exceptions to these cases, pending a proper fix for PR analyzer/97111. gcc/analyzer/ChangeLog: PR analyzer/111475 * analyzer.cc (is_special_named_call_p): Add "look_in_std" param. (is_std_function_p): Make non-static. * analyzer.h (is_special_named_call_p): Add optional "look_in_std" param. (is_std_function_p): New decl. * engine.cc (stmt_requires_new_enode_p): Look for both "signal" and "std::signal". * kf.cc (register_known_functions): Add various "std::" copies of the known functions. * known-function-manager.cc (known_function_manager::~known_function_manager): Clean up m_std_ns_map_id_to_kf. (known_function_manager::add_std_ns): New. (known_function_manager::get_match): Also look for known "std::" functions. (known_function_manager::get_by_identifier_in_std_ns): New. * known-function-manager.h (known_function_manager::add_std_ns): New decl. (known_function_manager::get_by_identifier_in_std_ns): New decl. (known_function_manager::m_std_ns_map_id_to_kf): New field. * sm-file.cc (register_known_file_functions): Add various "std::" copies of the known functions. * sm-malloc.cc (malloc_state_machine::on_stmt): Handle "std::realloc". * sm-signal.cc (signal_unsafe_p): Consider "std::" copies of the functions as also being async-signal-unsafe. (signal_state_machine::on_stmt): Consider "std::signal". gcc/testsuite/ChangeLog: PR analyzer/111475 * c-c++-common/analyzer/fd-glibc-byte-stream-socket.c: Add -fno-exceptions for now. * c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c: Likewise. * c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c: Rename to... * c-c++-common/analyzer/fd-manpage-getaddrinfo-server.c: ...this, and add -fno-exceptions for now. * c-c++-common/analyzer/fd-socket-meaning.c: Add -fno-exceptions for now. * c-c++-common/analyzer/fd-symbolic-socket.c: Likewise. * c-c++-common/analyzer/flexible-array-member-1.c: Use regexp to handle C vs C++ differences in spelling of function name, which could have a "std::" prefix on some targets. * c-c++-common/analyzer/pr106539.c: Likewise. * c-c++-common/analyzer/malloc-ipa-8-unchecked.c: Move back to... * gcc.dg/analyzer/malloc-ipa-8-unchecked.c: ...here, dropping attempt to generalize output for C vs C++. * c-c++-common/analyzer/signal-4a.c: Move back to... * gcc.dg/analyzer/signal-4a.c: ...here, dropping attempt to generalize output for C vs C++. * c-c++-common/analyzer/signal-4b.c: M
[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 --- Comment #13 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5219414f3cde3c1037e289a6654cd722cfa75dea commit r15-131-g5219414f3cde3c1037e289a6654cd722cfa75dea Author: David Malcolm Date: Fri May 3 09:05:29 2024 -0400 testsuite: fix analyzer C++ failures on Solaris [PR111475] As part of PR analyzer/96395, these patches moved testcases from gcc.dg/analyzer to c-c++-common/analyzer: - r14-3503-g55f6a7d949abc7 - r14-3823-g50b5199cff6908 - r14-6564-gae034b9106fbdd Unfortunately this led to numerous g++ testsuite failures on Solaris, tracked as PR analyzer/111475. Almost all of the failures are due to standard library differences where including a C standard library on C++ e.g. leads to the plain symbols referencing the symbols "std::" via a "using" declaration, whereas I had written the code expecting them to use symbols in the root namespace. The analyzer has special-case handling of many functions by name. This patch generalizes such handling to also match against functions in "std::" for all of the cases I found in the testsuite (via manual inspection of the preprocessed test cases against Solaris headers). This fixes cases where the analyzer was failing to "know about" the behavior of such functions. Other such failures are due to "std::" prefixes appearing in names of functions in the output, leading to mismatches against expected output. The patch adds regexes to some cases, and moves some other cases back from c-c++-common to gcc.dg where the dg-multiline syntax isn't expressive enough. Various "fd-*.c" failures relate to Solaris's socket-handling functions not being marked with "noexcept", where due to PR analyzer/97111 we mishandle the exception-handling edges in the CFG, leading to leak false positives. The patch works around this by adding -fno-exceptions to these cases, pending a proper fix for PR analyzer/97111. gcc/analyzer/ChangeLog: PR analyzer/111475 * analyzer.cc (is_special_named_call_p): Add "look_in_std" param. (is_std_function_p): Make non-static. * analyzer.h (is_special_named_call_p): Add optional "look_in_std" param. (is_std_function_p): New decl. * engine.cc (stmt_requires_new_enode_p): Look for both "signal" and "std::signal". * kf.cc (register_known_functions): Add various "std::" copies of the known functions. * known-function-manager.cc (known_function_manager::~known_function_manager): Clean up m_std_ns_map_id_to_kf. (known_function_manager::add_std_ns): New. (known_function_manager::get_match): Also look for known "std::" functions. (known_function_manager::get_by_identifier_in_std_ns): New. * known-function-manager.h (known_function_manager::add_std_ns): New decl. (known_function_manager::get_by_identifier_in_std_ns): New decl. (known_function_manager::m_std_ns_map_id_to_kf): New field. * sm-file.cc (register_known_file_functions): Add various "std::" copies of the known functions. * sm-malloc.cc (malloc_state_machine::on_stmt): Handle "std::realloc". * sm-signal.cc (signal_unsafe_p): Consider "std::" copies of the functions as also being async-signal-unsafe. (signal_state_machine::on_stmt): Consider "std::signal". gcc/testsuite/ChangeLog: PR analyzer/111475 * c-c++-common/analyzer/fd-glibc-byte-stream-socket.c: Add -fno-exceptions for now. * c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c: Likewise. * c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c: Rename to... * c-c++-common/analyzer/fd-manpage-getaddrinfo-server.c: ...this, and add -fno-exceptions for now. * c-c++-common/analyzer/fd-socket-meaning.c: Add -fno-exceptions for now. * c-c++-common/analyzer/fd-symbolic-socket.c: Likewise. * c-c++-common/analyzer/flexible-array-member-1.c: Use regexp to handle C vs C++ differences in spelling of function name, which could have a "std::" prefix on some targets. * c-c++-common/analyzer/pr106539.c: Likewise. * c-c++-common/analyzer/malloc-ipa-8-unchecked.c: Move back to... * gcc.dg/analyzer/malloc-ipa-8-unchecked.c: ...here, dropping attempt to generalize output for C vs C++. * c-c++-common/analyzer/signal-4a.c: Move back to... * gcc.dg/analyzer/signal-4a.c: ...here, dropping attempt to generalize output for C vs C++. * c-c++-common/analyzer/signal-4b.c:
[Bug c++/114459] [C++26] P2893R3 - Variadic friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 58100 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58100&action=edit gcc14-pr114459.patch Untested implementation.
[Bug target/114936] New: [14/15 Regression] Typo in aarch64-ldp-fusion.cc:combine_reg_notes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114936
Bug ID: 114936
Summary: [14/15 Regression] Typo in
aarch64-ldp-fusion.cc:combine_reg_notes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
aarch64-ldp-fusion.cc:combine_reg_notes has:
result = filter_notes (REG_NOTES (i2->rtl ()), result,
&found_eh_region, fr_expr);
result = filter_notes (REG_NOTES (i1->rtl ()), result,
&found_eh_region, fr_expr + 1);
if (!load_p)
{
// Simple frame-related sp-relative saves don't need CFI notes, but when
// we combine them into an stp we will need a CFI note as dwarf2cfi can't
// interpret the unspec pair representation directly.
if (RTX_FRAME_RELATED_P (i1->rtl ()) && !fr_expr[0])
fr_expr[0] = copy_rtx (PATTERN (i1->rtl ()));
if (RTX_FRAME_RELATED_P (i2->rtl ()) && !fr_expr[1])
fr_expr[1] = copy_rtx (PATTERN (i2->rtl ()));
}
so any REG_FRAME_RELATED_EXPR from i2 goes to fr_expr[0] and likewise i1 goes
to fr_expr[1], but then we have the opposite association inside the if
statement.
Many thanks to Matthew Malcomson for pointing this out to me.
I'm going to post the (arguably obvious) patch after testing that writes to
fr_expr + 1 first when we call filter_notes for i2. We may want to consider a
backport to GCC 14 too.
[Bug target/114734] [11/12/13/14 regression] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #17 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:796319476e4fd6813e8319061bc3a8f19b355e35 commit r14-10162-g796319476e4fd6813e8319061bc3a8f19b355e35 Author: Patrick O'Neill Date: Tue Apr 30 13:26:45 2024 -0700 RISC-V: Add testcase for pr114734 gcc/testsuite/ChangeLog: PR middle-end/114734 * gcc.target/riscv/rvv/autovec/pr114734.c: New test. Signed-off-by: Patrick O'Neill (cherry picked from commit ff4dc8b10a421cdb0c56f7f8c238609de4f9fbe2)
[Bug target/114734] [11/12/13 regression] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 Richard Biener changed: What|Removed |Added Known to work||14.0 Summary|[11/12/13/14 regression]|[11/12/13 regression] |RISC-V rv64gcv_zvl256b |RISC-V rv64gcv_zvl256b |miscompile with -flto -O3 |miscompile with -flto -O3 |-mrvv-vector-bits=zvl since |-mrvv-vector-bits=zvl since |r8-6047-g65dd1346027bb5 |r8-6047-g65dd1346027bb5 --- Comment #18 from Richard Biener --- We're getting a new RC, so pushed to 14 now as well.
[Bug target/114734] [11/12/13/14 regression] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #16 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:5c42872b2a08a742f061809c7650e0c62dd7a9f3 commit r14-10161-g5c42872b2a08a742f061809c7650e0c62dd7a9f3 Author: Richard Biener Date: Fri Apr 26 15:47:13 2024 +0200 middle-end/114734 - wrong code with expand_call_mem_ref When expand_call_mem_ref looks at the definition of the address argument to eventually expand a &TARGET_MEM_REF argument together with a masked load it fails to honor constraints imposed by SSA coalescing decisions. The following fixes this. PR middle-end/114734 * internal-fn.cc (expand_call_mem_ref): Use get_gimple_for_ssa_name to get at the def stmt of the address argument to honor SSA coalescing constraints. (cherry picked from commit 4d3a5618de5a949c61605f545f90e81bc502)
[Bug rtl-optimization/114924] [11/12/13/14 Regression] Wrong update of MEM_EXPR by RTL loop unrolling since r11-2963-gd6a05b494b4b71
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924 --- Comment #2 from GCC Commits --- The releases/gcc-14 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:242fbc0df6c23115c47d256e66fba6a770265c5d commit r14-10160-g242fbc0df6c23115c47d256e66fba6a770265c5d Author: Alex Coplan Date: Fri May 3 09:23:59 2024 +0100 cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR114924] The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up accidentally dropping (e.g.) an ARRAY_REF from the MEM_EXPR and end up replacing it with the underlying MEM_REF. This leads to an inconsistency in the MEM_EXPR information, and could lead to wrong code. While the walk down to the MEM_REF is necessary to update MR_DEPENDENCE_CLIQUE, we should use the outer tree expression for the MEM_EXPR. This patch does that. gcc/ChangeLog: PR rtl-optimization/114924 * cfgrtl.cc (duplicate_insn_chain): When updating MEM_EXPRs, don't strip (e.g.) ARRAY_REFs from the final MEM_EXPR. (cherry picked from commit fe40d525619eee9c2821126390df75068df4773a)
[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582 --- Comment #6 from Ian Lance Taylor --- There is no floating-point in the user code, but Go does have a runtime that runs at the start of every program, and it is possible that that code uses some floating-point operations. In particular by default memory allocation randomly profiles a small number of operations, and determining whether to do a random profile appears to involve floating-point operations (libgo/go/runtime/fastlog2.go).
[Bug c++/114935] [14/15 regression] Miscompilation of initializer_list in presence of exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114935 Jason Merrill changed: What|Removed |Added Priority|P3 |P1 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Last reconfirmed||2024-05-03 Target Milestone|--- |14.0 Summary|Miscompilation of |[14/15 regression] |initializer_list in presence of |initializer_list in presence of ||exceptions Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug c++/114935] New: Miscompilation of initializer_list in presence of exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114935
Bug ID: 114935
Summary: Miscompilation of initializer_list in
presence of exceptions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
The following testcase:
#include
#include
void __attribute__((noipa))
tata(std::initializer_list init)
{
throw 1;
}
int
main()
{
try
{
tata({ "0123456789012346" }); // using shorter string or "..."s works
}
catch (...)
{
}
}
aborts when compiled with GCC 14 even when not optimizing.
I have bisected the failure to r14-1705-g2764335bd336f2 (Jason
Merrill: c++: build initializer_list in a loop [PR105838])
This has been extracted from libstorage-ng testsuite and originally
filed as https://bugzilla.opensuse.org/show_bug.cgi?id=1223820
[Bug target/114910] can't build a c6x cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910 --- Comment #9 from Marc Poulhiès --- Yes, sorry I should have added that in my original message (I did mention the commit on IRC). This is the commit that introduces the hardcfr.c file that is miscompiled. The error may be latent and bisecting should probably run the above command with a copy of a preprocessed hardcfr.c ?
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #13 from Dmitrii Pasechnik --- Created attachment 58099 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58099&action=edit data for comment 12 - decompiled things data for comment 12 - decompiled .so's, .so's themselves, original C file. BROKEN* are for -O2 option, and FIXED* are for -O0 option.
[Bug target/114910] can't build a c6x cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910 --- Comment #8 from Mikael Pettersson --- According to my git bisect, the assembler error started with 551935d11817dd5b139d66c36f62c0f0eba0db06 is the first new commit commit 551935d11817dd5b139d66c36f62c0f0eba0db06 Author: Alexandre Oliva Date: Fri Oct 20 07:50:33 2023 -0300 Control flow redundancy hardening
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 Dmitrii Pasechnik changed: What|Removed |Added CC||dima.pasechnik at cs dot ox.ac.uk --- Comment #12 from Dmitrii Pasechnik --- A colleague disassembled, using ghidra (https://ghidra-sre.org/), the results of the compilations with, respectively, -O2 and with -O0 flags. Comparing the results, in the broken (built with -O2) case one sees a miscompilation of a call to GAP_CallFunc3Args - it is called with one argument less than it should, three instead of four! broken (-O2): > plVar9 = (long *)GAP_CallFunc3Args(*(undefined8 *)(param_1 + > 0x20),local_a0[4], > local_a8[4]); vs. good (-O0): < LAB_0013cbd9: < plVar10 = (long *)GAP_CallFunc3Args(*(undefined8 *)(param_1 + 0x20),local_a8[4], < local_a0[4],plVar16[4]); And this is despite the prototype for calling GAP_CallFunc3Args() is found in "gap/libgap-api.h", which is included in example.c as #include "gap/libgap-api.h", meant to be respected during the compilation. I hope this helps in chasing down the obvious compiler bug. Perhaps it can be also seen without disassembling, simply on the intermediate data generated by the compiler.
[Bug c/114931] [14/15 regression] ICE in get_alias_set when building tcl with -std=c23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931 --- Comment #16 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7a212ac678e13e0df5da2d090144b246a1262b64 commit r15-127-g7a212ac678e13e0df5da2d090144b246a1262b64 Author: Richard Biener Date: Fri May 3 11:48:07 2024 +0200 Avoid changing type in the type_hash_canon hash When building a type and type_hash_canon returns an existing type avoid changing it, in particular its TYPE_CANONICAL. PR middle-end/114931 * tree.cc (build_array_type_1): Return early when type_hash_canon returned an older existing type. (build_function_type): Likewise. (build_method_type_directly): Likewise. (build_offset_type): Likewise.
[Bug fortran/114922] fsyntax-only need the modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922 --- Comment #3 from Axel Ehrich --- The question is related to the actual purpose of the option -fsyntax only: In my understanding, the intention of the option -fsyntax-only is to construct the module files needed to compile the code. A build process would involve two steps: Step 1: construct all module files with gfortran -fsyntax only. Step 2: construct the object files without this option, while relying on the presence of all module files. (I have found this recipe on the internet and consider it valuable.) Alternatively, the purpose of -fsyntax-only could be to save compile time by a doing quick first check before entering the time consuming parts of the compilation. If this syntax check goes so far that it requires the module files already, the goal mentioned above cannot be reached.
[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114860 --- Comment #4 from prathamesh3492 at gcc dot gnu.org --- Hi Tamar, Sorry for late response. perf profile for povray with LTO: Compiled with 82d6d385f97 (commit before a2f4be3dae0): 20.03% pov::All_CSG_Intersect_Intersections 16.42% pov::All_Plane_Intersections 10.29% pov::All_Sphere_Intersections 10.10% pov::Intersect_BBox_Tree Compiled with a2f4be3dae0: 19.51% pov::All_CSG_Intersect_Intersections 16.91% pov::All_Plane_Intersections 12.53% pov::All_Sphere_Intersections 9.81% pov::Intersect_BBox_Tree I verified there are no code-gen differences for any of the above hot functions. Running size on povray_r_exe.out shows a slight code-size decrease of 344 bytes for text section: Compiled with 82d6d385f97: 1101505 Compiled with a2f4be3dae0: 1101161 Curiously, there’s a meaningful difference for pov::All_Sphere_Intersections, which seems to be caused due to following adrp instruction (with no code-gen changes in All_Sphere_Intersections): Compiled with 82d6d385f97: 18.07 │4aec44: adrp x0, 4e 1.77 │4aec48: ldr d28, [x0, #2784] Compiled with a2f4be3dae0: 28.93 │4aeae4: adrp x0, 4e 1.27 │4aeae8: ldr d28, [x0, #2432] This seems to come from following condition in Intersect_Sphere (which gets inlined into All_Sphere Intersections): if ((OCSquared >= Radius2) && (t_Closest_Approach < EPSILON)) As far as I see, there’s no difference between both adrp instructions except the address (4aec44 vs 4aeae4). And as far as I know, adrp will only calculate pc-relative page address (and not load any data). To check for any possible icache misses I used L1I_CACHE_REFILL counter, and turns out that there are 64% more L1 icache misses for above adrp instruction with a2f4be3dae0 compared to 82d6d385f97, which may (partially) explain the performance difference ? Although perf stat shows there are around 7% more L1 icache misses for whole program run with 82d6d385f97 compared to a2f4be3dae0. I could (repeatedly) reproduce the issue on two neoverse-v2 machines. The full command line passed to the compiler was: "-O3 -Wl,-z,muldefs -lm -fallow-argument-mismatch -fpermissive -fstack-arrays -flto -march=native -mcpu=neoverse-v2" Thanks, Prathamesh
[Bug tree-optimization/111882] [13 Regression] : internal compiler error: in get_expr_operand in ifcvt with Variable length arrays and bitfields inside a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Ball : https://gcc.gnu.org/g:4950f6bcd3cce9deb630b76af42cd6d6968ba03f commit r13-8678-g4950f6bcd3cce9deb630b76af42cd6d6968ba03f Author: Andre Vieira Date: Fri Oct 20 17:02:32 2023 +0100 ifcvt: Don't lower bitfields with non-constant offsets [PR 111882] This patch stops lowering of bitfields by ifcvt when they have non-constant offsets as we are not likely to be able to do anything useful with those during vectorization. That also fixes the issue reported in PR 111882, which was being caused by an offset with a side-effect being lowered, but constants have no side-effects so we will no longer run into that problem. gcc/ChangeLog: PR tree-optimization/111882 * tree-if-conv.cc (get_bitfield_rep): Return NULL_TREE for bitfields with non-constant offsets. gcc/testsuite/ChangeLog: * gcc.dg/vect/pr111882.c: New test. (cherry picked from commit 24cf1f600b8ad34c68a51f48884e72d01f729893)
[Bug c/114931] [14/15 regression] ICE in get_alias_set when building tcl with -std=c23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931 --- Comment #15 from Richard Biener --- Created attachment 58098 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58098&action=edit patch avoiding TYPE_CANONICAL tampering This avoids messing with TYPE_CANONICAL on types already in the hash - it doesn't fix the bug on its own but is a good thing anyway.
[Bug c++/114933] [15 Regression] mcfgthread-1.6.1 typecheck failure: error: explicit specializations are not permitted here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933 --- Comment #8 from LIU Hao --- Fixed in this commit: https://github.com/lhmouse/mcfgthread/commit/86ea295e41523183e7680c03cab35e6eb74c4857 It has actually been disallowed since C++98 (N1804) but as part of a different paragraph.
[Bug c++/114934] New: Error message for expected unqualified-id could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114934 Bug ID: 114934 Summary: Error message for expected unqualified-id could be improved Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- Suppose I misspelled an extra colon for the namespace (https://godbolt.org/z/q3b7531q3): #include #include using Tuple = std::tuple; GCC gives: :4:43: error: template argument 1 is invalid 4 | using Tuple = std::tuple; | ^ Although it is not stated why it is invalid, it is still acceptable. Clang gives: :4:31: error: expected unqualified-id 4 | using Tuple = std::tuple; | ^ It correctly points out the location of the issue which is nice. However, I changed it to the following (https://godbolt.org/z/zfoqeoxE3): #include #include using Pair = std::pair; GCC will give: :4:41: error: wrong number of template arguments (1, should be 2) 4 | using Pair = std::pair; | This is unkind because it doesn't indicate which one is invalid, but rather the *wrong number* of arguments. This can be very confusing to users who haven't discovered the typo, as there are indeed 2 template parameters here (which can make debugging extremely difficult if there are plenty of template parameters in the template list)
[Bug c++/114933] [15 Regression] mcfgthread-1.6.1 typecheck failure: error: explicit specializations are not permitted here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933 --- Comment #7 from Andrew Pinski --- (In reply to LIU Hao from comment #6) > This paragraph is new in N4658 and was not in N4917. Better to avoid it by > moving the specialization into an extern "C++" block. Thanks for the report. Right that is because of p2615r1 which is consider a DR due to cwg 2443: https://cplusplus.github.io/CWG/issues/2443.html and we only applied to back to C++20 (due to it only needing for modules).
[Bug c++/114933] [15 Regression] mcfgthread-1.6.1 typecheck failure: error: explicit specializations are not permitted here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933 --- Comment #6 from LIU Hao --- ISO/IEC WG21 N4917 > 13.9.4 Explicit specialization [temp.expl.spec] > 2 An explicit specialization shall not use a storage-class-specifier (9.2.2) > other than thread_local. This paragraph is new in N4658 and was not in N4917. Better to avoid it by moving the specialization into an extern "C++" block. Thanks for the report.
[Bug c++/114933] [15 Regression] mcfgthread-1.6.1 typecheck failure: error: explicit specializations are not permitted here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
--- Comment #5 from Andrew Pinski ---
The easy fix is to do:
extern "C++" { template struct __MCF_static_assert; }
extern "C++" { template<> struct __MCF_static_assert { }; }
Note from the commit message:
However there are also a couple of changes made to linkage specifiers
('extern "C"'); I've applied these as since C++20, to line up with when
modules were actually introduced.
[Bug tree-optimization/114932] Improvement in CHREC can give large performance gains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932 --- Comment #7 from Richard Biener --- Likely Base: (integer(kind=4) *) &block + ((sizetype) ((unsigned long) l0_19(D) * 324) + 36) vs. Base: (integer(kind=4) *) &block + ((sizetype) ((integer(kind=8)) l0_19(D) * 81) + 9) * 4 where we fail to optimize the outer multiply. It's ((unsigned)((signed)x * 81) + 9) * 4 and likely done by extract_muldiv for the case of (unsigned)x. The trick would be to promote the inner multiply to unsigned to make the otherwise profitable transform valid. But best not by enhancing extract_muldiv ...
[Bug c++/114933] [15 Regression] mcfgthread-1.6.1 typecheck failure: error: explicit specializations are not permitted here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2615r1.html `For consistency extern "C" is given the same restrictions when used directly.` So yes.
[Bug c++/114933] [15 Regression] mcfgthread-1.6.1 typecheck failure: error: explicit specializations are not permitted here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933 --- Comment #3 from Andrew Pinski --- (In reply to Sergei Trofimovich from comment #1) > /cc LIU Hao in case it's a new c++20 restriction and mcfgthread would need > to adapt. Looks like it is one: https://cplusplus.github.io/CWG/issues/2443.html
[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #12 from Aldy Hernandez --- (In reply to Andrew Pinski from comment #10) > If Aldy does not fix it by Saturday, I will give the union a try then. I > will also try out the solaris machine on the compile farm if possible. Sorry, didn't mean for you to pick this up. Thanks for the analysis. I can take it from here.
[Bug c++/114933] [15 Regression] mcfgthread-1.6.1 typecheck failure: error: explicit specializations are not permitted here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933 --- Comment #2 from Andrew Pinski --- r15-84-g79420dd3441458
[Bug c/114931] [14/15 regression] ICE in get_alias_set when building tcl with -std=c23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931 --- Comment #14 from Richard Biener --- Created attachment 58097 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58097&action=edit patch I am testing So I'm testing this. It definitely will "split brain" at the point the FE mucks with TYPE_CANONICAL of any existing type (and it will break an existing hash entry in the canonical type hash if it does so - looking it doesn't seem to muck with TYPE_CANONICAL of types that are possibly in the hash already though).
[Bug c++/114933] [15 Regression] mcfgthread-1.6.1 typecheck failure: error: explicit specializations are not permitted here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933 Sergei Trofimovich changed: What|Removed |Added CC||lh_mouse at 126 dot com Version|14.0|15.0 --- Comment #1 from Sergei Trofimovich --- The original trigger code resides at https://github.com/lhmouse/mcfgthread/blob/9f3c73a3651bf0cf94eef9681c5ba191d66b198b/mcfgthread/fwd.h#L131 /cc LIU Hao in case it's a new c++20 restriction and mcfgthread would need to adapt.
[Bug c/114931] [14/15 regression] ICE in get_alias_set when building tcl with -std=c23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #13 from Richard Biener ---
(In reply to Jakub Jelinek from comment #12)
> Anyway, such changes are a partial shift towards the model to update derived
> types which you said you don't want; it doesn't actually update them, but
> basically forces new types after the base type(s) is/are finalized.
Yes, I was wondering if when we make TYPE_STRUCTURAL_EQUALITY_P part of
the hash we're papering over the issue that we have recorded equal types
we didn't mark for structural compare. Though that would only be a missed
optimization I think (setting TYPE_STRUCTURAL_EQUALITY_P is).
> Another possibility might be simply in all the spots where we set
> TYPE_CANONICAL (t) = something; to add if (TYPE_STRUCTURAL_EQUALITY_P
> (TYPE_CANONICAL (t))) SET_TYPE_STRUCTURAL_EQUALITY (t);
But if TYPE_STRUCTURAL_EQUALITY_P (TYPE_CANONICAL (t)) then that canonical
type is broken. We should avoid (at all cost) creating such a type.
> On the build_function_type it could be
> --- gcc/tree.cc.jj2024-04-16 09:56:16.463008446 +0200
> +++ gcc/tree.cc 2024-05-03 10:21:04.119086667 +0200
> @@ -7511,17 +7511,25 @@ build_function_type (tree value_type, tr
>hashval_t hash = type_hash_canon_hash (t);
>t = type_hash_canon (hash, t);
>
> - /* Set up the canonical type. */
> - any_structural_p = TYPE_STRUCTURAL_EQUALITY_P (value_type);
> - any_noncanonical_p = TYPE_CANONICAL (value_type) != value_type;
> - canon_argtypes = maybe_canonicalize_argtypes (arg_types,
> - &any_structural_p,
> - &any_noncanonical_p);
> - if (any_structural_p)
> -SET_TYPE_STRUCTURAL_EQUALITY (t);
> - else if (any_noncanonical_p)
> -TYPE_CANONICAL (t) = build_function_type (TYPE_CANONICAL (value_type),
> - canon_argtypes);
> + if (TYPE_CANONICAL (t) == t)
> +{
> + /* Set up the canonical type. */
> + any_structural_p = TYPE_STRUCTURAL_EQUALITY_P (value_type);
> + any_noncanonical_p = TYPE_CANONICAL (value_type) != value_type;
> + canon_argtypes = maybe_canonicalize_argtypes (arg_types,
> + &any_structural_p,
> + &any_noncanonical_p);
> + if (any_structural_p)
> + SET_TYPE_STRUCTURAL_EQUALITY (t);
> + else if (any_noncanonical_p)
> + {
> + TYPE_CANONICAL (t)
> + = build_function_type (TYPE_CANONICAL (value_type),
> +canon_argtypes);
we shouldn't get a structual equality type here when !any_structural_p
Yes, ensuring this within type_hash_canon only papers over the issue in
different ways (to some extent). But this is how things are.
I guess another option might be to have the FE set TYPE_STRUCTURAL_EQUALITY_P
on _all_ types that possibly get "finalized" only later and have a second
sweep over all those types after the unit is finished and recompute
TYPE_CANONICAL there, making sure to catch all derived types. Like LTO
re-computes TYPE_CANONICAL.
> + if (TYPE_STRUCTURAL_EQUALITY_P (TYPE_CANONICAL (t)))
> + SET_TYPE_STRUCTURAL_EQUALITY (t);
> + }
> +}
>
>if (!COMPLETE_TYPE_P (t))
> layout_type (t);
[Bug c++/114933] New: [15 Regression] mcfgthread-1.6.1 typecheck failure: error: explicit specializations are not permitted here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
Bug ID: 114933
Summary: [15 Regression] mcfgthread-1.6.1 typecheck failure:
error: explicit specializations are not permitted here
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
mcfgthread-1.6.1 build failure started happening a few days ago on `gcc`
`master`. On r15-116-gff4dc8b10a421c minimized example failure looks this way:
// $ cat a.cc
extern "C++" template struct __MCF_static_assert;
extern "C++" template<> struct __MCF_static_assert { };
Fails as:
$ g++ -c a.cc -std=c++20
a.cc:2:14: error: explicit specializations are not permitted here
2 | extern "C++" template<> struct __MCF_static_assert { };
| ^~
For comparison 13.2.0 builds the example successfully:
$ g++-13.2.0 -c a.cc -std=c++20
Compiler details:
$ g++ -v |& unnix
Using built-in specs.
COLLECT_GCC=/<>/gcc-15.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-15.0.0/libexec/gcc/x86_64-unknown-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-15.0.0
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.1-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.1/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.39-31-dev/include
--with-build-sysroot=/
--with-gxx-include-dir=/<>/gcc-15.0.0/include/c++/15.0.0/
--program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 (experimental) (GCC)
[Bug tree-optimization/114932] Improvement in CHREC can give large performance gains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932 --- Comment #6 from Tamar Christina --- Created attachment 58096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58096&action=edit exchange2.fppized-bad.f90.187t.ivopts
[Bug tree-optimization/114932] Improvement in CHREC can give large performance gains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932 --- Comment #5 from Tamar Christina --- Created attachment 58095 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58095&action=edit exchange2.fppized-good.f90.187t.ivopts
[Bug tree-optimization/114932] Improvement in CHREC can give large performance gains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932 --- Comment #4 from Tamar Christina --- reduced more: --- module brute_force integer, parameter :: r=9 integer block(r, r, 0) contains subroutine brute do do do do do do do i7 = l0, 1 select case(1 ) case(1) block(:2, 7:, 1) = block(:2, 7:, i7) - 1 end select do i8 = 1, 1 do i9 = 1, 1 if(1 == 1) then call digits_20 end if end do end do end do end do end do end do end do end do end do end end --- I'll have to stop now till I'm back, but the main difference seems to be in: good: : IV struct: SSA_NAME: _1 Type: integer(kind=8) Base: (integer(kind=8)) ((unsigned long) l0_19(D) * 81) Step: 81 Biv: N Overflowness wrto loop niter: Overflow IV struct: SSA_NAME: _20 Type: integer(kind=8) Base: (integer(kind=8)) l0_19(D) Step: 1 Biv: N Overflowness wrto loop niter: No-overflow IV struct: SSA_NAME: i7_28 Type: integer(kind=4) Base: l0_19(D) + 1 Step: 1 Biv: Y Overflowness wrto loop niter: No-overflow IV struct: SSA_NAME: vectp.22_46 Type: integer(kind=4) * Base: (integer(kind=4) *) &block + ((sizetype) ((unsigned long) l0_19(D) * 324) + 36) Step: 324 Object: (void *) &block Biv: N Overflowness wrto loop niter: No-overflow bad: : IV struct: SSA_NAME: _1 Type: integer(kind=8) Base: (integer(kind=8)) l0_19(D) * 81 Step: 81 Biv: N Overflowness wrto loop niter: No-overflow IV struct: SSA_NAME: _20 Type: integer(kind=8) Base: (integer(kind=8)) l0_19(D) Step: 1 Biv: N Overflowness wrto loop niter: No-overflow IV struct: SSA_NAME: i7_28 Type: integer(kind=4) Base: l0_19(D) + 1 Step: 1 Biv: Y Overflowness wrto loop niter: No-overflow IV struct: SSA_NAME: vectp.22_46 Type: integer(kind=4) * Base: (integer(kind=4) *) &block + ((sizetype) ((integer(kind=8)) l0_19(D) * 81) + 9) * 4 Step: 324 Object: (void *) &block Biv: N Overflowness wrto loop niter: No-overflow
[Bug rtl-optimization/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #7 from Andrew Pinski ---
(In reply to Segher Boessenkool from comment #6)
> (In reply to Andrew Pinski from comment #2)
> > Looks like the issue is during combine.
> >
> > We go from CCGC with a sign_extend to a zero_extend with CCZ. that can't be
> > right.
>
> Why is that not correct? zero_extend is preferred over sign_extend, and both
> are equivalent when only checking for zero.
For Equality they are equivalent yes. But when doing `a >=s 0` a sign
extend/extract will cause different results from a zero extend/extract.
> Is there something wrong in target code here, perhaps?
For arm, x86 and mips?
For testcase in comment #4 on x86_64:
Before combine we start with:
```
(insn 16 15 17 2 (parallel [
(set (reg:SI 106 [ t_4 ])
(and:SI (reg:SI 105 [ tt1_3 ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":6:9 617 {*andsi_1}
(expr_list:REG_DEAD (reg:SI 105 [ tt1_3 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 17 16 20 2 (parallel [
(set (reg:SI 107 [ e_5 ])
(neg:SI (reg:SI 106 [ t_4 ])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":7:9 804 {*negsi_1}
(expr_list:REG_DEAD (reg:SI 106 [ t_4 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 20 17 21 2 (set (reg:CCGC 17 flags)
(compare:CCGC (reg:SI 107 [ e_5 ])
(const_int -1 [0x]))) "/app/example.cpp":8:16 11
{*cmpsi_1}
(expr_list:REG_DEAD (reg:SI 107 [ e_5 ])
(nil)))
(insn 21 20 22 2 (set (reg:QI 109)
(ge:QI (reg:CCGC 17 flags)
(const_int 0 [0]))) "/app/example.cpp":8:16 1125 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCGC 17 flags)
(nil)))
(insn 22 21 23 2 (set (reg:SI 108 [ _1 ])
(zero_extend:SI (reg:QI 109))) "/app/example.cpp":8:16 169
{*zero_extendqisi2}
(expr_list:REG_DEAD (reg:QI 109)
(nil)))
(insn 23 22 24 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 108 [ _1 ])
(const_int 0 [0]))) "/app/example.cpp":9:8 7 {*cmpsi_ccno_1}
(expr_list:REG_DEAD (reg:SI 108 [ _1 ])
(nil)))
(jump_insn 24 23 30 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 30)
(pc))) "/app/example.cpp":9:8 1130 {*jcc}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 7 (nil)))
-> 30)
```
We first combine 16->17 into:
```
(parallel [
(set (reg:SI 107 [ e_5 ])
(sign_extract:SI (reg:SI 105 [ tt1_3 ])
(const_int 1 [0x1])
(const_int 0 [0])))
(clobber (reg:CC 17 flags))
])
```
which is correct and good
And then when combining 17 -> 20 combine does:
Trying 17 -> 20:
17: {r107:SI=sign_extract(r105:SI,0x1,0);clobber flags:CC;}
REG_DEAD r105:SI
REG_UNUSED flags:CC
20: flags:CCGC=cmp(r107:SI,0x)
REG_DEAD r107:SI
Successfully matched this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:SI (reg:SI 105 [ tt1_3 ])
(const_int 1 [0x1])
(const_int 0 [0]))
(const_int 0 [0])))
Successfully matched this instruction:
(set (reg:QI 109)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0])))
Which is also replacing insn 21 incorrectly.
We go from `-(a&1) >= -1` (which is always true) to `(a&1) != 0`.
Maybe we go to `(a&1) <= 1` (still always true) and we mess up somehow to `(a &
1) != 0`
[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2024-05-03 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #5 from Eric Botcazou --- Rather weird, given that there is apparently no FP in the code. The (kludgy) way out could be to exclude the inexact flag from the test, as I don't think that people really care about exceptions on inexact results in practice.
[Bug c/114931] [14/15 regression] ICE in get_alias_set when building tcl with -std=c23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #12 from Jakub Jelinek ---
Anyway, such changes are a partial shift towards the model to update derived
types which you said you don't want; it doesn't actually update them, but
basically forces new types after the base type(s) is/are finalized.
Another possibility might be simply in all the spots where we set
TYPE_CANONICAL (t) = something; to add if (TYPE_STRUCTURAL_EQUALITY_P
(TYPE_CANONICAL (t))) SET_TYPE_STRUCTURAL_EQUALITY (t);
On the build_function_type it could be
--- gcc/tree.cc.jj 2024-04-16 09:56:16.463008446 +0200
+++ gcc/tree.cc 2024-05-03 10:21:04.119086667 +0200
@@ -7511,17 +7511,25 @@ build_function_type (tree value_type, tr
hashval_t hash = type_hash_canon_hash (t);
t = type_hash_canon (hash, t);
- /* Set up the canonical type. */
- any_structural_p = TYPE_STRUCTURAL_EQUALITY_P (value_type);
- any_noncanonical_p = TYPE_CANONICAL (value_type) != value_type;
- canon_argtypes = maybe_canonicalize_argtypes (arg_types,
- &any_structural_p,
- &any_noncanonical_p);
- if (any_structural_p)
-SET_TYPE_STRUCTURAL_EQUALITY (t);
- else if (any_noncanonical_p)
-TYPE_CANONICAL (t) = build_function_type (TYPE_CANONICAL (value_type),
- canon_argtypes);
+ if (TYPE_CANONICAL (t) == t)
+{
+ /* Set up the canonical type. */
+ any_structural_p = TYPE_STRUCTURAL_EQUALITY_P (value_type);
+ any_noncanonical_p = TYPE_CANONICAL (value_type) != value_type;
+ canon_argtypes = maybe_canonicalize_argtypes (arg_types,
+ &any_structural_p,
+ &any_noncanonical_p);
+ if (any_structural_p)
+ SET_TYPE_STRUCTURAL_EQUALITY (t);
+ else if (any_noncanonical_p)
+ {
+ TYPE_CANONICAL (t)
+ = build_function_type (TYPE_CANONICAL (value_type),
+ canon_argtypes);
+ if (TYPE_STRUCTURAL_EQUALITY_P (TYPE_CANONICAL (t)))
+ SET_TYPE_STRUCTURAL_EQUALITY (t);
+ }
+}
if (!COMPLETE_TYPE_P (t))
layout_type (t);
[Bug rtl-optimization/114924] [11/12/13/14/15 Regression] Wrong update of MEM_EXPR by RTL loop unrolling since r11-2963-gd6a05b494b4b71
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924 --- Comment #1 from GCC Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:fe40d525619eee9c2821126390df75068df4773a commit r15-126-gfe40d525619eee9c2821126390df75068df4773a Author: Alex Coplan Date: Fri May 3 09:23:59 2024 +0100 cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR114924] The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up accidentally dropping (e.g.) an ARRAY_REF from the MEM_EXPR and end up replacing it with the underlying MEM_REF. This leads to an inconsistency in the MEM_EXPR information, and could lead to wrong code. While the walk down to the MEM_REF is necessary to update MR_DEPENDENCE_CLIQUE, we should use the outer tree expression for the MEM_EXPR. This patch does that. gcc/ChangeLog: PR rtl-optimization/114924 * cfgrtl.cc (duplicate_insn_chain): When updating MEM_EXPRs, don't strip (e.g.) ARRAY_REFs from the final MEM_EXPR.
[Bug c/114931] [14/15 regression] ICE in get_alias_set when building tcl with -std=c23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-05-03 --- Comment #11 from Richard Biener --- Let me try to come up with a complete patch.
[Bug rtl-optimization/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 --- Comment #6 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #2) > Looks like the issue is during combine. > > We go from CCGC with a sign_extend to a zero_extend with CCZ. that can't be > right. Why is that not correct? zero_extend is preferred over sign_extend, and both are equivalent when only checking for zero. Is there something wrong in target code here, perhaps?
[Bug tree-optimization/114932] Improvement in CHREC can give large performance gains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932 --- Comment #3 from Tamar Christina --- (In reply to Andrew Pinski from comment #2) > > which is harder for prefetchers to follow. > > This seems like a limitation in the HW prefetcher rather than anything else. > Maybe the cost model for addressing mode should punish base+index if so. > Many HW prefetchers I know of are based on the final VA (or even PA) rather > looking at the instruction to see if it increments or not ... That was the first thing we tried, and even increasing the cost of register_offset to something ridiculously high doesn't change a thing. IVopts thinks it needs to use it and generates: _1150 = (voidD.26 *) _1148; _1152 = (sizetype) l0_78(D); _1154 = _1152 * 324; _1156 = _1154 + 216; # VUSE <.MEM_421> vect__349.614_1418 = MEM [(integer(kind=4)D.9 *)_1150 + _1156 * 1 clique 2 base 0]; Hence the bug report to see what's going on.
