https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW Target Milestone|--- |11.0 Target| |aarch64 Priority|P3 |P1 --- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #6) > Started with r11-165. > Perhaps decls set through MEM_REF even if it sets them in full size, but > their promoted mode is wider, shouldn't have the DECL_GIMPLE_REG_P bit set? Huh, no, that's for sure not a "fix". I presume _14 = MEM[(char * {ref-all})p_10(D) + ivtmp.8_4 * 1]; MEM[(char * {ref-all})&x] = _14; _16 = MEM[(char * {ref-all})q_11(D) + ivtmp.8_4 * 1]; MEM[(char * {ref-all})&y] = _16; x.0_1 = x; y.1_2 = y; if (x.0_1 != y.1_2) is problematical, expanded as (insn 21 20 0 (set (zero_extract:SI (reg/v:SI 99 [ y ]) (const_int 8 [0x8]) (const_int 0 [0])) (reg:SI 107)) "t.c":9:7 -1 (nil)) ;; if (x.0_1 != y.1_2) (insn 22 21 23 (set (reg:CC 66 cc) (compare:CC (reg/v:SI 98 [ x ]) (reg/v:SI 99 [ y ]))) "t.c":11:10 -1 (nil)) where the (set (zero_extract:SI ...) ..) leaves the upper parts of the register unspecified (old content) but the compare now uses the full register. IMHO the compare using the full register w/o first zero/sign-extending it has the bug. Who guarantees the inits of such promoted regs are properly extended? I'd say a fix in expansion of the non-MEM_P store would be OK-ish (the generated code is also suboptimal I guess). Note the bug would show up for VECTOR_TYPEs with integer modes in case we expand those as promoted reg even before the change in question. Semantic differences between GIMPLE and RTL are bad :/ How do we expand x = _14; ? I guess one could carefully craft a testcase for this case.