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.
