[Bug ipa/109817] [14 Regression] internal error in ICF pass on Ada interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109817 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking --- Comment #2 from Andrew Pinski --- gcc_checking_assert (i->fixed_offset || i->virtual_offset_p || i->indirect_offset); That assert was added in GCC 11: r11-4329-g67f3791f7d1332 So this might be an older regression but it is definitely a regression.
[Bug ipa/109817] [14 Regression] internal error in ICF pass on Ada interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109817 Andrew Pinski changed: What|Removed |Added Summary|internal error in ICF pass |[14 Regression] internal |on Ada interfaces |error in ICF pass on Ada ||interfaces Target Milestone|--- |14.0 CC||pinskia at gcc dot gnu.org Keywords||ice-on-valid-code
[Bug tree-optimization/87332] [meta-bug] Issues related to Identical Code Folding (ICF) and Tail Merging (-ftree-tail-merge)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87332 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-03-10 --- Comment #1 from Andrew Pinski --- .
[Bug tree-optimization/97333] [meta-bug] [gimple_can_duplicate_bb_p == false, tree-ssa-threadupdate] ICE in duplicate_block, at cfghooks.c:1093
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97333 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #8 from Andrew Pinski --- Note if you have gimple_can_duplicate_bb_p return false always, you need to disable -Werror as GCC's (target library) sources depend on some jump threading so some warnings don't show up.
[Bug tree-optimization/90134] ICE in duplicate_eh_regions_1, at except.c:557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90134 Andrew Pinski changed: What|Removed |Added Known to work|12.1.0 | Keywords||EH --- Comment #5 from Andrew Pinski --- Note in GCC 12+, you also need -fno-delete-dead-exceptions to get the ICE.
[Bug tree-optimization/68761] -floop-interchange internal compiler error: in create_tmp_var, at gimple-expr.c:519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68761 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Target Milestone|--- |6.0 Status|NEW |RESOLVED --- Comment #6 from Andrew Pinski --- r6-3016-gd6bb5ccfebfc29 basically removed the option for graphite usage. It was added back for the traditional loop based interchange in GCC 8 (r8-5164-gfbdec14e80e939 ). So closing as won't fix.
[Bug c++/90659] [11/12/13 Regression] ICE in tree_to_uhwi, at tree.h:4352/7291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90659 Jeffrey A. Law changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE |ICE in tree_to_uhwi, at |in tree_to_uhwi, at |tree.h:4352/7291|tree.h:4352/7291 CC||law at gcc dot gnu.org --- Comment #14 from Jeffrey A. Law --- Same as c#13. Removing gcc-14 regression marker.
[Bug target/90204] [11 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 Jeffrey A. Law changed: What|Removed |Added Summary|[11/12/13/14 Regression] C |[11 Regression] C code is |code is optimized worse |optimized worse than C++ |than C++| CC||law at gcc dot gnu.org --- Comment #23 from Jeffrey A. Law --- Per c#21 and c#22.
[Bug tree-optimization/56829] Feature request: "generic" builtin to support control flow in vectorized code ("movemask", "vec_any/all_*")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56829 --- Comment #4 from Andrew Pinski --- Note GCC 14 adds the ability to auto-vectorize early exist loops. I am not sure if this helps this issue here though.
[Bug tree-optimization/89049] [11 Regression] Unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Summary|[11/12/13/14 Regression]|[11 Regression] Unexpected |Unexpected vectorization|vectorization --- Comment #20 from Jeffrey A. Law --- Per c#18.
[Bug tree-optimization/20496] "-1" is inconsistently printed in tree dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20496 --- Comment #4 from Andrew Pinski --- Oh the TREE_OVERFLOW part was fixed much earlier than that though.
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 --- Comment #5 from kugan at gcc dot gnu.org --- -O3 -fno-tree-vectorize and -O3 -fno-tree-vrp works. I looked at the ever dump and it is not doing anything suspicious. Looks like range_info usage in vectoriser is causing the problem.
[Bug tree-optimization/20496] "-1" is inconsistently printed in tree dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20496 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Known to work|4.7.1 |5.1.0 Status|NEW |RESOLVED Target Milestone|--- |5.0 --- Comment #3 from Andrew Pinski --- Fixed by r5-424-g807e902eea17f3 . Which does: print_dec (node, file, TYPE_SIGN (TREE_TYPE (node))); always instead of dependent on the TREE_INT_CST_HIGH/TREE_INT_CST_LOW parts being different.
[Bug tree-optimization/97410] missing -Warray-bounds with constant index from second array element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97410 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Ever confirmed|0 |1 Last reconfirmed||2024-03-10 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- q_6 = [i_5(D)]; if ( == q_6) This should have been folded into just `i_5(D) == 0` but that does not help here. Anyways confirmed.
[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624 --- Comment #8 from Andrew Pinski --- For aarch64, it has been since GCC 13 though for the testcase in comment #6 .
[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624 Andrew Pinski changed: What|Removed |Added Known to work||9.1.0 --- Comment #7 from Andrew Pinski --- Looks like all of the testcases vectorize since GCC 11 as far as I can tell.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #12 from Jeffrey A. Law --- Aren't we compiling for PA2.0? If so, shouldn't we have a full 14 bit offset support, even when a load/store hits the FP register file (feel free to correct me if I'm wrong, it's only been 20 years since I worked on this stuff ;-) So I don't really see why the offsets are an issue here. If we were compiling for PA1.0/PA1.1, then yes, there's a real issue, but it's with allowing the larger offsets as a legitimate address. That's lying to the compiler, reload in particular and as I said, it's ultimately going to backfire -- even with the workaround since you're going to have DImode loads/stores to the FP register file due to xmpyu or potentially even memcpy and friends. I already tried what you're doing years ago. It's doomed to failure. You might think this is a reload problem. But I'm far from convinced. It smells much more like a PA backend issue to me.
[Bug tree-optimization/103116] SLP vectoriser fails to peel for gaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103116 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.4
[Bug tree-optimization/81189] Out of bounds memory access introduced by the vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81189 Andrew Pinski changed: What|Removed |Added Known to work||8.1.0 Target Milestone|--- |8.0 Known to fail||7.5.0 --- Comment #2 from Andrew Pinski --- Looks like it was fixed in GCC 8.1.0 in the end ...
[Bug rtl-optimization/113533] Code generation regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533 --- Comment #17 from Oleg Endo --- (In reply to Jeffrey A. Law from comment #16) > Note that Jakub recently twiddled fwprop to throttle it back a little. As a > result the regressions seen in this BZ are no longer an issue. I'm going to > remove the regression marker. > > Roger/Oleg, if y'all are going to continue on the costing work, we may want > to keep this open. Otherwise I wouldn't lose any sleep if we just closed it. Thanks for the update on this, Jeff. Even if the regression disappeared, the cost calculations for memory accesses are clearly wrong in that spot. So I'd like to at least fix the core issues. Just haven't had time to test it more thoroughly for any side-effects yet.
[Bug tree-optimization/97796] internal compiler error: Segmentation fault 0xb2ed5f crash_signal - graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97796 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #2 from Andrew Pinski --- No feedback in over 3 years so closing as works for me.
[Bug c/105150] [11 Regression] ICE with -Ofast: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105150 --- Comment #14 from Andrew Pinski --- *** Bug 87886 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/87886] ICE in format_helper, at real.h:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87886 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Andrew Pinski --- Dup of bug 105150. *** This bug has been marked as a duplicate of bug 105150 ***
[Bug rtl-optimization/113533] Code generation regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533 Jeffrey A. Law changed: What|Removed |Added Summary|[14 Regression] Code|Code generation regression |generation regression after |after change for pr111267 |change for pr111267 | --- Comment #16 from Jeffrey A. Law --- Note that Jakub recently twiddled fwprop to throttle it back a little. As a result the regressions seen in this BZ are no longer an issue. I'm going to remove the regression marker. Roger/Oleg, if y'all are going to continue on the costing work, we may want to keep this open. Otherwise I wouldn't lose any sleep if we just closed it.
[Bug tree-optimization/114268] [14 Regression] 5% exec time regression in 454.calculix on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114268 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug libgcc/110956] [13/14 regression] gcc_assert is hit at gcc-13.2.0/libgcc/unwind-dw2-fde.c#L291 with some special library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||law at gcc dot gnu.org --- Comment #14 from Jeffrey A. Law --- I'd think the right thing to do is close this one and track in the newer bug. It's not clear they're actually the same underlying problem, even though they have the same failure signature.
[Bug middle-end/95351] [11/12/13/14 Regression] Comparison with NAN optimizes incorrectly with -ffast-math disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95351 Andrew Pinski changed: What|Removed |Added Known to fail||4.6.4 Target Milestone|--- |11.5 Summary|Comparison with NAN |[11/12/13/14 Regression] |optimizes incorrectly with |Comparison with NAN |-ffast-math disabled|optimizes incorrectly with ||-ffast-math disabled Known to work||4.5.3 --- Comment #3 from Andrew Pinski --- (In reply to Marc Glisse from comment #2) > It might not be the issue, but merge_truthop_with_opposite_arm has a > suspicious HONOR_NANS (type) where type is bool: the result of the > comparison instead of one of the arguments. I suspect that is the issue since GCC 4.5 was fine and GCC 4.6 is broken. and r0-99565-g27d0d96a8f4064 added merge_truthop_with_opposite_arm for GCC 4.6.
[Bug tree-optimization/110279] [14 Regression] Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law --- Appears to be fixed on the trunk.
[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2024-03-10 CC||law at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 --- Comment #5 from Jerry DeLisle --- I have been studying this a bit by looking at the 2023 std and functionality of printf(). Specifically printf() provides the 'A' descriptor which can be used for float (kind=4) and double (kind=8). It will accept a long double (80 bit aka kind=10). I am noticing that the results of double and long double are identical, no extra precision visible. It is very possible I am not doing that correctly. I do not see anything related to quad precision floats. I am posting this as i think we will have to do some of our own translating byte portions of floats ourselves. Portability may be an issue. For example IBM 360 128bit precision or some other processor may not follow the same internal representations. Regardless I have preliminary code for the frontend that results in calling anew fucntion write_ex in transfer.c I think that kind=4 and kind=8 will be fine. Any thoughts on kind=10 or kind=16 I would appreciate as I further explore this.
[Bug sanitizer/108256] Missing integer overflow instrumentation when assignment LHS is narrow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108256 Andrew Pinski changed: What|Removed |Added CC||haoxintu at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 95326 has been marked as a duplicate of this bug. ***
[Bug middle-end/95326] GCC can not detect signed-integer-overflow correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95326 Andrew Pinski changed: What|Removed |Added Known to fail||13.1.0 Known to work||12.3.0 Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Fixed for GCC 13 by r13-4988-g8692b15ae7c05e so a dup of bug 108256. *** This bug has been marked as a duplicate of bug 108256 ***
[Bug c++/109247] [13/14 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Status|SUSPENDED |RESOLVED Resolution|--- |FIXED --- Comment #20 from Jeffrey A. Law --- Fixed on trunk and backported to gcc-13.
[Bug tree-optimization/82374] #pragma GCC optimize is not applied to openmp-generated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82374 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug c++/106363] [13 Regression] [modules] ICE using-declaration of imported name in the same namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106363 Jeffrey A. Law changed: What|Removed |Added Summary|[13/14 Regression] |[13 Regression] [modules] |[modules] ICE |ICE using-declaration of |using-declaration of|imported name in the same |imported name in the same |namespace |namespace | CC||law at gcc dot gnu.org --- Comment #7 from Jeffrey A. Law --- Fixed on the trunk.
[Bug c++/103183] [11/12/13/14 Regression] ind[arr] produces an lvalue when arr is an array xvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103183 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- Per c#5.
[Bug target/102264] [11/12/13/14 Regression] extra spilling when using inline-asm and all registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #11 from Jeffrey A. Law --- I agree with c#7. If you use all the registers, then you're lucky it compiled at all without throwing an error.
[Bug target/102250] [11/12/13/14 Regression] python is not documented as a Prerequisite for building for riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102250 --- Comment #7 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:7c8f0a79a7e1e42f846ddbca14b98b47ddcfd178 commit r14-9416-g7c8f0a79a7e1e42f846ddbca14b98b47ddcfd178 Author: jlaw Date: Sat Mar 9 20:11:39 2024 -0700 [committed] [target/102250] Document python requirement for risc-v PR target/102250 gcc/ * doc/install.texi: Document need for python when building RISC-V compilers.
[Bug tree-optimization/99987] [12/13/14 Regression] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99987 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug target/111362] [14 Regression] '-fcompare-debug' failure (length) with -O -fno-tree-ch --param=max-completely-peel-times=0 -march=rv64iv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111362 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/111362] [14 Regression] '-fcompare-debug' failure (length) with -O -fno-tree-ch --param=max-completely-peel-times=0 -march=rv64iv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111362 --- Comment #4 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:50531b6d400945793a1d549e6ee941d989319d42 commit r14-9415-g50531b6d400945793a1d549e6ee941d989319d42 Author: jlaw Date: Sat Mar 9 19:27:32 2024 -0700 [committed] [PR target/111362] Fix compare-debug issue with mode switching The issue here is the code we emit for mode-switching can change when -g is added to the command line. This is caused by processing debug notes occurring after a call which is the last real statement in a basic block. Without -g the CALL_INSN is literally the last insn in the block and the loop exits. If mode switching after the call is needed, it'll be handled as we process outgoing edges. With -g the loop iterates again and in the processing of the node the backend signals that a mode switch is necessary. I pondered fixing this in the target, but the better fix is to ignore the debug notes in the insn stream. I did a cursory review of some of the other compare-debug failures, but did not immediately see others which would likely be fixed by this change. Sigh. Anyway, bootstrapped and regression tested on x86. Regression tested on rv64 as well. PR target/111362 gcc/ * mode-switching.cc (optimize_mode_switching): Only process NONDEBUG insns. gcc/testsuite * gcc.target/riscv/compare-debug-1.c: New test. * gcc.target/riscv/compare-debug-2.c: New test.
[Bug tree-optimization/93271] [11/12/13/14 regression] SRA producing wrong code on denormals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271 --- Comment #17 from Andrew Pinski --- Ping?
[Bug middle-end/85957] i686: Integers appear to be different, but compare as equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957 --- Comment #29 from Andrew Pinski --- fexcess-precision=standard was added to C++ front-end by r13-3290-g98e341130f8798 (for GCC 13).
[Bug c/38716] Undocumented __attribute__((optimize)) behaviour when the attribute specifies no optimisation level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38716 Bug 38716 depends on bug 63401, which changed state. Bug 63401 Summary: "optimize" attribute overwrites other options https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/63401] "optimize" attribute overwrites other options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92860 --- Comment #4 from Andrew Pinski --- Fixed by the patches which fixed PR 92860 (there were a few) so closing.
[Bug middle-end/63401] "optimize" attribute overwrites other options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401 Andrew Pinski changed: What|Removed |Added Known to fail||11.4.0 Keywords||needs-bisection Target Milestone|--- |12.0 Known to work||12.1.0 --- Comment #3 from Andrew Pinski --- Both this and the duplicate was fixed in GCC 12 ...
[Bug target/114284] [14 Regression] arm: Load of volatile short gets miscompiled (loaded twice) since r14-8319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #10 from Roger Sayle --- Thanks Jakub. My apologies for the unintentional breakage.
[Bug tree-optimization/107372] Loop distribution creates memcpy between structs with different storage order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107372 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.4
[Bug tree-optimization/107372] Loop distribution creates memcpy between structs with different storage order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107372 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Fixed correctly by r13-4244-g55cb8c5c9abfe8 .
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #11 from Jeffrey A. Law --- The larger point is we don't just disable passes because they have a bug, or even multiple bugs. We need to do the right thing from an engineering standpoint, ie, actually debug the problem. In fact, this is a great example of why disabling would be a mistake. This bug is going to be easier to analyze than the python issue triggered by f-m-o or the m68k bootstrap issue. Had we disabled, we likely wouldn't have tripped over this issue.
[Bug rtl-optimization/58021] MODE_EXIT switches at NOTE_INSN_DELETED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58021 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.9.0 --- Comment #1 from Andrew Pinski --- Fixed a long time ago by r0-124502-gbba332115892c0 for GCC 4.9.0
[Bug rtl-optimization/57968] MODE_EXIT switches inserted too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57968 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.9.0 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed a long time ago: r0-12-gce4a94223ea08c (for GCC 4.9.0).
[Bug target/111362] [14 Regression] '-fcompare-debug' failure (length) with -O -fno-tree-ch --param=max-completely-peel-times=0 -march=rv64iv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111362 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org --- Comment #3 from Jeffrey A. Law --- Looks like a minor bug in the generic mode-switching code to me. Testing a fix...
[Bug tree-optimization/56286] vectorizer does not keep loop-closed SSA up-to-date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56286 Andrew Pinski changed: What|Removed |Added Keywords||FIXME Last reconfirmed|2013-02-11 00:00:00 |2024-3-9 --- Comment #3 from Andrew Pinski --- The fixme is still there: /* If we vectorized any loop only virtual SSA form needs to be updated. ??? Also while we try hard to update loop-closed SSA form we fail to properly do this in some corner-cases (see PR56286). */ rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa_only_virtuals); ret |= TODO_cleanup_cfg;
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #10 from Sam James --- Sure, that's fine (I would've CC'd you for your opinion if you weren't here already). I know you were reluctant already with the m68k PR, but figured this was different enough to suggest it given the other one is analysed at least. Understood.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #9 from Jeffrey A. Law --- Sam, no. That would be a big mistake.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #8 from Sam James --- We could flip the default for -ffold-mem-offsets for HPPA to off for now..
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #7 from John David Anglin --- Created attachment 57658 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57658=edit Patch This change works around the reload issue for alpha.i and the reduced test case. In principle, this could also occur for SI and DI mode floating-point loads and stores but limiting them to 5-bit offsets is a big compromise. It probably would also break python builds as PR rtl-optimization/112415 still isn't fixed.
[Bug middle-end/114291] -fcompare-debug failure (length) with -fprofile-use at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114291 Andrew Pinski changed: What|Removed |Added Component|gcov-profile|middle-end --- Comment #2 from Andrew Pinski --- I suspect the issue is dump_enumerated_decls is not skipping GIMPLE_LABEL as GIMPLE_LABEL does not effect different code generation only additional labels and at -O0 GCC emits extra labels for better debug info.
[Bug gcov-profile/114291] -fcompare-debug failure (length) with -fprofile-use at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114291
--- Comment #1 from Andrew Pinski ---
`Declarations used by main, sorted by DECL_UID` is printed by
dump_enumerated_decls
Which is caused by execute_cleanup_cfg_post_optimizing :
```
if ((flag_compare_debug_opt || flag_compare_debug)
&& flag_dump_final_insns)
{
...
flag_dump_noaddr = flag_dump_unnumbered = 1;
fprintf (final_output, "\n");
dump_enumerated_decls (final_output,
dump_flags | TDF_SLIM | TDF_NOUID);
flag_dump_noaddr = save_noaddr;
flag_dump_unnumbered = save_unnumbered;
```
That looks fine.
But I don't get why L0 is there in the -g case but not there without ...
[Bug c++/114292] [11/12/13/14 Regression] ICE with a generic (templated) lambda capturing a constant for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292 --- Comment #2 from Andrew Pinski --- It looks like tile_rows is not being captured correctly.
[Bug c++/114292] [11/12/13/14 Regression] ICE with a generic (templated) lambda capturing a constant for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292 Andrew Pinski changed: What|Removed |Added Known to work||4.9.4, 5.3.0, 5.5.0, 6.4.0, ||7.1.0, 7.5.0 Summary|ICE with a generic |[11/12/13/14 Regression] |(templated) lambda |ICE with a generic |capturing a constant for|(templated) lambda |VLA allocation |capturing a constant for ||VLA allocation Known to fail||5.1.0, 5.2.0, 8.1.0 Target Milestone|--- |11.5
[Bug c++/114292] ICE with a generic (templated) lambda capturing a constant for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-03-09
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confiremed. reduced testcase:
```
void f(int c)
{
constexpr int r = 4;
[&](auto) { int t[r * c]; }(0);
}
```
[Bug ipa/113359] [13/14 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-09 Known to fail||14.0 Summary|[13 Regression] LTO |[13/14 Regression] LTO |miscompilation of ceph on |miscompilation of ceph on |aarch64 |aarch64 --- Comment #18 from Andrew Pinski --- Confirmed.
[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #17 from Sam James --- There's another small testcase in PR114263.
[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #16 from Andrew Pinski --- *** Bug 114263 has been marked as a duplicate of this bug. ***
[Bug ipa/114263] LTO generating incorrect code with -O2 -std=c++20 -fno-strict-aliasing flags in GCC13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114263 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Yes this is a dup of bug 113359. *** This bug has been marked as a duplicate of bug 113359 ***
[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Andrew Pinski changed: What|Removed |Added CC||lutztonineubert at gmail dot com --- Comment #53 from Andrew Pinski --- *** Bug 106921 has been marked as a duplicate of this bug. ***
[Bug ipa/106921] [11/12/13/14 Regression] -O1 and -fipa-icf -fpartial-inlining causes wrong code since r11-4987-g602c6cfc79ce4ae6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106921 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #9 from Andrew Pinski --- (In reply to Martin Liška from comment #5) > So what happens? First, a split part is created and ICF merges the functions: ... > > I don't see there any problem, later on, the functions are inlined back and > we end up with the following in a-pr106921.c.094t.fixup_cfg3: You missed that the range infomation on the SSA names are kept for one version of the functions which meant they will be an inconsistency. Anyways this is a dup of bug 113907 which has more analysis on the issue and ideas of how to fix it. *** This bug has been marked as a duplicate of bug 113907 ***
[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Andrew Pinski changed: What|Removed |Added Summary|[12/13/14 regression] ICU |[11/12/13/14 regression] |miscompiled since on x86|ICU miscompiled since on |since |x86 since |r14-5109-ga291237b628f41|r14-5109-ga291237b628f41 --- Comment #52 from Andrew Pinski --- The testcase from PR 114290 shows this has been an issue since GCC 9 (r9-7460-g9f2cfe108f75de). r9-7460-g9f2cfe108f75de was the revision which copied the range information for the splitted out function too ...
[Bug ipa/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Andrew Pinski changed: What|Removed |Added CC||jlame646 at gmail dot com --- Comment #51 from Andrew Pinski --- *** Bug 114290 has been marked as a duplicate of this bug. ***
[Bug ipa/114290] [11/12/13/14 regression] GCC output incorrect output with -O2 since r9-7460-g9f2cfe108f75de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114290
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Andrew Pinski ---
Yes this is a dup of bug 113907.
What is happening is fnsplit happens and splits off from both f and g:
return {A / B + (A % B != 0)};
and
return {C / D + (C % D != 0)};
into a new 2 functions and the range information is still there for A/B (C/D).
Which is fine.
And then ICF comes along and sees this 2 new functions are the same (which they
are) but since the range information is there still from one version of the
function (which in this case the bad one), the wrong result happens.
This is all described in PR 113907 too.
*** This bug has been marked as a duplicate of bug 113907 ***
[Bug ipa/114290] [11/12/13/14 regression] GCC output incorrect output with -O2 since r9-7460-g9f2cfe108f75de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114290 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |11.5
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #6 from John David Anglin --- It looks to me like a bug in reload. Reload generates bogus reloads for insn 14 and deletes insn 10 which sets (reg/f:SI 146). But the bug was probably exposed by the change I made a few months ago to pa_legitimate_address_p. insn 14 needs reloading because the offset doesn't fit in 5 bits. The code in pa_emit_move_sequence to fix up invalid offsets in floating point loads and stores is not used. This backtrace points to the broken area of reload. (gdb) bt #0 pa_emit_move_sequence (operands=0xf7b02e08, mode=E_SImode, scratch_reg=0x0) at ../../gcc/gcc/config/pa/pa.cc:1924 #1 0x011366a8 in gen_movsi (operand0=0xf98f35e8, operand1=0xf98276a0) at ../../gcc/gcc/config/pa/pa.md:2141 #2 0x004a7070 in insn_gen_fn::operator() ( this=) at ../../gcc/gcc/recog.h:441 #3 emit_move_insn_1 (x=0xf98276a0, y=0xf98276a0) at ../../gcc/gcc/expr.cc:4551 #4 0x004b229c in gen_move_insn (x=0xf98276a0, y=0xf98f35e8) at ../../gcc/gcc/expr.cc:4741 #5 0x00843fe4 in gen_reload (out=, in=, opnum=-108890464, type=RELOAD_FOR_OPERAND_ADDRESS) at ../../gcc/gcc/reload1.cc:8637 #6 0x008442f0 in gen_reload (out=, in=, opnum=-108890464, type=RELOAD_FOR_OPERAND_ADDRESS) at ../../gcc/gcc/reload1.cc:8550 #7 0x00848914 in emit_input_reload_insns (chain=, rl=0x192ddf8 , old=, j=-108890464) at ../../gcc/gcc/reload1.cc:7527 #8 do_input_reload (chain=, rl=0xf98f35e8, j=-108890464) at ../../gcc/gcc/reload1.cc:7814 #9 0x00850698 in emit_reload_insns (chain=) at ../../gcc/gcc/reload1.cc:8002 #10 reload_as_needed (live_known=1) at ../../gcc/gcc/reload1.cc:4543 --Type for more, q to quit, c to continue without paging-- #11 reload (first=, global=1) at ../../gcc/gcc/reload1.cc:1047 #12 0x0067c508 in do_reload () at ../../gcc/gcc/ira.cc:5985 #13 (anonymous namespace)::pass_reload::execute (this=) at ../../gcc/gcc/ira.cc:6161 #14 0x0079ef7c in execute_one_pass (pass=0xf98276a0) at ../../gcc/gcc/passes.cc:2646 #15 0x0079f894 in execute_pass_list_1 (pass=0xf98276a0) at ../../gcc/gcc/passes.cc:2755 #16 0x0079f8ac in execute_pass_list_1 (pass=0xf98276a0) at ../../gcc/gcc/passes.cc:2756 #17 0x0079f90c in execute_pass_list (fn=, pass=) at ../../gcc/gcc/passes.cc:2766 #18 0x003b9a8c in cgraph_node::expand (this=0xf98276a0) at ../../gcc/gcc/context.h:48 #19 cgraph_node::expand (this=0xf98276a0) at ../../gcc/gcc/cgraphunit.cc:1798 #20 0x003bbaa8 in expand_all_functions () at ../../gcc/gcc/cgraphunit.cc:2028 #21 symbol_table::compile (this=0xf98276a0) at ../../gcc/gcc/cgraphunit.cc:2402 #22 0x003bdc4c in symbol_table::compile (this=0x7) at ../../gcc/gcc/cgraphunit.cc:2315 #23 symbol_table::finalize_compilation_unit (this=0x7) at ../../gcc/gcc/cgraphunit.cc:2587 #24 0x008d137c in compile_file () at ../../gcc/gcc/toplev.cc:476 Will try to work around issue in pa_legitimate_address_p.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #31 from Jerry DeLisle --- (In reply to john.harper from comment #30) > Thank you! > I encourage folks to move to gcc/gfortran 13. However, if you need it on 12, I can do so.
[Bug ipa/114290] [11/12/13/14 regression] GCC output incorrect output with -O2 since r9-7460-g9f2cfe108f75de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114290 Sam James changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Sam James --- (In reply to Sam James from comment #2) > r9-7460-g9f2cfe108f75de ... i.e. r10-1350-gbaf8d2ecd702d4.
[Bug ipa/114290] [11/12/13/14 regression] GCC output incorrect output with -O2 since r9-7460-g9f2cfe108f75de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114290 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org Summary|GCC output incorrect output |[11/12/13/14 regression] |with -O2|GCC output incorrect output ||with -O2 since ||r9-7460-g9f2cfe108f75de See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90982 --- Comment #2 from Sam James --- r9-7460-g9f2cfe108f75de
[Bug ipa/114290] GCC output incorrect output with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114290 rvalue changed: What|Removed |Added CC||i at rvalue dot moe --- Comment #1 from rvalue --- I've done some bisect and found the problematic commit was 9f2cfe108f75de49a331ba27f01d509e2c8c1c70 and the problematic patch was https://gcc.gnu.org/pipermail/gcc-patches/2019-June/524662.html Tested on target x86_64-unknown-linux-gnu
[Bug target/111362] [14 Regression] '-fcompare-debug' failure (length) with -O -fno-tree-ch --param=max-completely-peel-times=0 -march=rv64iv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111362 Jeffrey A. Law changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-09
[Bug d/103944] [12/13/14 Regression] Testsuite hang due to libphobos/testsuite/libphobos.gc/forkgc2.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P4
[Bug tree-optimization/106315] [13/14 Regression] 7.8% increased codesize on specfp 507.cactuBSSN_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug rtl-optimization/112610] [12/13/14 Regression] ICE: SIGSEGV with -flive-range-shrinkage -fdump-rtl-all-all -fira-verbose=9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112610 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Vlad fixed this on the trunk a while back.
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Jeffrey A. Law changed: What|Removed |Added CC||christoph at muppetnet dot net --- Comment #50 from Jeffrey A. Law --- *** Bug 113665 has been marked as a duplicate of this bug. ***
[Bug ipa/113665] [11/12/13/14 regression] Regular for Loop results in Endless Loop with -O2 since r11-4987-g602c6cfc79ce4a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #10 from Jeffrey A. Law --- Tracking in 113907 as that one has more detail about the ICF vs Ranges issue, possible short and longer term solutions, etc. *** This bug has been marked as a duplicate of bug 113907 ***
[Bug c++/114292] New: ICE with a lambda capturing a constant for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292
Bug ID: 114292
Summary: ICE with a lambda capturing a constant for VLA
allocation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: franckbehaghel_gcc at protonmail dot com
Target Milestone: ---
cat main.cpp
void process_tile( int tile_cols)
{
constexpr int tile_rows = 4;
auto lambda = [&](auto param1) {
// Define an tmp buffer.
float buffer[tile_rows * tile_cols] ;
};
int param1=0;
lambda(param1);
}
int main(int, const char**) {
int tile_cols = 4;
process_tile(tile_cols);
return 0;
}
g++ --version
g++ (GCC) 14.0.1 20240307 (experimental)
g++ main.cpp
main.cpp: In instantiation of ‘process_tile(int):: [with auto:1
= int]’:
main.cpp:14:11: required from here
14 | lambda(param1);
| ~~^~~~
main.cpp:9:22: internal compiler error: in tsubst_expr, at cp/pt.cc:21412
9 | float buffer[tile_rows * tile_cols] ;
| ^
0x778cc4 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:21412
0x967c7a tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:20082
0x969973 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:20297
0x96eb39 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:16278
0x96ee98 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.cc:16723
0x97e712 tsubst_decl
../../gcc/gcc/cp/pt.cc:15532
0x978e8e tsubst_stmt
../../gcc/gcc/cp/pt.cc:18524
0x977905 tsubst_stmt
../../gcc/gcc/cp/pt.cc:18393
0x977905 tsubst_stmt
../../gcc/gcc/cp/pt.cc:18780
0x977847 tsubst_stmt
../../gcc/gcc/cp/pt.cc:18393
0x977847 tsubst_stmt
../../gcc/gcc/cp/pt.cc:18407
0x977905 tsubst_stmt
../../gcc/gcc/cp/pt.cc:18393
0x977905 tsubst_stmt
../../gcc/gcc/cp/pt.cc:18780
0x9760e6 tsubst_stmt
../../gcc/gcc/cp/pt.cc:27065
0x9760e6 instantiate_body
../../gcc/gcc/cp/pt.cc:27065
0x97688e instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.cc:27350
0x8732af maybe_instantiate_decl(tree_node*)
../../gcc/gcc/cp/decl2.cc:5616
0x8732af maybe_instantiate_decl(tree_node*)
../../gcc/gcc/cp/decl2.cc:5603
0x8742f5 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.cc:5915
0x7e283a build_over_call
../../gcc/gcc/cp/call.cc:10563
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/99599] [11/12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 Patrick Palka changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=108393| CC||nikolasklauser at berlin dot de --- Comment #20 from Patrick Palka --- *** Bug 108393 has been marked as a duplicate of this bug. ***
[Bug c++/108393] circular concept false-positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393 Patrick Palka changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=99599 | Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #6 from Patrick Palka --- GCC trunk after r14-3809 should now avoid this kind of constraint recursion involving an unreachable_sentinel_t parameter. *** This bug has been marked as a duplicate of bug 99599 ***
[Bug target/114284] [14 Regression] arm: Load of volatile short gets miscompiled (loaded twice) since r14-8319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Jeffrey A. Law --- Actually change the state this time :-0
[Bug target/114284] [14 Regression] arm: Load of volatile short gets miscompiled (loaded twice) since r14-8319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #8 from Jeffrey A. Law --- Fixed on the trunk.
[Bug middle-end/114291] New: -fcompare-debug failure (length) with -fprofile-use at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114291
Bug ID: 114291
Summary: -fcompare-debug failure (length) with -fprofile-use at
-O0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following is an -fcompare-debug failure that shows up with PGO (here on
aarch64-linux-gnu):
$ cat t.c
void foo() {}
int main(void) {}
$ gcc t.c -fprofile-generate
$ ./a.out
$ gcc t.c -fprofile-use -fcompare-debug
gcc: error: t.c: ‘-fcompare-debug’ failure (length)
The difference seems to be as follows:
$ gcc t.c -fprofile-use -fdump-final-insns=nodebug.final
$ gcc t.c -fprofile-use -g -fcompare-debug-second
-fdump-final-insns=debug.final
$ diff -u nodebug.final debug.final
--- nodebug.final 2024-03-09 12:00:43.875729773 +
+++ debug.final 2024-03-09 12:00:52.555650670 +
@@ -1,5 +1,6 @@
-;; Function foo (foo, funcdef_no=0, decl_uid=4426, cgraph_uid=1,
symbol_order=0) (unlikely executed)
+
+;; Function foo (foo, funcdef_no=0, cgraph_uid=1, symbol_order=0) (unlikely
executed)
(note # 0 0 NOTE_INSN_DELETED)
(note # 0 0 NOTE_INSN_PROLOGUE_END)
@@ -18,7 +19,10 @@
(barrier # 0 0)
(note # 0 0 NOTE_INSN_DELETED)
-;; Function main (main, funcdef_no=1, decl_uid=4429, cgraph_uid=2,
symbol_order=1)
+Declarations used by main, sorted by DECL_UID:
+0: void ;
+
+;; Function main (main, funcdef_no=1, cgraph_uid=2, symbol_order=1)
(note # 0 0 NOTE_INSN_DELETED)
(note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
[Bug target/114284] [14 Regression] arm: Load of volatile short gets miscompiled (loaded twice) since r14-8319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3e3e4156a5f93e6d62101594ca6660ee9ce9c10e commit r14-9412-g3e3e4156a5f93e6d62101594ca6660ee9ce9c10e Author: Jakub Jelinek Date: Sat Mar 9 13:04:26 2024 +0100 fwprop: Restore previous behavior for forward propagation of RTL with MEMs [PR114284] Before the recent PR111267 r14-8319 fwprop changes, fwprop would never try to propagate what was not considered PROFITABLE, where the profitable part actually was partly about profitability, partly about very good reasons not to actually propagate and partly for cases where propagation is completely incorrect. In particular, classify_result has: /* Allow (subreg (mem)) -> (mem) simplifications with the following exceptions: 1) Propagating (mem)s into multiple uses is not profitable. 2) Propagating (mem)s across EBBs may not be profitable if the source EBB runs less frequently. 3) Propagating (mem)s into paradoxical (subreg)s is not profitable. 4) Creating new (mem/v)s is not correct, since DCE will not remove the old ones. */ if (single_use_p && single_ebb_p && SUBREG_P (old_rtx) && !paradoxical_subreg_p (old_rtx) && MEM_P (new_rtx) && !MEM_VOLATILE_P (new_rtx)) return PROFITABLE; and didn't mark any other MEM_P (new_rtx) or rtxes which contain a MEM in its subrtxes as PROFITABLE. Now, since r14-8319 profitable_p method has been renamed to likely_profitable_p and has just a minor role. Now, rule 4) above is something that isn't about profitability, but about correct behavior, if you propagate mem/v, the code is miscompiled. This particular case has been fixed elsewhere by Haochen in r14-9379. But I think even the 1) and 2) and maybe 3) are a strong don't do it, don't rely solely on rtx costs, increasing the number of loads of the same memory, even when cached, is undesirable, canceling load hoisting can be undesirable as well. So, the following patch restores previous behavior of src contains any MEMs, in that case likely_profitable_p () is taken as the old profitable_p () as a requirement rather than just a hint. For propagation of something which doesn't load from memory this keeps the r14-8319 behavior. 2024-03-09 Jakub Jelinek PR target/114284 * fwprop.cc (try_fwprop_subst_pattern): Don't propagate src containing MEMs unless prop.likely_profitable_p ().
[Bug c++/114290] New: GCC output incorrect output with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114290
Bug ID: 114290
Summary: GCC output incorrect output with -O2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following program gives wrong output `0` with `-O2` for input `2`. When
`f(1,1)` is commented out(or removed) it produces correct output.
https://godbolt.org/z/3rxah7Grx
```
#include
#include
struct Node {
int x;
};
Node f(int A, int B) {
if (A < 0) return {0};
return {A / B + (A % B != 0)};
}
Node g(int C, int D) {
if (C > 0) return {0};
return {C / D + (C % D != 0)};
}
int main() {
int n;
std::cin >> n;
f(1, 1); //commenting this line fixes the issue
Node t = g(-1, n);
std::cout << t.x;
}
```
[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=26 --- Comment #14 from Xi Ruoyao --- (In reply to Jeffrey A. Law from comment #13) > So like the other bug involving multiplies against objects with a known > range [0,1], we should very seriously consider turning the multiply into a > conditional move. ie x * b where b is known to have the range [0,1] we can > turn that into > > dest = b ? x : 0 > > Some processors that don't have generalized conditional moves do have > conditional zero instructions. ie, zicond on RISC-V. It's PR26.
