[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 --- Comment #12 from Andrew Pinski --- Updated patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686055.html
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 --- Comment #11 from Andrew Pinski --- s/TYPE_SIZE_UNIT/TYPE_SIZE/g in the patch :).
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 --- Comment #10 from Andrew Pinski --- (In reply to Andrew Pinski from comment #9) > Created attachment 61598 [details] > includes the fix for libstdc++ +FAIL: g++.dg/lto/pr107467 cp_lto_pr107467_0.o-cp_lto_pr107467_0.o link, -O2 -fno-strict-aliasing -flto (internal compiler error: in int_mode_for_mode, at stor-layout.cc:408) /home/apinski/src/upstream-gcc-isel/gcc/gcc/testsuite/g++.dg/lto/pr107467_0.C: In function 'get_const.isra': /home/apinski/src/upstream-gcc-isel/gcc/gcc/testsuite/g++.dg/lto/pr107467_0.C:21:34: internal compiler error: in int_mode_for_mode, at stor-layout.cc:408 0x239a6cf internal_error(char const*, ...) /home/apinski/src/upstream-gcc-isel/gcc/gcc/diagnostic-global-context.cc:517 0x995a93 fancy_abort(char const*, int, char const*) /home/apinski/src/upstream-gcc-isel/gcc/gcc/diagnostic.cc:1803 0x81b74f int_mode_for_mode(machine_mode) /home/apinski/src/upstream-gcc-isel/gcc/gcc/stor-layout.cc:408 0xb624e7 extract_bit_field_1 /home/apinski/src/upstream-gcc-isel/gcc/gcc/expmed.cc:1823 0xb63419 extract_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**) /home/apinski/src/upstream-gcc-isel/gcc/gcc/expmed.cc:2174 0xb67562 store_integral_bit_field /home/apinski/src/upstream-gcc-isel/gcc/gcc/expmed.cc:1012 0xb67562 store_bit_field_1 /home/apinski/src/upstream-gcc-isel/gcc/gcc/expmed.cc:891 0xb67f70 store_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>, machine_mode, rtx_def*, bool, bool) /home/apinski/src/upstream-gcc-isel/gcc/gcc/expmed.cc:1213 0xb947e2 store_field /home/apinski/src/upstream-gcc-isel/gcc/gcc/expr.cc:8336 0xb90293 expand_assignment(tree_node*, tree_node*, bool) /home/apinski/src/upstream-gcc-isel/gcc/gcc/expr.cc:6334 0xb90293 expand_assignment(tree_node*, tree_node*, bool) /home/apinski/src/upstream-gcc-isel/gcc/gcc/expr.cc:5971 0xa50e19 expand_gimple_stmt_1 /home/apinski/src/upstream-gcc-isel/gcc/gcc/cfgexpand.cc:4289 0xa50e19 expand_gimple_stmt /home/apinski/src/upstream-gcc-isel/gcc/gcc/cfgexpand.cc:4370 0xa522fe expand_gimple_basic_block /home/apinski/src/upstream-gcc-isel/gcc/gcc/cfgexpand.cc:6433 0xa54316 execute /home/apinski/src/upstream-gcc-isel/gcc/gcc/cfgexpand.cc:7181 Wait I think I see my mistake, confusing bytes and bits.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459
Andrew Pinski changed:
What|Removed |Added
Attachment #61597|0 |1
is obsolete||
--- Comment #9 from Andrew Pinski ---
Created attachment 61598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61598&action=edit
includes the fix for libstdc++
Simplified C testcase for the ICE:
```
struct a {
int b;
int c;
int d;
} e;
void f() {
e = (struct a){};
}
```
Basically if we have a target, then using 0 is wrong, we should continue on to
the store_constructor part.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > Created attachment 61597 [details] > New patch based on the review > > This version is in testing but it works and maybe it is better than before. Causes an ICE while building libstdc++. trying to reduce it and seeing what can be done about it.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 Andrew Pinski changed: What|Removed |Added Attachment #61589|0 |1 is obsolete|| --- Comment #7 from Andrew Pinski --- Created attachment 61597 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61597&action=edit New patch based on the review This version is in testing but it works and maybe it is better than before.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 --- Comment #6 from Andrew Pinski --- I should mention this shows up more after PR 87901 too.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 Andrew Pinski changed: What|Removed |Added Attachment #61586|0 |1 is obsolete|| --- Comment #5 from Andrew Pinski --- Created attachment 61589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61589&action=edit Full patch with testcase Tested for aarch64-linux, just need to do x86_64 now.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 --- Comment #4 from Andrew Pinski --- Created attachment 61586 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61586&action=edit Fix which needs testcases and full testing This is the fix which I will finishing up tomorrow.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Andrew Pinski ---
Actually the problem is not what is listed in comment #2 at all but rather
the expansion of
;; MEM [(struct array *)&buffer + 1B] = {};
Being so bad.
```
(insn 6 5 7 (set (mem/c:HI (plus:DI (reg/f:DI 93 virtual-stack-vars)
(const_int -16 [0xfff0])) [0 S2 A128])
(const_int 0 [0])) "/app/example.cpp":7:9 -1
(nil))
(insn 7 6 9 (set (mem/c:QI (plus:DI (reg/f:DI 93 virtual-stack-vars)
(const_int -14 [0xfff2])) [0 S1 A16])
(const_int 0 [0])) "/app/example.cpp":7:9 -1
(nil))
(insn 9 7 10 (set (reg:SI 105)
(mem/c:SI (plus:DI (reg/f:DI 93 virtual-stack-vars)
(const_int -16 [0xfff0])) [0 S4 A128]))
"/app/example.cpp":7:9 -1
(nil))
(insn 10 9 11 (parallel [
(set (reg:SI 104)
(and:SI (reg:SI 105)
(const_int 16777215 [0xff])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":7:9 -1
(expr_list:REG_EQUAL (and:SI (mem/c:SI (plus:DI (reg/f:DI 93
virtual-stack-vars)
(const_int -16 [0xfff0])) [0 S4 A128])
(const_int 16777215 [0xff]))
(nil)))
(insn 11 10 12 (parallel [
(set (reg:SI 106)
(ashift:SI (reg:SI 104)
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":7:9 -1
(nil))
(insn 12 11 13 (set (reg:SI 107)
(zero_extend:SI (subreg:QI (reg/v:SI 99 [ bufferD.3003 ]) 0)))
"/app/example.cpp":7:9 -1
(nil))
(insn 13 12 14 (parallel [
(set (reg:SI 108)
(ior:SI (reg:SI 107)
(reg:SI 106)))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":7:9 -1
(nil))
(insn 14 13 0 (set (reg/v:SI 99 [ bufferD.3003 ])
(reg:SI 108)) "/app/example.cpp":7:9 -1
(nil))
```
Note:
```
auto sample2(char c) {
array buffer = {0, 0, 0, 0};
buffer.data[0] = c;
return buffer;
}
```
is just as bad:
movl.LC0(%rip), %eax
movb%dil, %al
LC0 is just 0s.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 Richard Biener changed: What|Removed |Added Target||x86_64-*-* --- Comment #2 from Richard Biener --- Also on x86_64 I see DECL_ALIGN getting in the way of NRV as we seem to up alignment on locals aggressively but DECL_RETURN stays at what the ABI mandates. Of course in this case !aggregate_value_p (result, current_function_decl) anyway, still this extra copy could be elided IMHO. Usually this is the job of SRA. We also perform some of this coalescing in the frontend/gimplifier IIRC, not sure what prevents it here.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed||2023-06-28 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed, there might be a dup of this linked to PR 101926 .
