[Bug tree-optimization/107591] range-op{,-float}.cc for x * x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591 --- Comment #19 from Pilar Latiesa --- The testcase: #include struct TVec { double x, y, z; }; double dot(TVec const &u, TVec const &v) { return u.x * v.x + u.y * v.y + u.y * v.y + u.z * v.z; } double mag(TVec const &u) { return std::sqrt(dot(u, u)); } with current trunk is compiled as: vmovsd 8(%rdi), %xmm0 vmovsd (%rdi), %xmm1 vmulsd %xmm0, %xmm0, %xmm0 vmovsd %xmm1, %xmm1, %xmm2 vfmadd132sd %xmm1, %xmm0, %xmm2 vmovsd 16(%rdi), %xmm1 vaddsd %xmm2, %xmm0, %xmm0 vfmadd132sd %xmm1, %xmm0, %xmm1 vsqrtsd %xmm1, %xmm1, %xmm0 ret That's excellent. Thanks
[Bug tree-optimization/109417] New: ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 Bug ID: 109417 Summary: ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhendong.su at inf dot ethz.ch Target Milestone: --- This appears to be a recent regression. Compiler Explorer: https://godbolt.org/z/eM6aG1aYc [605] % 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/13.0.1/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 --with-system-zlib Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.0.1 20230405 (experimental) [master r13-7008-gfdc5abbdcfb] (GCC) [606] % [606] % gcctk -O2 small.c; ./a.out [607] % [607] % gcctk -O3 small.c during GIMPLE pass: vrp small.c: In function ‘main’: small.c:3:5: internal compiler error: Segmentation fault 3 | int main() { | ^~~~ 0xeeb4bf crash_signal ../../gcc-trunk/gcc/toplev.cc:314 0x1cea605 gori_compute::may_recompute_p(tree_node*, basic_block_def*, int) ../../gcc-trunk/gcc/gimple-range-gori.cc:1322 0x1cda775 ranger_cache::range_from_dom(vrange&, tree_node*, basic_block_def*, ranger_cache::rfd_mode) ../../gcc-trunk/gcc/gimple-range-cache.cc:1462 0x1cdc8e0 ranger_cache::range_from_dom(vrange&, tree_node*, basic_block_def*, ranger_cache::rfd_mode) ../../gcc-trunk/gcc/gimple-range-cache.cc:1426 0x1cdc8e0 ranger_cache::fill_block_cache(tree_node*, basic_block_def*, basic_block_def*) ../../gcc-trunk/gcc/gimple-range-cache.cc:1212 0x1cdd5a4 ranger_cache::block_range(vrange&, basic_block_def*, tree_node*, bool) ../../gcc-trunk/gcc/gimple-range-cache.cc:1039 0x1cd3ce8 gimple_ranger::range_on_entry(vrange&, basic_block_def*, tree_node*) ../../gcc-trunk/gcc/gimple-range.cc:156 0x11bde4a remove_unreachable::remove_and_update_globals(bool) ../../gcc-trunk/gcc/tree-vrp.cc:156 0x11c066d remove_unreachable::remove_and_update_globals(bool) ../../gcc-trunk/gcc/tree-vrp.cc:1104 0x11c066d execute_ranger_vrp(function*, bool, bool) ../../gcc-trunk/gcc/tree-vrp.cc:1104 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. [608] % [608] % cat small.c int printf(const char *, ...); int c, d, *e, f[1][2], g; int main() { int h = 0, *a = &h, **b[1] = {&a}; while (e) while (g) { L: for (h = 0; h < 2; h++) { while (d) for (*e = 0; *e < 1;) printf("0"); while (c) ; f[g][h] = 0; } } if (h) goto L; return 0; }
[Bug ipa/109408] [13 Regression] ICE in decide_about_value, at ipa-cp.cc:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109408 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 109303 *** --- Comment #3 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 109303 ***
[Bug ipa/109408] [13 Regression] ICE in decide_about_value, at ipa-cp.cc:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109408 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 109303 ***
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303 --- Comment #12 from Martin Liška --- *** Bug 109408 has been marked as a duplicate of this bug. *** --- Comment #13 from Martin Liška --- *** Bug 109408 has been marked as a duplicate of this bug. ***
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303 --- Comment #12 from Martin Liška --- *** Bug 109408 has been marked as a duplicate of this bug. *** --- Comment #13 from Martin Liška --- *** Bug 109408 has been marked as a duplicate of this bug. ***
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 Xi Ruoyao changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #4 from Xi Ruoyao --- (In reply to Jonny Grant from comment #3) > A different example where GCC does a good job of indicating the line number > of a missing comma problem. > > > https://godbolt.org/z/asGhE3W17 > > > :6:5: error: expected '}' before '{' token > 6 | {"G", "H"}, > | ^ > :2:1: note: to match this '{' > 2 | { > | ^ > :6:5: error: expected ',' or ';' before '{' token > 6 | {"G", "H"}, > | ^ This is easy because the parser has to insert a comma here to correct the syntax. But for a missing } it can be added at one of multiple places to make the syntax correct. The parser always keeps progressing unless it's sure there is a syntax error. Note that static const char * list[][2] = { {"A", "B"}, {"C", "D"}, {"E", "F", {"G", "H"}, {"I", "J"} }}; is NOT a syntax error. It's a semantic error (violating a constraint) but the parser does not know about semantics (i.e. the parser does not know what "[2]" means at all). So the parser cannot be sure about the syntax error until the last line. Mixing the semantic analysis into the parser is not acceptable because it's not how a compiler is implemented. Make the parser try different locations and pass all possible syntax tree to the further passes is at least quadratic behavior and not acceptable. I'll say this WONTFIX. If someone knows how to do this in a rational way please reopen.
[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 Xi Ruoyao changed: What|Removed |Added Last reconfirmed||2023-04-05 Ever confirmed|0 |1 CC||xry111 at gcc dot gnu.org Keywords||ice-on-valid-code Known to work||12.2.0 Version|unknown |13.0 Summary|ICE on valid code at -O3 on |[13 Regression] ICE on |x86_64-linux-gnu: |valid code at -O3 on |Segmentation fault |x86_64-linux-gnu: ||Segmentation fault Status|UNCONFIRMED |NEW
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #42 from Tamar Christina --- Thanks for all the work so far folks! Just to clarify the current state, it looks like the first reduced testcase is now correct. But the larger example as in c26 is still suboptimal, but slightly better. https://godbolt.org/z/7vbrG8EMj
[Bug libstdc++/109405] Should class final decoration result in larger unique_ptr with deleter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109405 Xi Ruoyao changed: What|Removed |Added Resolution|--- |WONTFIX CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Xi Ruoyao --- WONTFIX then.
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 ktkachov at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #43 from ktkachov at gcc dot gnu.org --- Indeed, thank you for the high quality analysis and improvements! Marking this as P1 as it's a regression on aarch64-linux in GCC 13 so we'd want to track this for the release, but of course it's up to RMs for the final say.
[Bug libstdc++/109405] Should class final decoration result in larger unique_ptr with deleter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109405 --- Comment #4 from Jonathan Wakely --- It's possible to fix for the --enable-symvers=gnu-versioned-namespace build which does not promise a backwards compatible ABI. I didn't do that yet, I *think* it was because support for [[no_unique_address]] was still patchy in Clang and other non-GCC compilers. Maybe that's no longer an issue and it could be done now.
[Bug libstdc++/109418] New: -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109418 Bug ID: 109418 Summary: -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gareth-anthony-hulse at posteo dot net Target Milestone: --- Created attachment 54812 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54812&action=edit Output of `make -B 2> /tmp/errors.txt` `/usr/include/c++/12.2.1/bits/random.tcc` has variables that are possibly uninitialised. The two culprits being line 1577: `double __x;` and line 1600: `double __v;`. initialising them with a value such as 0, stops the complaints from the compiler. This bug triggers for me when compiling ImHex with commit version 89aee456c6cd897ea7e998340ded2004d3638412. The commit mentioned was supposed to work around this issue, but had no effect. Attached log 'errors.txt' which is an output from `make -B 2> /tmp/errors.txt`. Specs: https://linux-hardware.org/?probe=201a4578ea FLAGS: - CPPFLAGS = -D_FORTIFY_SOURCE=2 - CXXFLAGS = -O3 -ftree-vectorize -floop-interchange -ftree-loop-distribution -ftree-loop-linear -floop-parallelize-all -fgraphite-identity -ftree-parallelize-loops=24 -floop-strip-mine -floop-block -fPIC -ffat-lto-objects -flto-compression-level=9 -pipe -fno-signed-zeros -fno-trapping-math -fno-plt -frename-registers -fstack-protector-all -flto=24 -pthread -DNDEBUG -fstack-clash-protection -fcf-protection=full - $LDFLAGS = -Wl,-O3,-flto,--strip-all,--sort-common,--as-needed,-z,relro,-z,now,-z,defs -pthread
[Bug libstdc++/109418] -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109418 --- Comment #1 from Xi Ruoyao --- (In reply to Gareth Anthony Hulse from comment #0) > Created attachment 54812 [details] > Output of `make -B 2> /tmp/errors.txt` > > `/usr/include/c++/12.2.1/bits/random.tcc` has variables that are possibly > uninitialised. The two culprits being line 1577: `double __x;` and line > 1600: `double __v;`. initialising them with a value such as 0, stops the > complaints from the compiler. No it's not the culprit. It's obvious __x and __v are not used uninitialized so it's a false warning. But -Wmaybe-uninitialized creates false warnings in the nature (so it's named *maybe*-uninitialized). To me -Werror=maybe-uninitialized does not make any sense.
[Bug libstdc++/109418] -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109418 Xi Ruoyao changed: What|Removed |Added Keywords|easyhack| CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- Remove "easyhack" to prevent anyone from submitting a patch zero-initializing these variables to paper over the issue.
[Bug c++/109419] New: [modules] ICE: Segmentation fault when using -fmodules-ts and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109419 Bug ID: 109419 Summary: [modules] ICE: Segmentation fault when using -fmodules-ts and -g Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pap...@gmx.de Target Milestone: --- compiling -8x---8x---8x---8x--- #include struct A { A() { s.insert(1); } std::set s; }; #include -8x---8x---8x---8x--- as test.cpp with g++ -ggdb -std=c++20 -fmodules-ts -freport-bug -c test.cpp leads to an segmentation fault: internal compiler error: Segmentation fault signal terminated program cc1plus
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 --- Comment #8 from Richard Earnshaw --- The __ARM_ARCH_...__ macros turned out to be a very bad design decision. Each new architecture needs a new macro that older compilers (and software) will not know about. The ACLE approach is far more sensible and GCC has mostly adopted that now. I personally consider the existing __ARM_ARCH_...__ macros to be deprecated, though I don't think the manual actually says this yet. There is a known bug in GCC. ACLE says that __ARM_ARCH should have the value *100 + for architectures after arm-v8, but we don't implement that yet (there may already be a PR about this) and report __ARM_ARCH=8 for all existing armv8.xxx variants.
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Richard Earnshaw --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312 *** This bug has been marked as a duplicate of bug 99312 ***
[Bug target/99312] __ARM_ARCH is not implemented correctly when compiled with -march=armv8.1-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312 Richard Earnshaw changed: What|Removed |Added CC||Vedant.VijayYevale@infineon ||.com --- Comment #7 from Richard Earnshaw --- *** Bug 109415 has been marked as a duplicate of this bug. ***
[Bug target/99312] __ARM_ARCH is not implemented correctly when compiled with -march=armv8.1-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312 --- Comment #8 from Richard Earnshaw --- Applies to both AArch64 and Arm back-ends.
[Bug fortran/104272] finalizer gets called during allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272 --- Comment #5 from Kai Germaschewski --- (In reply to Paul Thomas from comment #4) > Created attachment 54811 [details] > Fix for this PR > > I was sufficiently intrigued by this bug that I decided that I would look > into it right away. After all, it is the first time that such an old > finalization problem was producing too many calls to the final subroutine. > > I'll be posting to the list after checking the deja-gnuified testcase. > > Paul Thanks a lot for looking into this. I briefly looked at `gfc_trans_allocate`, but it's definitely beyond me ;)
[Bug c++/109420] New: [13 Regression] lookup of 'struct T::X' at instantiation time does not ignore non-type bindings of 'X'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109420 Bug ID: 109420 Summary: [13 Regression] lookup of 'struct T::X' at instantiation time does not ignore non-type bindings of 'X' Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ppalka at gcc dot gnu.org Target Milestone: --- struct A { struct X { }; int X; }; template void f() { struct T::X x; } template void f(); : In instantiation of ‘void f() [with T = A]’: :11:20: required from here :8:15: error: ‘typename A::X’ names ‘int A::X’, which is not a type
[Bug c++/109420] [13 Regression] lookup of 'struct T::X' at instantiation time does not ignore non-type bindings of 'X'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109420 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to fail||13.0 Target Milestone|--- |13.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-04-05 Known to work||12.2.0 --- Comment #1 from Patrick Palka --- Started with r13-6098-g46711ff8e60d64
[Bug c++/109420] [13 Regression] lookup of 'struct T::X' at instantiation time does not ignore non-type bindings of 'X'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109420 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P1
[Bug target/109040] [13 Regression] wrong code with v16hi compare & mask on riscv64 at -O2 since r13-4907-g2e886eef7f2b5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Jeffrey A. Law --- Duplicate. *** This bug has been marked as a duplicate of bug 108947 ***
[Bug target/108947] [13 Regression] wrong code with -O2 -fno-forward-propagate and vector compare on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108947 --- Comment #2 from Jeffrey A. Law --- *** Bug 109040 has been marked as a duplicate of this bug. ***
[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905 since r13-5681-ge8109bd87766be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959 --- Comment #9 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:f0f372fab3e70622a4ea6fe4073991e1bb506e4e commit r13-7011-gf0f372fab3e70622a4ea6fe4073991e1bb506e4e Author: Martin Jambor Date: Wed Apr 5 16:36:49 2023 +0200 ipa: Avoid another ICE when dealing with type-incompatibilities (PR 108959) PR 108959 shows one more example where undefined code with type incompatible accesses to stuff passed in parameters can cause an ICE because we try to create a VIEW_CONVERT_EXPR of mismatching sizes: 1. IPA-CP tries to push one type from above, 2. IPA-SRA (correctly) decides the parameter is useless because it is only used to construct an argument to another function which does not use it and so the formal parameter should be removed, 3. but the code reconciling IPA-CP and IPA-SRA transformations still wants to perform the IPA-CP and overrides the built-in DCE of useless statements and tries to stuff constants into them instead, constants of a type with mismatching type and size. This patch avoids the situation in IPA-SRA by purging the IPA-CP results from any "aggregate" constants that are passed in parameters which are detected to be useless. It also removes IPA value range and bits information associated with removed parameters stored in the same structure so that the useless information is not streamed later on. gcc/ChangeLog: 2023-03-22 Martin Jambor PR ipa/108959 * ipa-sra.cc (zap_useless_ipcp_results): New function. (process_isra_node_results): Call it. gcc/testsuite/ChangeLog: 2023-03-17 Martin Jambor PR ipa/108959 * gcc.dg/ipa/pr108959.c: New test.
[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905 since r13-5681-ge8109bd87766be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Martin Jambor --- Fixed.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #9 from CVS Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:ddb0f66e6c1e846bdc217075c9a770bfd0b01970 commit r13-7012-gddb0f66e6c1e846bdc217075c9a770bfd0b01970 Author: John David Anglin Date: Wed Apr 5 14:44:54 2023 + Add assember CFI directives to millicode division and remainder routines. The millicode division and remainder routines trap division by zero. The unwinder needs these directives to unwind divide by zero traps. 2023-04-05 John David Anglin libgcc/ChangeLog: PR target/109374 * config/pa/milli64.S (RETURN_COLUMN): Define. ($$divI): Add CFI directives. ($$divU): Likewise. ($$remI): Likewise. ($$remU): Likewise.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #10 from John David Anglin --- Fixed on trunk.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #11 from Eric Botcazou --- Nice work!
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #12 from dave.anglin at bell dot net --- On 2023-04-05 10:56 a.m., ebotcazou at gcc dot gnu.org wrote: > Nice work! Your comments were accurate and very helpful. Thanks, dave
[Bug middle-end/108892] [13 Regression] unable to generate reloads for at -Og on riscv64 since r13-4907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108892 --- Comment #6 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:4a45f5d6a9b53f7f5446dee47e25b07d413bb7eb commit r13-7013-g4a45f5d6a9b53f7f5446dee47e25b07d413bb7eb Author: Jeff Law Date: Wed Apr 5 09:16:29 2023 -0600 [RFA][Bug target/108892 ][13 regression] Force re-recognition after changing RTL structure of an insn So as mentioned in the PR the underlying issue here is combine changes the form of an existing insn, but fails to force re-recognition. As a result other parts of the compiler blow up. > /* Temporarily replace the set's source with the > contents of the REG_EQUAL note. The insn will > be deleted or recognized by try_combine. */ > rtx orig_src = SET_SRC (set); rtx orig_dest = SET_DEST (set); if (GET_CODE (SET_DEST (set)) == ZERO_EXTRACT) > SET_DEST (set) = XEXP (SET_DEST (set), 0); > SET_SRC (set) = note; > i2mod = temp; > i2mod_old_rhs = copy_rtx (orig_src); > i2mod_new_rhs = copy_rtx (note); > next = try_combine (insn, i2mod, NULL, NULL, > &new_direct_jump_p, last_combined_insn); > i2mod = NULL; > if (next) > { > statistics_counter_event (cfun, "insn-with-note combine", 1); > goto retry; > } SET_SRC (set) = orig_src; > SET_DEST (set) = orig_dest; This code replaces the SET_SRC of an insn in the RTL stream with the contents of a REG_EQUAL note. So given an insn like this: > (insn 122 117 127 2 (set (reg:DI 157 [ _46 ]) > (ior:DI (reg:DI 200) > (reg:DI 251))) "j.c":14:5 -1 > (expr_list:REG_EQUAL (const_int 25769803782 [0x60006]) > (nil))) It replaces the (ior ...) with a (const_int ...). The resulting insn is passed to try_combine which will try to recognize it, then use it in a combination attempt. Recognition succeeds with the special define_insn_and_split pattern in the risc-v backend resulting in: > (insn 122 117 127 2 (set (reg:DI 157 [ _46 ]) > (const_int 25769803782 [0x60006])) "j.c":14:5 177 {*mvconst_internal} > (expr_list:REG_EQUAL (const_int 25769803782 [0x60006]) > (nil))) This is as-expected. Now assume we were unable to combine anything, so try_combine returns NULL_RTX. The quoted code above restores SET_SRC (and SET_DEST) resulting in: > (insn 122 117 127 2 (set (reg:DI 157 [ _46 ]) > (ior:DI (reg:DI 200) > (reg:DI 251))) "j.c":14:5 177 {*mvconst_internal} > (expr_list:REG_EQUAL (const_int 25769803782 [0x60006]) > (nil))) But this doesn't get re-recognized and we ICE later in LRA. The fix is trivial, reset the INSN_CODE to force re-recognition in the case where try_combine fails. PR target/108892 gcc/ * combine.cc (combine_instructions): Force re-recognition when after restoring the body of an insn to its original form. gcc/testsuite/ * gcc.c-torture/compile/pr108892.c: New test.
[Bug middle-end/108892] [13 Regression] unable to generate reloads for at -Og on riscv64 since r13-4907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108892 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- Fixed on the trunk. Currently no plans to backport as this hasn't been seen on any release branches.
[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #6 from John David Anglin --- Fails consistently with timeout on hppa-unknown-linux-gnu. Increasing timeout doesn't help. dave@mx3210:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ time ./poll.exe wait_for(0s): 1098ns for 169420 calls, avg 59.0255ns per call wait_until(system_clock minimum): 4394ns for 169420 calls, avg 236.102ns per call wait_until(steady_clock minimum): 5492ns for 169420 calls, avg 295.127ns per call wait_until(system_clock epoch): 1695216533549ns for 169420 calls, avg 1.0006e+07ns per call wait_until(steady_clock epoch: 1694205876189ns for 169420 calls, avg 1e+07ns per call wait_for when ready: 0ns for 169420 calls, avg 0ns per call /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/future/members/poll.cc:129: int main(): Assertion 'wait_for_0 < (ready * 30)' failed. Aborted (core dumped) real56m29.632s user0m5.355s sys 0m8.722s
[Bug c++/109421] New: Compilation takes a long time for struct that contains a large default-initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109421 Bug ID: 109421 Summary: Compilation takes a long time for struct that contains a large default-initialized array Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ejakobs at boerboeltrading dot com Target Milestone: --- This is similar to #59659, but is still a problem in GCC 11.2.1 and GCC 10.2.1. The following code takes a very long time to compile with -O3 enabled: #include #ifndef SIZE #define SIZE 10 #endif struct S { int a; }; struct T { std::vector arr[SIZE]{}; // remove the default-initializer {} to compile fast }; int main(int argc, char** argv) { T t; for (int i=0; i
[Bug c++/109421] Compilation takes a long time for struct that contains a large default-initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109421 --- Comment #1 from Andrew Pinski --- Looks to be fixed with GCC 12.1.0 .
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385 Andrew Pinski changed: What|Removed |Added CC||ejakobs at boerboeltrading dot com --- Comment #18 from Andrew Pinski --- *** Bug 109421 has been marked as a duplicate of this bug. ***
[Bug c++/109421] Compilation takes a long time for struct that contains a large default-initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109421 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 92385. *** This bug has been marked as a duplicate of bug 92385 ***
[Bug c++/109422] New: wrong depth used for template parameter mangling for lambdas in function signatures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109422 Bug ID: 109422 Summary: wrong depth used for template parameter mangling for lambdas in function signatures Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: richard-gccbugzilla at metafoo dot co.uk Target Milestone: --- Testcase: struct C { template void f(decltype([](T, auto) { return 0; })) {} }; void g() { C().f({}); } GCC mangles f as _ZN1C1fIiEEvDTtlNS_UlT_T_E_EEE -- note that this is mangling / numbering the lambda directly within C, which is not permitted by http://itanium-cxx-abi.github.io/cxx-abi/abi.html#closure-types but seems like the best choice (see https://github.com/itanium-cxx-abi/cxx-abi/issues/165). But the mangling of the as T_T_ is definitely wrong -- two different template parameters should not be mangled the same. This should instead be mangled as T_TL__ under https://github.com/itanium-cxx-abi/cxx-abi/issues/31#issuecomment-528122117
[Bug c++/109422] wrong depth used for template parameter mangling for lambdas in function signatures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109422 --- Comment #1 from Richard Smith --- > This should instead be mangled as T_TL__ Sorry, that's wrong; the rule we ended up with would mangle this as T_TL0__.
[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |13.0 Priority|P3 |P1 Summary|[13 Regression] ICE on |[13 Regression] ICE on |valid code at -O3 on|valid code at -O3 on |x86_64-linux-gnu: |x86_64-linux-gnu: |Segmentation fault |Segmentation fault since ||r13-6945 CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r13-6945-g429a7a88438cc80e
[Bug modula2/109423] New: cc1gm2 ICE if an INCL or EXCL is performced on an unknown set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109423 Bug ID: 109423 Summary: cc1gm2 ICE if an INCL or EXCL is performced on an unknown set Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- cc1gm2 ICE if an INCL or EXCL is performced on an unknown set. For example: MODULE setunknown2 ; BEGIN INCL (unknownSet, unknownVariable) END setunknown2.
[Bug libstdc++/88508] std::bad_cast in std::basic_ostringstream.oss.fill()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508 Frank Heckenbach changed: What|Removed |Added CC||f.heckenb...@fh-soft.de --- Comment #2 from Frank Heckenbach --- According to https://stackoverflow.com/questions/57406448/canot-read-char8-t-from-basic-stringstreamchar8-t this seems to be the same issue, so I'm not filing a new bug, just adding a comment. Apparently this is no GCC bug, but according to the standard. IMHO this shows how ridiculous the current UTF-8 support is. A common I/O manipulator (setw) fails with an inscrutable error (bad cast, what cast?) which is even suppressed by default, unless enabled with o.exceptions, so by the default the stream just mysteriously stops working. And all that because the library doesn't know what the space character is in UTF-8. Just ranting, I know, but it's silly. % cat test.cpp #include #include #include int main () { std::basic_ostringstream o; o.exceptions (std::ifstream::badbit); o << std::setw (1) << u8""; } % g++ -std=c++20 -Wall -Wextra -o test test.cpp % ./test terminate called after throwing an instance of 'std::bad_cast' what(): std::bad_cast Aborted
[Bug target/108947] [13 Regression] wrong code with -O2 -fno-forward-propagate and vector compare on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108947 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #3 from Sam James --- Note that's substantial discussion (including a patch) in dupe PR109040.
[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/piperma | |il/gcc-patches/2023-Februar | |y/611684.html | Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #22 from Andrew Pinski --- I am no longer working on this.
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 Andrew Pinski changed: What|Removed |Added Attachment #40185|0 |1 is obsolete|| --- Comment #27 from Andrew Pinski --- Created attachment 54813 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54813&action=edit Set of patches for moving part of the minmax_replacement to match This is my current set of patches for moving minmax_replacement to match.
[Bug tree-optimization/101024] Missed min expression at phiopt1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101024 --- Comment #6 from Andrew Pinski --- Part of this is in the patch set in bug 25290 comment # 27 patch set. Mostly the "c ? min/max : min/max" part, I still need to implement the "c ? min : d" part.
[Bug tree-optimization/109424] New: ~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109424 Bug ID: 109424 Summary: ~ Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization Assignee: pinskia at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Take: ``` int f(int x, int y) { int t = ((x > y) ? x : y); return ~t; } int f1(int x, int y) { return ~((x > y) ? x : y); } ``` You would assume GCC produce the same code for both, but nope, the first f is worse. The reason why is GCC decides to move the ~ into the ?: operator making the code worse. fold does this "optimization" but nothing undones it, phi-opt undones it for casts in some but not all cases.
[Bug tree-optimization/109424] ~((x > y) ? x : y) produces two not instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109424 Andrew Pinski changed: What|Removed |Added Summary|~ |~((x > y) ? x : y) produces ||two not instructions --- Comment #1 from Andrew Pinski --- > You would assume GCC produce the same code for both, but nope, the first f is > worse. Sorry f1 is worse.
[Bug tree-optimization/109424] ~((x > y) ? x : y) produces two not instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109424 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96694 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-04-05 --- Comment #2 from Andrew Pinski --- I noticed this while looking into PR 96694 .
[Bug c++/109425] New: mismatched argument pack lengths while expanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 Bug ID: 109425 Summary: mismatched argument pack lengths while expanding Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: h2+bugs at fsfe dot org Target Milestone: --- The following snippet is rejected by GCC10, GCC11 and GCC12: ```cpp #include template concept weakly_eq_comparable = requires (T1 t1, T2 t2) { { t1 == t2 } -> std::convertible_to; }; template struct my_tuple { template requires ((sizeof...(Ts) == sizeof...(T2s)) && (weakly_eq_comparable && ...)) friend bool operator==(my_tuple const & lhs, my_tuple const & rhs) { return true; } }; int main() { my_tuple m1; } ``` See also: https://godbolt.org/z/3eEjT589o The error is: ``` : In instantiation of 'struct my_tuple': :20:26: required from here :11:86: error: mismatched argument pack lengths while expanding 'weakly_eq_comparable' 11 | requires ((sizeof...(Ts) == sizeof...(T2s)) && (weakly_eq_comparable && ...)) | ~~^~~~ Compiler returned: 1 ``` Clang>=13 accepts this code. I am not sure if this is related to #107853, because I am not getting an ICE, but it seems like the problems (or their solutions) could be related. Thank you!
[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 --- Comment #2 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #1) > Started with r13-6945-g429a7a88438cc80e I've run into this before. _54 = _22 is processed, and we cache _22 as a dependency fo _54. then we do some propagation and rewrite this statement as _54 = 3 When we look at _54 later, it still shows the cached dependency as _22, but there is no longer a _22 in the IL. We are trapping because may_recompute_p is expecting the dependency to be up to date. The fix is to check if it is in the FREE_LIST or not as well. Patch in testing. diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc index 5f4313b27dd..2a575c006fc 100644 --- a/gcc/gimple-range-gori.cc +++ b/gcc/gimple-range-gori.cc @@ -1314,7 +1314,7 @@ gori_compute::may_recompute_p (tree name, basic_block bb, int depth) tree dep2 = depend2 (name); // If the first dependency is not set, there is no recomputation. - if (!dep1) + if (!dep1 || SSA_NAME_IN_FREE_LIST (dep1)) return false;
[Bug c++/109425] mismatched argument pack lengths while expanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Seems to have been fixed by r13-4876-gbd1fc4a219d8c0 commit bd1fc4a219d8c0fad0ec41002e895b49e384c1c2 Author: Patrick Palka Date: Fri Dec 23 09:18:37 2022 -0500 c++: template friend with variadic constraints [PR107853] so it is related to bug 107853. In fact I think we can say it's a dup. *** This bug has been marked as a duplicate of bug 107853 ***
[Bug c++/107853] [10/11/12 Regression] variadic template with a variadic template friend with a requires of fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853 Marek Polacek changed: What|Removed |Added CC||h2+bugs at fsfe dot org --- Comment #8 from Marek Polacek --- *** Bug 109425 has been marked as a duplicate of this bug. ***
[Bug fortran/104312] ICE with -ff2c in fold_convert_loc, at fold-const.cc:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104312 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Last reconfirmed||2023-04-05 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. The issue may be clearer if the testcase is extended as follows: function f() real, pointer :: f, e real, target :: a(2) f => a(1) return entry e() e => a(2) end so that one gets (before the traceback): pr104312-zz.f90:5:8: 5 | return |1 Error: pointer value used where a floating-point was expected pr104312-zz.f90:8:3: 8 | end | 1 Error: pointer value used where a floating-point was expected pr104312-zz.f90:1:0: 1 | function f() | internal compiler error: in fold_convert_loc, at fold-const.cc:2504 Setting a breakpoint in gfc_generate_return and checking the fndecl, one sees that it is wrong for -ff2c.
[Bug modula2/109423] cc1gm2 ICE if an INCL or EXCL is performced on an unknown set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109423 --- Comment #1 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:1bd13193fab77a19da323974aec876f0fc1817ee commit r13-7019-g1bd13193fab77a19da323974aec876f0fc1817ee Author: Gaius Mulley Date: Wed Apr 5 23:07:46 2023 +0100 PR modula2/109423 cc1gm2 ICE if an INCL or EXCL is performed on an unknown set This patch fixes an ICE if attempting to INCL or EXCL on an unknown set. The fix was to correct an error format string. Also included in the patch are patches to remove unused variables. The patch also marks a variable as written in BuildAdr. gcc/m2/ChangeLog: PR modula2/109423 * gm2-compiler/M2Base.def (Unbounded): Remove. * gm2-compiler/M2Error.def (ErrorAbort0): Add noreturn attribute. * gm2-compiler/M2Quads.mod (BuildInclProcedure): Correct error format string. (BuildExceptProcedure): Correct error format string. (BuildAdrFunction): Call PutWriteQuad when taking the address of a variable. * gm2-libs-ch/SysExceptions.c (_M2_SysExceptions_init): Add parameters. * gm2-libs-ch/wrapc.c (_M2_wrapc_init): Add parameters. * gm2-libs/DynamicStrings.mod (DumpStringInfo): Remove t. (PopAllocationExemption): Remove f. * gm2-libs/FIO.mod (BufferedWrite): Remove result. * gm2-libs/FormatStrings.mod (Copy): Remove endpos and afterperc. (HandlePercent): Remove result. * gm2-libs/Indexing.mod (RemoveIndiceFromIndex): Remove k. * gm2-libs/M2Dependent.mod (CreateModule): Remove p0 and p1. (DumpModuleData): Remove mptr. (ConstructModules): Remove nulp. * gm2-libs/RTExceptions.mod (PopHandler): Remove i. * gm2-libs/RTint.mod (Listen): Remove b4s, b4m, afs and afm. * gm2-libs/SFIO.mod (ReadS): Remove c. * gm2-libs/StringConvert.mod (doDecimalPlaces): Remove whole and fraction. gcc/testsuite/ChangeLog: * gm2/pim/fail/setunknown.mod: New test. PR modula2/109423 * gm2/pim/fail/setunknown2.mod: New test. Signed-off-by: Gaius Mulley
[Bug modula2/109423] cc1gm2 ICE if an INCL or EXCL is performced on an unknown set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109423 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-04-05 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Gaius Mulley --- The bugfix was a format specifier in M2Quads.mod:BuildInclProcedure and BuildExclProcedure. The patch above include these fixes and also removes unused variables.
[Bug modula2/109423] cc1gm2 ICE if an INCL or EXCL is performced on an unknown set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109423 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Gaius Mulley --- Closing now the patch has been applied.
[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 Chip Kerchner changed: What|Removed |Added CC||chip.kerchner at ibm dot com --- Comment #3 from Chip Kerchner --- This is showing up in some of the binaries generated by Eigen (with GCC13).
[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 --- Comment #4 from Chip Kerchner --- It shows up as a rounding difference on BE machines.
[Bug target/109399] RISC-V: RVV VSETVL PASS backward demand fusiton bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109399 JuzheZhong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from JuzheZhong --- fixed
[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 --- Comment #5 from Michael Meissner --- Created attachment 54814 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54814&action=edit Test case This is test case that shows the generation of fmaddfp and fnmsubfp.
[Bug c++/109425] mismatched argument pack lengths while expanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 --- Comment #2 from Hannes Hauswedell --- Thanks for the quick reply, and nice that it is already fixed for 13! I assume this will not be backported? It wouldn't be a huge problem, because it is possible to workaround with non-friend operators.
[Bug c++/109426] New: Gcc runs into Infinite loop, when resolving templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 Bug ID: 109426 Summary: Gcc runs into Infinite loop, when resolving templates Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zhonghao at pku dot org.cn Target Milestone: --- The code is as follows: typedef struct astruct_d { void *data; } astruct; /* Generate a whole bunch of unique fake mallocs, this keeps the vartrack dump simpler to understand (all the "size" arguments have a unique name). */ #define DE0(X) \ void *malloc##X (unsigned long size##X); #define DE1(X) \ DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \ DE0(X##5) DE0(X##6) DE0(X##7) DE0(X##8) DE0(X##9) #define DE2(X) \ DE1(X##0) DE1(X##1) DE1(X##2) DE1(X##3) DE1(X##4) \ DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9) #define DE3(X) \ DE2(X##0) DE2(X##1) DE2(X##2) DE2(X##3) DE2(X##4) \ DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9) #define DE4(X) \ DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \ DE3(X##5) DE3(X##6) DE3(X##7) DE3(X##8) DE3(X##9) DE4(0) #undef DE0 #undef DE1 #undef DE2 #undef DE3 #undef DE4 void foo (void) { /* Now call all those mallocs and generate a series of variables while at it. */ #define DE0(X) \ astruct *A##X = (astruct *) malloc##X(sizeof (astruct)); #define DE1(X) \ DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \ DE0(X##5) DE0(X##6) DE0(X##7) DE0(X##8) DE0(X##9) #define DE2(X) \ DE1(X##0) DE1(X##1) DE1(X##2) DE1(X##3) DE1(X##4) \ DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9) #define DE3(X) \ DE2(X##0) DE2(X##1) DE2(X##2) DE2(X##3) DE2(X##4) \ DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9) #define DE4(X) \ DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \ DE3(X##5) DE3(X##6) DE3(X##7) DE3(X##8) DE3(X##9) DE4(0) DE4(1) } GCC runs into an infinite loop: code0.c:35:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 35 | astruct *A##X = (astruct *) malloc##X(sizeof (astruct)); | ^ code0.c:37:32: note: in expansion of macro ‘DE0’ 37 | DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \ |^~~ code0.c:41:42: note: in expansion of macro ‘DE1’ 41 | DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9) | ^~~ code0.c:44:2: note: in expansion of macro ‘DE2’ 44 | DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9) | ^~~ code0.c:46:22: note: in expansion of macro ‘DE3’ 46 | DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \ | ^~~ code0.c:49:1: note: in expansion of macro ‘DE4’ 49 | DE4(1) | ^~~
[Bug c++/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 Andrew Pinski changed: What|Removed |Added Summary|Gcc runs into Infinite |Gcc runs into Infinite loop |loop, when resolving| |templates | --- Comment #1 from Andrew Pinski --- The code example you provided does not have any templates ...
[Bug c/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 Andrew Pinski changed: What|Removed |Added Component|c++ |c --- Comment #2 from Andrew Pinski --- There is no infinite loop and the code finally completes. You are causing an warnings of over 2x warning messages with the macros. This will be slow. I don't run into an infinite loop at all on the trunk.
[Bug testsuite/108899] [13 Regression] ERROR: can't rename to "saved-unsupported": command already exists on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108899 --- Comment #10 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:673a2a6445a79bcce5ba433d6bbec4b99a1bc7c6 commit r13-7021-g673a2a6445a79bcce5ba433d6bbec4b99a1bc7c6 Author: Alexandre Oliva Date: Wed Apr 5 11:27:28 2023 -0300 testsuite: fix proc unsupported overriding in modules.exp [PR108899] The overrider of proc unsupported in modules.exp had two problems reported by Thomas Schwinge, even after Jakub Jelínek's fix: - it remained in effect while running other dejagnu testsets - it didn't quote correctly the argument list passed to it, which caused test names to be surrounded by curly braces, as in: UNSUPPORTED: {...} This patch fixes both issues, obsoleting and reverting Jakub's change, by dropping the overrider and renaming the saved proc back, and by using uplevel's argument list splicing. Co-authored-by: Thomas Schwinge for gcc/testsuite/ChangeLog PR testsuite/108899 * g++.dg/modules/modules.exp (unsupported): Drop renaming. Fix quoting.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-04-06 --- Comment #2 from Jerry DeLisle --- I am using my copy of the F2018 standard. "13.8.1.2 The Tn edit descriptor indicates that the transmission of the next character to or from a record is to occur at the nth character position of the record, relative to the left tab limit. This position can be in either direction from the current position." Currently we do this: 1234567890123 1234 0123 1234 0123 We should do this: 1234567890123 1234 0123 1234 0123 "13.5 (3) During formatted stream output, processing of an A edit descriptor can cause file positioning to occur (13.7.4)." I am not finding anything that says file positioning is not allowed. The above is just elaborating different ways that an A edit descriptor affects the positioning. Positioning is always done no matter what with the T specifier. Regardless, I do need to fix this.
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 --- Comment #8 from jiawei --- Thank you for this fix, I neglected to confirm the format, sorry for that.
[Bug tree-optimization/109427] New: Wrong param description in param.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109427 Bug ID: 109427 Summary: Wrong param description in param.opt Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fxue at os dot amperecomputing.com Target Milestone: --- -param=vect-induction-float= Common Joined UInteger Var(param_vect_induction_float) Init(1) IntegerRage(0, 1) Param Optimization ^^^
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #2) > I am using my copy of the F2018 standard. > > "13.8.1.2 The Tn edit descriptor indicates that the transmission of the next > character to or from a record is to occur at the nth character position of > the record, relative to the left tab limit. This position can be in either > direction from the current position." > > Currently we do this: > > 1234567890123 > 1234 0123 > 1234 0123 > > We should do this: > > 1234567890123 > 1234 0123 > 1234 0123 > > "13.5 (3) During formatted stream output, processing of an A edit descriptor > can cause file positioning to occur (13.7.4)." > > I am not finding anything that says file positioning is not allowed. The > above is just elaborating different ways that an A edit descriptor affects > the positioning. Positioning is always done no matter what with the T > specifier. > > Regardless, I do need to fix this. Yes, there is a bug. The A edit descriptor and whether or not it does file positioning is not relevant. The relevant words from F2018 are 13.8.1.2 T, TL, and TR editing The left tab limit affects file positioning by the T and TL edit descriptors. Immediately prior to nonchild data transfer (12.6.4.8.3), the left tab limit becomes defined as the character position of the current record or the current position of the stream file. If, during data transfer, the file is positioned to another record, the left tab limit becomes defined as character position one of that record. with write(fd, "(a)") "1234567890123" write(fd, "(a, t10, a)") "1234", "0123" ! A-descriptor, file positioning the left tab limit for the 2nd write is established before data transfer to position 1. The 'T10' edit descriptor is relative to that position. The write of "1234" in the 2nd write might place the character position to 5, but it does not update the left tab limit because the write() is not positioned to a new record.
[Bug tree-optimization/109427] param=vect-induction-float= has a typo for IntegerRange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109427 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-04-06 Summary|Wrong param description in |param=vect-induction-float= |params.opt |has a typo for IntegerRange Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Oh there is a small typo. Let me fix it. I looked into the awk files before and yes they don't detect invalid attributes.
[Bug tree-optimization/109427] param=vect-induction-float= has a typo for IntegerRange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109427 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:0f816116356fec32e3a3a2fb5af790a0438c5da4 commit r13-7022-g0f816116356fec32e3a3a2fb5af790a0438c5da4 Author: Andrew Pinski Date: Wed Apr 5 21:13:00 2023 -0700 Fix typo in -param=vect-induction-float= attributes There was a typo in the attributes of the option -param=vect-induction-float= for IntegerRange. This fixes that typo. Committed as obvious after a build/test. gcc/ChangeLog: PR tree-optimization/109427 * params.opt (-param=vect-induction-float=): Fix option attribute typo for IntegerRange.
[Bug tree-optimization/109427] param=vect-induction-float= has a typo for IntegerRange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109427 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:6c5d6ed689d24418a3bc0647ab34a7ab017d7030 commit r12-9388-g6c5d6ed689d24418a3bc0647ab34a7ab017d7030 Author: Andrew Pinski Date: Wed Apr 5 21:13:00 2023 -0700 Fix typo in -param=vect-induction-float= attributes There was a typo in the attributes of the option -param=vect-induction-float= for IntegerRange. This fixes that typo. Committed to GCC 12 branch as obvious after a build/test. gcc/ChangeLog: PR tree-optimization/109427 * params.opt (-param=vect-induction-float=): Fix option attribute typo for IntegerRange. (cherry picked from commit 0f816116356fec32e3a3a2fb5af790a0438c5da4)
[Bug tree-optimization/109427] param=vect-induction-float= has a typo for IntegerRange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109427 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.3 Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug lto/109428] New: GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 Bug ID: 109428 Summary: GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: chluo at cse dot cuhk.edu.hk CC: marxin at gcc dot gnu.org Target Milestone: --- GCC reused zlib 1.2.11. A heap overflow vulnerability (https://github.com/madler/zlib/issues/723) was recently found in zlib through version 1.2.12 and was patched in the latest version of zlib in https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166bece1. The patch basically inserted an additional check at the if condition and does not influence any functionalities. We found that in the current version of GCC (0f816116356fec32e3a3a2fb5af790a0438c5da4), the simple patch has still not been propagated yet. Since the vulnerability in zlib also impacts GCC and it is publically known for a while, we believe GCC should apply the patch ASAP.
[Bug c/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||xry111 at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #2) > There is no infinite loop and the code finally completes. > > You are causing an warnings of over 2x warning messages with the macros. > This will be slow. Looks like it's slow not only because of the warnings. The preprocessed code is 1.6M and it's slow even with -w (62.76s with 12.2.0). > > I don't run into an infinite loop at all on the trunk. Anyway this is INVALID. You cannot assume any compiler able to compile such a compiler bomb efficiently.
[Bug other/105404] new version of zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 Andrew Pinski changed: What|Removed |Added CC||chluo at cse dot cuhk.edu.hk --- Comment #9 from Andrew Pinski --- *** Bug 109428 has been marked as a duplicate of this bug. ***
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 105404 ***
[Bug other/105404] new version of zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 --- Comment #10 from Andrew Pinski --- Note GCC does not call inflateGetHeader so it is not affected by CVE-2022-37434.
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 chluo at cse dot cuhk.edu.hk changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #2 from chluo at cse dot cuhk.edu.hk --- Thank you for your quick update! The commit might just list one approach to exploit the bug in **inflate()** function. I am not sure if there are other ways to reach there but the buggy code is definitely a hazard. Anyway, it is good to align with the patched version of upstream code zlib. It would not take effort since the patch is very easy to apply and verify.
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Still a dup of bug 105404 because we have not updated the sources yet for either CVEs. *** This bug has been marked as a duplicate of bug 105404 ***
[Bug other/105404] new version of zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 --- Comment #11 from Andrew Pinski --- *** Bug 109428 has been marked as a duplicate of this bug. ***
[Bug c/85696] OpenMP with variably modified and default(none) won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696 zhonghao at pku dot org.cn changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #11 from zhonghao at pku dot org.cn --- Is this bug really fixed? I tried the latest version, but it is still rejected: :1:28: error: use of parameter outside function body before ']' token 1 | void foo(int n, int a[][n]) |^ : In function 'void foo(...)': :4:9: error: 'a' was not declared in this scope 4 | a[23][0] = 42; | ^ Compiler returned: 1
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 --- Comment #4 from Andrew Pinski --- (In reply to chluo from comment #2) > Thank you for your quick update! The commit might just list one approach to > exploit the bug in **inflate()** function. I am not sure if there are other > ways to reach there but the buggy code is definitely a hazard. > Anyway, it is good to align with the patched version of upstream code zlib. > It would not take effort since the patch is very easy to apply and verify. Also the only way hit the bug is if state->head is non-null. the only place which sets state->head to non-null is in inflateGetHeader since state is an opaque object outside of zlib even. So if someone modifies the state from outside of zlib, then there might be other issues. Anyways GCC does not modify state either nor calls inflateGetHeader so it would not hit this bug.
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 --- Comment #5 from chluo at cse dot cuhk.edu.hk --- OK, also thanks for the kind explanations!
[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495 zhonghao at pku dot org.cn changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #7 from zhonghao at pku dot org.cn --- I tried to compile the sample code with the latest gcc. struct __attribute__ ((aligned (8))) s { char c; }; _Static_assert (_Alignof (struct s) >= 8, "wrong alignment"); However, it does not compile. Is this a regression?
[Bug c/85696] OpenMP with variably modified and default(none) won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696 --- Comment #12 from Jakub Jelinek --- If you are trying to compile C code which isn't valid C++ by C++, then such an error is expected.