[Bug target/114264] RISC-V: ICE in riscv-vector-costs.cc of gcc master branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114264 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||law at gcc dot gnu.org --- Comment #2 from Jeffrey A. Law --- Fixed on the trunk.
[Bug middle-end/114196] [13 Regression] Fixed length vector ICE: in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114196 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 Summary|[13/14 Regression] Fixed|[13 Regression] Fixed |length vector ICE: in |length vector ICE: in |vect_peel_nonlinear_iv_init |vect_peel_nonlinear_iv_init |, at tree-vect-loop.cc:9454 |, at tree-vect-loop.cc:9454 CC||law at gcc dot gnu.org
[Bug target/113790] [14 Regression][riscv64] ICE in curr_insn_transform, at lra-constraints.cc:4294 since r14-4944-gf55cdce3f8dd85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Jeffrey A. Law --- Fixed on the trunk.
[Bug tree-optimization/110327] [12/13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r12-4790-g4b3a325f07a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110327 --- Comment #3 from Jeffrey A. Law --- Two block copies isn't fatal when the second one is the one with the actual jump thread. But costing does get more complex. Basically we copy 8 so that we can isolate its two incoming paths which thread differently in bb10. That's pretty standard stuff. It looks like that particular threading possibility is hidden until after DOM3 is complete. Prior to and during DOM3, there's another block in the way. # c.3_16 = PHI <0(3), 2(5)> _9 = h; _10 = *_9; _11 = *_10; _12 = *_11; _13 = (char) _12; if (_13 != -28) goto ; [0.00%] else goto ; [100.00%] ;;succ: 8 ;;9 ;; basic block 8, loop depth 0 ;;pred: 7 __builtin_unreachable (); ;;succ: ;; basic block 9, loop depth 1 ;;pred: 7 if (_12 <= 4) goto ; [50.00%] else goto ; [50.00%] ;;succ: 10 ;;15 ;; basic block 10, loop depth 1 ;;pred: 9 _15 = d; *_10 = _15; if (c.3_16 <= 0) goto ; [5.50%] else goto ; [94.50%] Note bb9.
[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110503 --- Comment #7 from Jeffrey A. Law --- As you note, this feels like a failure to recognize that only one value can actually satisfy the condition.
[Bug tree-optimization/110538] [14 Regression] Dead Code Elimination Regression since r14-368-ge1366a7e4ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110538 --- Comment #3 from Jeffrey A. Law --- Thread references removed edge: Cancelling jump thread: (9, 10) incoming edge; (10, 8) joiner (8, 6) normal; Thread references removed edge: Cancelling jump thread: (2, 3) incoming edge; (3, 9) joiner (9, 10) nocopy (10, 8) normal; Thread references removed edge: Cancelling jump thread: (2, 3) incoming edge; (3, 10) joiner (10, 8) normal; Thread references removed edge: Cancelling jump thread: (3, 10) incoming edge; (10, 8) normal; [ ... ] Merging blocks 10 and 8 Removing basic block 11 ;; basic block 11, loop depth 1 ;; pred: goto ; [100.00%] ;; succ: 3 So one of the edges in the jump threading path gets removed. As a result the threader throws the path away. At least that's my best guess. We could possibly defer block merging until after threading. No idea how hard that might be. The sequencing is a bit painful, but IIRC the key is that we must remove unreachables in the CFG before threading (due to how unreachables interact with the dominator tree updates).
[Bug tree-optimization/110891] [14 Regression] Dead Code Elimination Regression since r14-2674-gd0de3bf9175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891 --- Comment #8 from Jeffrey A. Law --- Note that Richi was supportive of the patch and just asked for a few minor changes. Pinski, if you wanted to take care of Richi's comments we could get this one off the P2 list.
[Bug tree-optimization/110931] [14 Regression] Dead Code Elimination Regression since r14-2890-gcc2003cd875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110931 --- Comment #5 from Jeffrey A. Law --- One could also look at this as a failure to propagate. l.0_1 = l; t_4 = (short int) l.0_1; if (t_4 == 0) goto ; [50.00%] else goto ; [50.00%] We ought to be able to propagate l.0_1 into the conditional for t_4. If we do that, then we'll be able to propagate 0 for l.0_1 in this block: ;; basic block 3, loop depth 0, count 536870912 (estimated locally, freq 0.5000) ;;prev block 2, next block 4, flags: (NEW, VISITED) ;;pred: 2 [50.0% (guessed)] count:536870912 (estimated locally, freq 0.5000) (TRUE_VALUE,EXECUTABLE) b_5 = (char) l.0_1; if (b_5 != 1) goto ; [0.00%] else goto ; [100.00%] And once we propagate the value 0 that will make the make bb5 (containing the call to foo) unreachable. IIRC we have (had?) some code to do these kinds of propagations through conversions. IIRC it was fairly conservative, perhaps overly so.
[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 Jeffrey A. Law changed: What|Removed |Added CC||rzinsly at ventanamicro dot com --- Comment #13 from Jeffrey A. Law --- 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.
[Bug tree-optimization/111798] [14 Regression] Recent change causing testsuite regression and poor code on mcore-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111798 Jeffrey A. Law changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Jeffrey A. Law --- I wouldn't look at with/without tree-sra. Instead I would look at the assembly code before/after your change. It's clearly worse. testK goes from ~37 instructions to ~70 and the abort call is no longer removed.
[Bug tree-optimization/110293] Some `A CMP (A NEEQ 0)` is not simplified in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293 --- Comment #10 from Andrew Pinski --- Here is some more optimizations where the inner CMP is not EQ/NE: signed: x == (x <= CST) -> CST == 0 ? false : CST < 0 ? x == 0 : x == 1 x == (x < CST) -> CST == 1 ? false : CST <= 0 ? x == 0 : x == 1 unsigned: x == (x u<= CST) -> CST == 0 ? false : x == 1 (note 0 should already be handled) x == (x u<= CST) -> CST == 0 ? x == 0 : CST == 1 ? false : x == 1 (note 0/1 should be handled already)
[Bug middle-end/111799] [14 Regression] Missed Dead Code Elimination since r14-2365-g2e406f0753e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111799 --- Comment #6 from Jeffrey A. Law --- I'd hazard a guess we need to first eliminate the ad = assignment. That should in turn allow us to realize ad is unchanging.
[Bug tree-optimization/111801] [14 Regression] Missed Dead Code Elimination since r14-4141-gbf6b107e2a3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111801 --- Comment #2 from Jeffrey A. Law --- Interestingly enough this is picked up at -O3. Looks like PRE does a better job and the result is easier to discover the range for first operand of the controlling conditional.
[Bug tree-optimization/111864] [12/13/14 Regression] Dead Code Elimination Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864 Jeffrey A. Law changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #2 from Jeffrey A. Law --- It almost looks like a costing issue. The threaders find opportunities to thread all the incoming edges in the key block to the path which avoids the call.. But all the paths get rejected. This is the key block: ;; basic block 11, loop depth 0, count 976284897 (estimated locally, freq 0.9092), maybe hot ;;prev block 10, next block 12, flags: (NEW, REACHABLE, VISITED) ;;pred: 10 [99.8% (guessed)] count:225266786 (estimated locally, freq 0.2098) (TRUE_VALUE,EXECUTABLE) ;;14 [100.0% (guessed)] count:751018112 (estimated locally, freq 0.6994) (TRUE_VALUE,EXECUTABLE) # o.10_11 = PHI <(10), o.10_28(14)> _17 = o.10_11 == _20 = o.10_11 == _27 = _20 | _17; if (_27 != 0) goto ; [58.87%] else goto ; [41.13%] It's pretty obvious that 10->11 can thread to 6. If we look at the other incoming edge we need o.10_28 which comes from bb14 with the value So that path should be 14->10->11 threading to 6. But they get rejected during threadfull2.
[Bug tree-optimization/112545] [14 Regression] Size regression when using -Os starting with r14-569-g21e2ef2dc25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112545 --- Comment #2 from Jeffrey A. Law --- This looks like a missed case for singletons. _1 = d.9_28 <= 0; _2 = (signed short) _1; _3 = (signed short) d.9_28; c.a = 0; if (_2 == _3) goto ; [0.00%] else goto ; [100.00%] Back substituting the condition is: (d.9_28 <= 0) == d.9_28 d.9_28 <= 0 has a range [0,1] The only value that can make that expression true is if d.9_28 has the value 0.
[Bug tree-optimization/113433] [12/13/14 Regression] Missed optimization for redundancy computation elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113433
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #2 from Jeffrey A. Law ---
So we could attack this as a DOM problem. Not all the infrastructure is in
there. But the recognition of negated expressions isn't hard. Something like
this in tree-ssa-scopedtables will detect the negated expression in the hash
table.
/* We might be able to lookup the negated expression. */
case PLUS_EXPR:
{
tree x = gimple_assign_rhs_to_tree (stmt);
x = fold_unary (NEGATE_EXPR, TREE_TYPE (x), x);
struct hashable_expr expr;
expr.type = TREE_TYPE (x);
expr.kind = EXPR_BINARY;
expr.ops.binary.op = MINUS_EXPR;
expr.ops.binary.opnd0 = TREE_OPERAND (x, 0);
expr.ops.binary.opnd1 = TREE_OPERAND (x, 1);
class expr_hash_elt element2 (, NULL_TREE);
expr_hash_elt **slot
= m_avail_exprs->find_slot (, NO_INSERT);
if (slot && *slot)
return fold_build1 (NEGATE_EXPR, TREE_TYPE (x), (*slot)->lhs
());
return NULL_TREE;
}
Right now DOM isn't prepared for avail_expr_stack::simplify_binary_operation to
return anything other than a constant, ssa_name or NULL. But how hard could it
be to expand further :-)
Not sure if this happens enough to make the extra lookups worth the effort.
[Bug tree-optimization/114277] [11/12/13/14 Regression] Missed optimization: x*(x||b) => x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114277 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org, ||rzinsly at ventanamicro dot com --- Comment #2 from Jeffrey A. Law --- The other approach we could take (and which I think may have certain advantages) would be to first realize this is a multiplication by a boolean (0/1) value. That's just a conditional move. If we then rewrote as a conditional move there's a reasonable chance we'd be able to further simplify. The biggest problem with this approach is if we're aggressively transforming into conditional moves in gimple, the expanders will need improvement, particularly on targets that don't have conditional moves. Raphael has a TODO in this space. He may have further thoughts.
[Bug c++/111224] modules: xtreme-header-1_a.H etc. ICE (in core_vals, at cp/module.cc:6108) on AArch64 with SVE types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224 Nathaniel Shead changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org --- Comment #10 from Nathaniel Shead --- I now have access to an Aarch64 machine via the build farm. My patch in #c7 is not sufficient to get the minimised testcase working (need to update the assumptions on VECTOR_TYPEs too) and it looks like we'll need to work out how to stream the aarch64-specific types found in the 'registered_builtin_types' list too, like __fp16. I'll submit a patch to the mailing lists once I've worked out the details.
[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 #5 from John David Anglin ---
This is what we have from reload with Sam's reduced test case:
(insn 9 103 123 2 (set (reg/f:SI 1 %r1)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref:SI ("indirect_child") "beta.c":18:32 53 {*pa.md:2656}
(nil))
(insn 123 9 11 2 (set (reg:SI 20 %r20 [113])
(reg/f:SI 1 %r1)) "beta.c":18:32 42 {*pa.md:2195}
(nil))
(insn 11 123 10 2 (set (reg:SI 1 %r1 [115])
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2] "beta.c":18:32
53 {*pa.md:2656}
(nil))
(note 10 11 12 2 NOTE_INSN_DELETED)
(insn 12 10 13 2 (set (reg/f:SI 20 %r20 [114])
(mem/u/c:SI (lo_sum:SI (reg:SI 1 %r1 [115])
(unspec:SI [
(symbol_ref/u:SI ("*.LC0") [flags 0x2])
] UNSPEC_DLTIND14R)) [0 S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
(expr_list:REG_EQUIV (symbol_ref/u:SI ("*.LC0") [flags 0x2])
(nil)))
(insn 13 12 125 2 (set (reg:DF 68 %fr22 [116])
(mem/u/c:DF (reg/f:SI 20 %r20 [114]) [0 S8 A64])) "beta.c":18:32 75
{*pa.md:3866}
(expr_list:REG_EQUIV (mem/c:DF (plus:SI (reg/f:SI 146)
(const_int 16 [0x10])) [1 indirect_child.cg.prop.fract+0 S8
A64])
(nil)))
(insn 125 13 127 2 (set (reg:SI 20 %r20)
(const_int 32 [0x20])) "beta.c":18:32 42 {*pa.md:2195}
(nil))
(insn 127 125 128 2 (set (reg:SI 20 %r20)
(reg/f:SI 146)) "beta.c":18:32 42 {*pa.md:2195}
(nil))
(insn 128 127 14 2 (set (reg:SI 20 %r20)
(plus:SI (reg:SI 20 %r20)
(const_int 32 [0x20]))) "beta.c":18:32 120 {addsi3}
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 146)
(const_int 32 [0x20]))
(nil)))
(insn 14 128 116 2 (set (mem/c:DF (plus:SI (reg:SI 20 %r20)
(const_int -16 [0xfff0])) [1
indirect_child.cg.prop.fract+0 S8 A64])
(reg:DF 68 %fr22 [116])) "beta.c":18:32 75 {*pa.md:3866}
(nil))
In ira, we had:
(insn 9 103 11 2 (set (reg:SI 113)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref:SI ("indirect_child") "beta.c":18:32 53 {*pa.md:2656}
(nil))
(insn 11 9 10 2 (set (reg:SI 115)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2] "beta.c":18:32
53 {*pa.md:2656}
(nil))
(insn 10 11 12 2 (set (reg/f:SI 146)
(mem/u/c:SI (lo_sum:SI (reg:SI 113)
(unspec:SI [
(symbol_ref:SI ("indirect_child") )
] UNSPEC_DLTIND14R)) [0 S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
(expr_list:REG_DEAD (reg:SI 113)
(expr_list:REG_EQUIV (symbol_ref:SI ("indirect_child") )
(nil
(insn 12 10 13 2 (set (reg/f:SI 114)
(mem/u/c:SI (lo_sum:SI (reg:SI 115)
(unspec:SI [
(symbol_ref/u:SI ("*.LC0") [flags 0x2])
] UNSPEC_DLTIND14R)) [0 S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
(expr_list:REG_DEAD (reg:SI 115)
(expr_list:REG_EQUIV (symbol_ref/u:SI ("*.LC0") [flags 0x2])
(nil
(insn 13 12 14 2 (set (reg:DF 116)
(mem/u/c:DF (reg/f:SI 114) [0 S8 A64])) "beta.c":18:32 75
{*pa.md:3866}
(expr_list:REG_DEAD (reg/f:SI 114)
(expr_list:REG_EQUIV (mem/c:DF (plus:SI (reg/f:SI 146)
(const_int 16 [0x10])) [1 indirect_child.cg.prop.fract+0 S8
A64])
(nil
(insn 14 13 110 2 (set (mem/c:DF (plus:SI (reg/f:SI 146)
(const_int 16 [0x10])) [1 indirect_child.cg.prop.fract+0 S8
A64])
(reg:DF 116)) "beta.c":18:32 75 {*pa.md:3866}
(expr_list:REG_DEAD (reg:DF 116)
(nil)))
[Bug libstdc++/114240] sys_days not being parsed with only a date in the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #8 from Jonathan Wakely --- This should be fixed now. Thanks for the report.
[Bug libstdc++/114279] utc_clock does not support leap seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114279 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|13.3|14.0 Status|ASSIGNED|RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed for GCC 14. Thanks for the report.
[Bug libstdc++/114240] sys_days not being parsed with only a date in the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240 --- Comment #7 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3e8ee03edd018eed43444755f601cdb9d5931654 commit r14-9406-g3e8ee03edd018eed43444755f601cdb9d5931654 Author: Jonathan Wakely Date: Fri Mar 8 16:15:57 2024 + libstdc++: Do not require a time-of-day when parsing sys_days [PR114240] When parsing a std::chrono::sys_days (or a sys_time with an even longer period) we should not require a time-of-day to be present in the input, because we can't represent that in the result type anyway. Rather than trying to decide which specializations should require a time-of-date and which should not, follow the direction of Howard Hinnant's date library, which allows extracting a sys_time of any period from input that only contains a date, defaulting the time-of-day part to 00:00:00. This seems consistent with the intent of the standard, which says it's an error "If the parse fails to decode a valid date" (i.e., it doesn't care about decoding a valid time, only a date). libstdc++-v3/ChangeLog: PR libstdc++/114240 * include/bits/chrono_io.h (_Parser::operator()): Assume hours(0) for a time_point, so that a time is not required to be present. * testsuite/std/time/parse/114240.cc: New test.
[Bug libstdc++/114279] utc_clock does not support leap seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114279 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f4a52c184d608325c14338b57f464f7d0bbc7526 commit r14-9405-gf4a52c184d608325c14338b57f464f7d0bbc7526 Author: Jonathan Wakely Date: Fri Mar 8 14:41:47 2024 + libstdc++: Fix parsing of leap seconds as chrono::utc_time [PR114279] Implementing all chrono::from_stream overloads in terms of chrono::sys_time meant that a leap second time like 23:59:60.001 cannot be parsed, because that cannot be represented in a sys_time. The fix to support parsing leap seconds as utc_time is to convert the parsed date to utc_time and then add the parsed time to that, which allows the result to land in a leap second, rather than doing all the arithmetic with sys_time which doesn't have leap seconds. For local_time we also allow %S to parse a 60s value, because doing otherwise might disallow some valid uses. We can't know all use cases users have for treating times as local_time. For all other clocks, we can reject times that have 60 or 60.nnn as the seconds part, because that cannot occur in a valid UNIX, GPS, or TAI time. Since our chrono::file_clock uses sys_time, it can't occur for that clock either. In order to support this a new _M_is_leap_second member is needed in the _Parser type. This can be added at the end, where most targets currently have padding bytes. Similar to what I did recently for formatter _Spec structs, we can also reserve additional padding bits for future expansion. This also fixes bugs in the from_stream overloads for utc_time, tai_time, gps_time, and file_time, which were not using time_point_cast to explicitly convert to the result type. That's needed because the result type might have lower precision than the value returned from from_sys or from_utc, which has a precision no lower than seconds. libstdc++-v3/ChangeLog: PR libstdc++/114279 * include/bits/chrono_io.h (_Parser::_M_is_leap_second): New data member. (_Parser::_M_reserved): Reserve padding bits for future use. (_Parser::operator()): Set _M_is_leap_second if %S reads 60s. (from_stream): Only allow _M_is_leap_second for utc_time and local_time. Adjust arithmetic for utc_time so that leap seconds are preserved. Use time_point_cast to convert to a possibly lower-precision result type. * testsuite/std/time/parse.cc: Move to ... * testsuite/std/time/parse/parse.cc: ... here. * testsuite/std/time/parse/114279.cc: New test.
[Bug tree-optimization/113757] [14 regression] ICE when building legion-23.03.0 since r14-8398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Jambor --- Fixed.
[Bug tree-optimization/113757] [14 regression] ICE when building legion-23.03.0 since r14-8398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757 --- Comment #9 from GCC Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:54e505d0446f86b7ad383acbb8e5501f20872b64 commit r14-9403-g54e505d0446f86b7ad383acbb8e5501f20872b64 Author: Martin Jambor Date: Sat Mar 9 00:47:22 2024 +0100 ipa: Avoid excessive removing of SSAs (PR 113757) PR 113757 shows that the code which was meant to debug-reset and remove SSAs defined by LHSs of calls redirected to __builtin_unreachable can trigger also when speculative devirtualization creates a call to a noreturn function (and since it is noreturn, it does not bother dealing with its return value). What is more, it seems that the code handling this case is not really necessary. I feel slightly idiotic about this because I have a feeling that I added it because of a failing test-case but I can neither find the testcase nor a reason why the code in cgraph_edge::redirect_call_stmt_to_callee would not be sufficient (it turns the SSA name into a default-def, a bit like IPA-SRA, but any code dominated by a call to a noreturn is not dangerous when it comes to its side-effects). So this patch just removes the handling. gcc/ChangeLog: 2024-02-07 Martin Jambor PR ipa/113757 * tree-inline.cc (redirect_all_calls): Remove code adding SSAs to id->killed_new_ssa_names. gcc/testsuite/ChangeLog: 2024-02-07 Martin Jambor PR ipa/113757 * g++.dg/ipa/pr113757.C: New test.
[Bug target/114085] Internal (cross) compiler error when building libstdc++ for the H8/300 family
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114085 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org Priority|P3 |P4 CC||law at gcc dot gnu.org --- Comment #2 from Jeffrey A. Law --- Jon's right. This would be a compiler bug. Note however that we have never supported libstdc++ on the H8, but even so the compiler shouldn't be faulting like that.
[Bug testsuite/114182] gcc.c-torture/compile/attr-complex-method-2.c fails for H8/300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114182 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #5 from Jeffrey A. Law --- Pinski's suggestion is the right one. We have a small number of targets that use 32bit doubles. For the sake of testing we should define a target test to cleanly indicate the size of a double and check that in attr-complex-method-2.c and likely in other places.
[Bug target/114222] gcc.c-torture/execute/builtin-bitops-1.c fails for H8/300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114222 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #2 from Jeffrey A. Law --- More likely the test is running out of address space. The default linker script has a pretty small address space and the text will commonly clash with the heap/stack. Naturally that corrupts the text segment causing all kinds of interesting problems -- worse yet, the problems are intermittent as they depend on precisely what gets clobbered within the text segment and what value ends up in the text segment. The easiest way to check for that is throw the test into the debugger and run it. Assuming it faults, disassemble the instruction at the fault point. Then use objdump to disassemble the binary and see if the instruction has been changed.
[Bug analyzer/108722] [13/14 Regression] gcc.dg/analyzer/file-CWE-1341-example.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108722 seurer at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from seurer at gcc dot gnu.org --- Fixed now. Thanks!
[Bug testsuite/109549] [14 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 Jeffrey A. Law changed: What|Removed |Added Assignee|law at gcc dot gnu.org |unassigned at gcc dot gnu.org Priority|P1 |P2
[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 #4 from Jeffrey A. Law --- BTW, the P4 designation is primarily because I suspected this would likely be a PA specific issue. If it turns out to be a generic problem, it would probably immediately bump to P1.
[Bug middle-end/114289] Non-optimal assembly for accessing bit-fields in packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289 --- Comment #5 from Andrew Pinski --- Or it is a dup of bug 55658. Either way dup.
[Bug tree-optimization/66364] poor optimization of packed structs containing bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66364 Andrew Pinski changed: What|Removed |Added CC||dan at stahlke dot org --- Comment #6 from Andrew Pinski --- *** Bug 114289 has been marked as a duplicate of this bug. ***
[Bug middle-end/114289] Non-optimal assembly for accessing bit-fields in packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 66364 ***
[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 John David Anglin changed: What|Removed |Added Last reconfirmed||2024-03-08 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from John David Anglin --- Confirmed with -fpie and -fpic.
[Bug middle-end/114289] Non-optimal assembly for accessing bit-fields in packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
--- Comment #3 from Dan Stahlke ---
Variants that generate more reasonable results:
struct foo {
int x:32;
} __attribute__((packed));
struct foo {
int x:16;
} __attribute__((packed));
struct foo {
int x:31;
};
struct foo {
int x:31;
} __attribute__((packed, aligned(4)));
[Bug middle-end/114289] Non-optimal assembly for accessing bit-fields in packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu Keywords||missed-optimization Component|tree-optimization |middle-end --- Comment #2 from Andrew Pinski --- Part of this is a target issue. Due to the x86_64 backend defining SLOW_BYTE_ACCESS to 0. #define SLOW_BYTE_ACCESS 0
[Bug tree-optimization/114289] Non-optimal assembly for accessing bit-fields in packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
Dan Stahlke changed:
What|Removed |Added
Target|x86_64-linux-gnu|
Keywords|missed-optimization |
Component|middle-end |tree-optimization
--- Comment #1 from Dan Stahlke ---
Variants that generate more reasonable results:
struct foo {
int x:32;
} __attribute__((packed));
struct foo {
int x:16;
} __attribute__((packed));
struct foo {
int x:31;
};
struct foo {
int x:31;
} __attribute__((packed, aligned(4)));
[Bug tree-optimization/114289] New: Non-optimal assembly for accessing bit-fields in packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114289
Bug ID: 114289
Summary: Non-optimal assembly for accessing bit-fields in
packed structs
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dan at stahlke dot org
Target Milestone: ---
// gcc -O3 -g -Wall -march=haswell -mavx2
// https://godbolt.org/z/Yfb9dnYx4
struct foo {
int x:31;
} __attribute__((packed));
int fx(struct foo const *o) { return o->x; }
Disassembly:
movzx eax, BYTE PTR [rdi+1]
movzx edx, BYTE PTR [rdi]
sal rax, 8
or rax, rdx
movzx edx, BYTE PTR [rdi+2]
sal rdx, 16
or rdx, rax
movzx eax, BYTE PTR [rdi+3]
and eax, 127
sal rax, 24
or rax, rdx
sal rax, 33
sar rax, 33
ret
Compare to clang:
mov eax, dword ptr [rdi]
add eax, eax
sar eax
ret
[Bug c++/94894] avoidable instantiation of conversion function template during overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- Fixed in GCC 13
[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201 Bug 106201 depends on bug 94894, which changed state. Bug 94894 Summary: avoidable instantiation of conversion function template during overload resolution https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/105766] requires std::is_constructible<> reports 'constraint depends on itself' error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105766 Bug 105766 depends on bug 94894, which changed state. Bug 94894 Summary: avoidable instantiation of conversion function template during overload resolution https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/107188] using concept type-constraint declared in nested namespace causes incorrect compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107188 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.0 Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- Fixed in GCC 13
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 --- Comment #6 from Andrew Pinski --- (In reply to Antoni from comment #4) > A load in LLVM returns undef, so it is not UB. The problem is in > rustc_codegen_gcc itself. Right, GCC gimple semantics are different from LLVM semantics. GCC gimple semantics are in my opinion the better semantics really. How to handle things like Rust semantics with the GCC gimple semantics is an open question. Basically if I understand correctly Rust semantics depend on LLVM semantics which seems like wrong approach for a security language. undef vs UB is a small semantic difference that makes it hard to program rust really :).
[Bug sanitizer/113284] [14 regression] many failures in asan after r14-6946-ge66dc37b299cac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113284 seurer at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from seurer at gcc dot gnu.org --- Fixed now. Thanks!
[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 Peter Bergner changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #7 from Peter Bergner --- (In reply to Sam James from comment #6) > Please send it to the ML with git-send-email. ...and CC our port maintainers, Segher, Ke Wen and David who are all on CC here.
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 --- Comment #5 from Antoni --- (In reply to Andrew Pinski from comment #3) > >Rust will sometimes copy uninitialized memory and I'd like to avoid > >disabling this specific warning. > > > Note in C, there are specific rules about copying unitialized memory. Most > is it is undefined. It is kinda of odd a "security" language like Rust > allows copying unitialized memory at all since a copy should be considered > an use ... So, if it is UB in C, it makes sense that the analyzer stays that way. However, I would need another solution to copy undefined memory using a different GIMPLE construct or something.
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 --- Comment #4 from Antoni --- (In reply to Andrew Pinski from comment #3) > >Rust will sometimes copy uninitialized memory and I'd like to avoid > >disabling this specific warning. > > > Note in C, there are specific rules about copying unitialized memory. Most > is it is undefined. It is kinda of odd a "security" language like Rust > allows copying unitialized memory at all since a copy should be considered > an use ... A load in LLVM returns undef, so it is not UB. The problem is in rustc_codegen_gcc itself.
[Bug c/53548] allow flexible array members in unions like zero-length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548 --- Comment #8 from Kees Cook --- Clang bug: https://github.com/llvm/llvm-project/issues/84565
[Bug c/53548] allow flexible array members in unions like zero-length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548 --- Comment #7 from Kees Cook --- There is still no way to use C99 flexible arrays in unions (or alone in structs) without syntactic obfuscation. The extension that already allows 0-sized arrays in unions should be extended to cover C99 arrays. This is especially important for projects migrating away from the various deprecated "fake" flexible array members to C99 flex array members, as they continue to depend on both union membership and single-member structs (i.e. the Linux kernel has lots of these, some even in UAPI). Please reopen this bug. :) Clang is also preparing to fix this issue.
[Bug c/53548] allow flexible array members in unions like zero-length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548 Kees Cook changed: What|Removed |Added CC||carlos at gcc dot gnu.org, ||kees at outflux dot net, ||ndesaulniers at google dot com, ||qing.zhao at oracle dot com --- Comment #6 from Kees Cook --- There is still no way to use C99 flexible arrays in unions (or alone in structs) without syntactic obfuscation. The extension that already allows 0-sized arrays in unions should be extended to cover C99 arrays. This is especially important for projects migrating away from the various deprecated "fake" flexible array members to C99 flex array members, as they continue to depend on both union membership and single-member structs (i.e. the Linux kernel has lots of these, some even in UAPI).
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #21 from Steve Kargl --- On Fri, Mar 08, 2024 at 08:01:02PM +, kyle.shores44 at gmail dot com wrote: > > (In reply to Steve Kargl from comment #19) > > > > It seems your code is hitting a NULL pointer dereference when > > generating a warning. In resolve.cc(resolve_procedure_expression), > > one finds > > > > /* A non-RECURSIVE procedure that is used as procedure expression within > > its > > own body is in danger of being called recursively. */ > > if (is_illegal_recursion (sym, gfc_current_ns)) > > gfc_warning (0, "Non-RECURSIVE procedure %qs at %L is possibly calling" > > " itself recursively. Declare it RECURSIVE or use" > > " %<-frecursive%>", sym->name, >where); > > > > for whatever reason >where is a NULL pointer. If I change > > the above to remove >where, then your code compiles with > > a bunch of warningsi, e.g., > > > > [ 95%] Building Fortran object > > test/oldtuv/CMakeFiles/oldphotolib.dir/util/la_srb.type.F90.o > > /usr/home/sgk/tmp/tuv-x/test/oldtuv/util/la_srb.type.F90:873:28: > > > > 873 | end module la_srb_type > > |1 > > Warning: Non-RECURSIVE procedure 'get_config_array' at (1) is possibly > > calling itself recursively. Declare it RECURSIVE or use '-frecursive' > > > > Unfortunately, without a much smaller example code, I cannot go > > any further in debugging your problem. > > Well that's odd, that function doesn't call itself recursively > If shuffling the USE statements around allows your code to compile, then it is likely that gfortran cannot tell if there is an indirect recursion. gfortran tries to help the user with a warning about **possible** recursion. There is likely an issue with how gfortran is searching namespaces, but % find . -name \*.F90 | xargs wc -l | grep total 96683 total % find . -name \*.f90 | xargs wc -l | grep total 4238 total Chopping 100 kLOC to something that is managable is beyond what I can do.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #20 from Kyle Shores --- (In reply to Steve Kargl from comment #19) > On Fri, Mar 08, 2024 at 05:42:05PM +, kyle.shores44 at gmail dot com > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 > > > > --- Comment #17 from Kyle Shores --- > > I was able to get tuv-x to compile by putting use statements in problematic > > files at the top of the module. In one case, I had to match the use > > ordering to > > the order that the objects were used in the module (unsure if that > > mattered), > > and I also removed an object in a use only statement that wasn't used in > > that > > same file and then it compiled (these last two issues were for the same file > > test/unit/radiator/from_host.F90) > > > > > > It seems your code is hitting a NULL pointer dereference when > generating a warning. In resolve.cc(resolve_procedure_expression), > one finds > > /* A non-RECURSIVE procedure that is used as procedure expression within > its > own body is in danger of being called recursively. */ > if (is_illegal_recursion (sym, gfc_current_ns)) > gfc_warning (0, "Non-RECURSIVE procedure %qs at %L is possibly calling" >" itself recursively. Declare it RECURSIVE or use" >" %<-frecursive%>", sym->name, >where); > > for whatever reason >where is a NULL pointer. If I change > the above to remove >where, then your code compiles with > a bunch of warningsi, e.g., > > [ 95%] Building Fortran object > test/oldtuv/CMakeFiles/oldphotolib.dir/util/la_srb.type.F90.o > /usr/home/sgk/tmp/tuv-x/test/oldtuv/util/la_srb.type.F90:873:28: > > 873 | end module la_srb_type > |1 > Warning: Non-RECURSIVE procedure 'get_config_array' at (1) is possibly > calling itself recursively. Declare it RECURSIVE or use '-frecursive' > > Unfortunately, without a much smaller example code, I cannot go > any further in debugging your problem. Well that's odd, that function doesn't call itself recursively For example get_config_array: https://github.com/NCAR/tuv-x/blob/6930151e3cd89189df4ec046fdf19c02300d4380/src/util/config.F90#L715-L754 Either way, this PR fixes the issue for gcc 13 be moving use statements around https://github.com/NCAR/tuv-x/pull/53. The bug still exists in gcc 13, but for anyone else who encounters this issue, they can try pulling use statements up to the top of the module
[Bug target/113790] [14 Regression][riscv64] ICE in curr_insn_transform, at lra-constraints.cc:4294 since r14-4944-gf55cdce3f8dd85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790 --- Comment #2 from GCC Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:cebbaa2a84586a7345837f74a53b7a0263bf29ee commit r14-9401-gcebbaa2a84586a7345837f74a53b7a0263bf29ee Author: Vladimir N. Makarov Date: Fri Mar 8 14:48:33 2024 -0500 [PR113790][LRA]: Fixing LRA ICE on riscv64 LRA failed to consider all insn alternatives when non-reload pseudo did not get a hard register. This resulted in failure to generate code by LRA. The patch fixes this problem. gcc/ChangeLog: PR target/113790 * lra-assigns.cc (assign_by_spills): Set up all_spilled_pseudos for non-reload pseudo too.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #19 from Steve Kargl --- On Fri, Mar 08, 2024 at 05:42:05PM +, kyle.shores44 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 > > --- Comment #17 from Kyle Shores --- > I was able to get tuv-x to compile by putting use statements in problematic > files at the top of the module. In one case, I had to match the use ordering > to > the order that the objects were used in the module (unsure if that mattered), > and I also removed an object in a use only statement that wasn't used in that > same file and then it compiled (these last two issues were for the same file > test/unit/radiator/from_host.F90) > > It seems your code is hitting a NULL pointer dereference when generating a warning. In resolve.cc(resolve_procedure_expression), one finds /* A non-RECURSIVE procedure that is used as procedure expression within its own body is in danger of being called recursively. */ if (is_illegal_recursion (sym, gfc_current_ns)) gfc_warning (0, "Non-RECURSIVE procedure %qs at %L is possibly calling" " itself recursively. Declare it RECURSIVE or use" " %<-frecursive%>", sym->name, >where); for whatever reason >where is a NULL pointer. If I change the above to remove >where, then your code compiles with a bunch of warningsi, e.g., [ 95%] Building Fortran object test/oldtuv/CMakeFiles/oldphotolib.dir/util/la_srb.type.F90.o /usr/home/sgk/tmp/tuv-x/test/oldtuv/util/la_srb.type.F90:873:28: 873 | end module la_srb_type |1 Warning: Non-RECURSIVE procedure 'get_config_array' at (1) is possibly calling itself recursively. Declare it RECURSIVE or use '-frecursive' Unfortunately, without a much smaller example code, I cannot go any further in debugging your problem.
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 --- Comment #3 from Andrew Pinski --- >Rust will sometimes copy uninitialized memory and I'd like to avoid disabling >this specific warning. Note in C, there are specific rules about copying unitialized memory. Most is it is undefined. It is kinda of odd a "security" language like Rust allows copying unitialized memory at all since a copy should be considered an use ...
[Bug tree-optimization/114287] [13.2.1 Regression] 416.gamess in SPEC CPU 2006 miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114287 --- Comment #2 from Andrew Pinski --- Anyways the fortran code in SPEC is borken. See the long thread in PR 69368 about that.
[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 Andrew Pinski changed: What|Removed |Added CC||manolis.tsamis at vrull dot eu --- Comment #97 from Andrew Pinski --- *** Bug 114287 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/114287] [13.2.1 Regression] 416.gamess in SPEC CPU 2006 miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114287 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- You need -fno-aggressive-loop-optimizations see PR 69368 . *** This bug has been marked as a duplicate of bug 69368 ***
[Bug debug/113777] ICE: in add_child_die_after, at dwarf2out.cc:5785 with -g -fsso-struct=big-endian and __attribute__((__hardbool__))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113777 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2024-03-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Eric Botcazou --- This works with __attribute__((may_alias)) though, so what's special with __attribute__((__hardbool__)) ?
[Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027 --- Comment #11 from Sam James --- Calling it a 11..14 regression as we know 14 is bad and 7.5 is OK, but I can't test 11/12 on an avx512 machine right now.
[Bug ipa/113996] [11/12/13/14 Regression] ICE with LTO at -O2 and above with some Ada code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113996 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #5 from Eric Botcazou --- I'll have a look.
[Bug target/110027] Misaligned vector store on detect_stack_use_after_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027 --- Comment #10 from Christoph Erhardt --- I have just verified that the reproducer program I attached above (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027#c4) still crashes as expected on Fedora 39 with GCC 13.2.1. It's not super-tiny, but it fails reliably. :-)
[Bug c++/110323] [11/12/13/14 Regression] Code for explicit instantiation of template method of template class not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323 --- Comment #9 from Marek Polacek --- Oh and I meant to say it's the DECL_DECLARED_INLINE_P check that makes the difference.
[Bug middle-end/114196] [13/14 Regression] Fixed length vector ICE: in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114196 Patrick O'Neill changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|NEW --- Comment #5 from Patrick O'Neill --- Re-opened since this might want to be backported to 13 for aarch64.
[Bug c++/110323] [11/12/13/14 Regression] Code for explicit instantiation of template method of template class not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323
--- Comment #8 from Marek Polacek ---
(In reply to Patrick Palka from comment #7)
> I noticed we emit the function if we turn it into a non-member:
>
> #include
>
> constexpr int VAL = 1;
>
> template
> void bar(typename std::conditional::type arg) {
> }
>
> template void bar<1>(int arg);
>
> I wonder why this bug seems specific to member functions?
Good question. It's because in this case bar is marked as force_output here:
/* When not optimizing, also output the static functions. (see
PR24561), but don't do so for always_inline functions, functions
declared inline and nested functions. These were optimized out
in the original implementation and it is unclear whether we want
to change the behavior here. */
if (((!opt_for_fn (decl, optimize) || flag_keep_static_functions
|| node->no_reorder)
&& !node->cpp_implicit_alias
&& !DECL_DISREGARD_INLINE_LIMITS (decl)
&& !DECL_DECLARED_INLINE_P (decl)
&& !(DECL_CONTEXT (decl)
&& TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL))
&& !DECL_COMDAT (decl) && !DECL_EXTERNAL (decl))
node->force_output = 1;
and when deciding if we ought to emit the fn in symtab_node::needed_p we do:
/* If the user told us it is used, then it must be so. */
if (force_output)
return true;
With -O the fn isn't emitted.
[Bug middle-end/114196] [13/14 Regression] Fixed length vector ICE: in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114196 Patrick O'Neill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick O'Neill --- Fixed - thanks!
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #18 from Kyle Shores --- (In reply to Steve Kargl from comment #16) > On Fri, Mar 08, 2024 at 04:44:52PM +, kyle.shores44 at gmail dot com > wrote: > > I have not made a smaller example, but we have since removed json-fortran > > as a > > dependency for tuv-x. > > > > So it should be easier to view the failure in tuv-x. I have not made the > > time > > to try to reduce the code to an example, but maybe this could help. > > > > Following this instructions should show an error > > > > git clone https://github.com/NCAR/tuv-x > > cd tuv-x > > mkdir build && cd build > > FC=g++-13 cmake .. > > make > > > > FC=g++-13? > > Should that be gfortran13? > > I get > > % env FC=/usr/home/sgk/work/x/bin/g++ cmake .. > -- The Fortran compiler identification is GNU 14.0.1 > -- The CXX compiler identification is GNU 14.0.1 > -- The C compiler identification is GNU 14.0.1 > -- Detecting Fortran compiler ABI info > -- Detecting Fortran compiler ABI info - failed > -- Check for working Fortran compiler: /usr/home/sgk/work/x/bin/g++ > -- Check for working Fortran compiler: /usr/home/sgk/work/x/bin/g++ - broken > CMake Error at > /usr/local/share/cmake/Modules/CMakeTestFortranCompiler.cmake:59 (message): > The Fortran compiler > > "/usr/home/sgk/work/x/bin/g++" ya, sorry about that. I'm more used to typing g++ than gfortran, muscle memory kicked in
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #17 from Kyle Shores --- I was able to get tuv-x to compile by putting use statements in problematic files at the top of the module. In one case, I had to match the use ordering to the order that the objects were used in the module (unsure if that mattered), and I also removed an object in a use only statement that wasn't used in that same file and then it compiled (these last two issues were for the same file test/unit/radiator/from_host.F90) Here's the PR: https://github.com/NCAR/tuv-x/pull/53
[Bug c++/110323] [11/12/13/14 Regression] Code for explicit instantiation of template method of template class not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #7 from Patrick Palka ---
I noticed we emit the function if we turn it into a non-member:
#include
constexpr int VAL = 1;
template
void bar(typename std::conditional::type arg) {
}
template void bar<1>(int arg);
I wonder why this bug seems specific to member functions?
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #16 from Steve Kargl --- On Fri, Mar 08, 2024 at 04:44:52PM +, kyle.shores44 at gmail dot com wrote: > I have not made a smaller example, but we have since removed json-fortran as a > dependency for tuv-x. > > So it should be easier to view the failure in tuv-x. I have not made the time > to try to reduce the code to an example, but maybe this could help. > > Following this instructions should show an error > > git clone https://github.com/NCAR/tuv-x > cd tuv-x > mkdir build && cd build > FC=g++-13 cmake .. > make > FC=g++-13? Should that be gfortran13? I get % env FC=/usr/home/sgk/work/x/bin/g++ cmake .. -- The Fortran compiler identification is GNU 14.0.1 -- The CXX compiler identification is GNU 14.0.1 -- The C compiler identification is GNU 14.0.1 -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - failed -- Check for working Fortran compiler: /usr/home/sgk/work/x/bin/g++ -- Check for working Fortran compiler: /usr/home/sgk/work/x/bin/g++ - broken CMake Error at /usr/local/share/cmake/Modules/CMakeTestFortranCompiler.cmake:59 (message): The Fortran compiler "/usr/home/sgk/work/x/bin/g++"
[Bug c++/114242] Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 Andreas Fertig changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andreas Fertig --- The behavior of g++ is correct.
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 114242, which changed state. Bug 114242 Summary: Coroutine with lambda-coroutine and operator new does not compile https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug sanitizer/112709] [13/14 Regression] address sanitize and returns_twice causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709
--- Comment #6 from Jakub Jelinek ---
struct S { char c[1024]; };
int foo (int);
__attribute__((returns_twice, noipa)) struct S
bar (int x)
{
(void) x;
struct S s = {};
s.c[42] = 42;
return s;
}
void
baz (struct S *p)
{
foo (1);
*p = bar (0);
}
void
qux (int x, struct S *p)
{
if (x == 25)
x = foo (2);
else if (x == 42)
x = foo (foo (3));
*p = bar (x);
}
void
corge (int x, struct S *p)
{
void *q[] = { &, &, &, & };
if (x == 25)
{
l1:
x = foo (2);
}
else if (x == 42)
{
l2:
x = foo (foo (3));
}
l3:
*p = bar (x);
if (x < 4)
goto *q[x & 3];
}
[Bug sanitizer/112709] [13/14 Regression] address sanitize and returns_twice causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709 --- Comment #5 from Jakub Jelinek --- Adjusted testcase which shows more cases, like multiple edges into the returns_twice bb in addition to the edge from .ABNORMAL_DISPATCHER.
[Bug target/113542] [14 Regression] gcc.target/arm/bics_3.c regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Richard Earnshaw --- Change the test slightly to avoid the insn matching issues. This does leave open the question of how best to optimize the slightly simpler sequences, where we could do even better than we do now, but that's an enhancement and not appropriate for gcc-14.
[Bug target/113542] [14 Regression] gcc.target/arm/bics_3.c regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542 --- Comment #5 from GCC Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:ac829a89fb56cfd914d5e29ed4695e499b0dbc95 commit r14-9399-gac829a89fb56cfd914d5e29ed4695e499b0dbc95 Author: Richard Earnshaw Date: Fri Mar 8 16:23:53 2024 + arm: testsuite: tweak bics_3.c [PR113542] This test was too simple, which meant that the compiler was sometimes able to find a better optimization of the code than using a BICS instruction. Fix this by changing the test slightly to produce a sequence where BICS should always be the preferred solution. gcc/testsuite: PR target/113542 * gcc.target/arm/bics_3.c: Adjust code to something which should always result in BICS.
[Bug sanitizer/112709] [13/14 Regression] address sanitize and returns_twice causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709 --- Comment #4 from Jakub Jelinek --- Thinking about it, I'd say this should be instrumented differently between asan and ubsan. ubsan, which ought to just check whether the pointer is non-NULL and properly aligned, should instrument it in the caller, so for returns_twice on all the edges but the abnormal from .ABNORMAL_DISPATCHER, if there is just one such edge, emit it on that edge, if there are multiple, split the block, add PHIs and move the .ABNORMAL_DISPATCHER edge. Because the function isn't called for the second time actually, the argument where to store it to will be the same in both cases. For asan this is different, while the address to which the result is stored will be the same, the memory might be poisoned in between, so I think we want to instrument that on the callee side when storing into RESULT_DECL.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #15 from Kyle Shores --- To reiterate how this issue can sometimes be resolved, if I take use statements out of subroutines and place them at the top of a module, files can then be compiled.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #14 from Kyle Shores --- I have not made a smaller example, but we have since removed json-fortran as a dependency for tuv-x. So it should be easier to view the failure in tuv-x. I have not made the time to try to reduce the code to an example, but maybe this could help. Following this instructions should show an error git clone https://github.com/NCAR/tuv-x cd tuv-x mkdir build && cd build FC=g++-13 cmake .. make
[Bug rtl-optimization/113660] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fnon-call-exceptions -fharden-control-flow-redundancy on invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113660 --- Comment #1 from Alexandre Oliva --- There's nothing specific about -fharden-control-flow-redundancy here, FWIW. ISTM that it just adds enough EH-related stuff to the function that an EH note gets attached to the impossible asm, a stmt then insn at the end of a block. Then, when vregs realizes that the asm has impossible constraints, it deletes it, and that loses the REG_EH_REGION note attached to it, which triggers the error. I'm not sure what the correct behavior would be, but presumably the note would have to be preserved/moved, or not required.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 103256, which changed state. Bug 103256 Summary: [modules] Internal compiler error after using iostream and filesystem as modules https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103256 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/103256] [modules] Internal compiler error after using iostream and filesystem as modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103256 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- This testcase successfully compiles and runs since GCC 13.
[Bug c++/102536] [modules] ICE Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102536 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- This is fixed for GCC 14 since r14-8962-gce67b75e918bcb.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 102536, which changed state. Bug 102536 Summary: [modules] ICE Error reporting routines re-entered https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102536 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/105489] [modules] Internal Compiler Error for 6 line source code (using C++20 modules) doing nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105489 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Target Milestone|--- |14.0 --- Comment #1 from Patrick Palka --- This seems fixed on trunk at least.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 105489, which changed state. Bug 105489 Summary: [modules] Internal Compiler Error for 6 line source code (using C++20 modules) doing nothing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105489 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 101433, which changed state. Bug 101433 Summary: [modules] Bad File Data from simple function returning std::vector https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101433 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/101433] [modules] Bad File Data from simple function returning std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101433 Patrick Palka changed: What|Removed |Added Target Milestone|11.5|13.0
[Bug c++/101433] [modules] Bad File Data from simple function returning std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101433 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.5 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- GCC 13 + trunk accepts this.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 101224, which changed state. Bug 101224 Summary: Problem with interaction of modules and std::unique_ptr https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101224 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/103499] C++20 modules error: invalid use of non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103499 Patrick Palka changed: What|Removed |Added CC||p.cross13 at yahoo dot com --- Comment #9 from Patrick Palka --- *** Bug 101224 has been marked as a duplicate of this bug. ***
[Bug c++/101224] Problem with interaction of modules and std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101224 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Patrick Palka --- Fixed for GCC 14 by the PR103499 fix. *** This bug has been marked as a duplicate of bug 103499 ***
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 113930, which changed state. Bug 113930 Summary: [modules] checking ICE in register_duplicate when using partitioned modules https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113930 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/113930] [modules] checking ICE in register_duplicate when using partitioned modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113930 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Patrick Palka --- The checking ICE gone after r14-9375 here as well, so let's call this a dup of PR114229. *** This bug has been marked as a duplicate of bug 114229 ***
[Bug c++/114229] [modules] duplicate vtable symbols when including stl in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114229 --- Comment #7 from Patrick Palka --- *** Bug 113930 has been marked as a duplicate of this bug. ***
[Bug c++/110905] GCC rejects constexpr code that may re-initialize union member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110905 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101631 CC||ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- GCC trunk accepts the comment #4 testcase (thanks for the reduction) since r14-4771.
[Bug tree-optimization/107946] [13/14 Regression] 507.cactuBSSN_r regresses by ~9% on znver3 with PGO since r13-3875-g9e11ceef165bc0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug analyzer/108400] [12/13/14 Regression] -Wanalyzer-null-dereference false positive on SoftEtherVPN's src/Cedar/WebUI.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug middle-end/108847] [11/12/13/14 Regression] unnecessary bitwise AND on boolean types and shifting of the "sign" bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
