https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78575
--- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #5)
> It doesn't unfortunately.
Just a wild guess, in PR78547 we trip at:
#2 0x00000000011b4fbb in loc_cmp (x=0x2aaaae9330a8, y=0x2aaaae930fd8) at
../../git/gcc/gcc/var-tracking.c:3417
3417 gcc_assert (GET_MODE (x) == GET_MODE (y));
(gdb) p debug_rtx (y)
(mem/c:V1TI (value/u:DI 1:1 @0x2ab27f0/0x2a485f0) [1 u128_3+0 S16 A128])
$9 = void
(gdb) p debug_rtx (x)
(mem/c:TI (value/u:DI 1:1 @0x2ab27f0/0x2a485f0) [1 u128_3+0 S16 A128])
$10 = void
and your patch handles registers in:
+ rtx *loc = DF_REF_LOC (ref);
+ if (REG_P (*loc) && GET_MODE (*loc) == V1TImode)
+ {
+ *loc = gen_rtx_SUBREG (TImode, *loc, 0);
+ changed = true;
+ }
maybe we need to handle memory locations here, too?
