------- Comment #4 from jakub at gcc dot gnu dot org 2009-11-09 18:42 -------
For:
(insn 78 77 16 2 rh528639.i:12 (cond_exec (eq (reg:CC 24 cc)
(const_int 0 [0x0]))
(set (reg:SI 0 r0 [orig:133 iftmp.0 ] [133])
(reg:SI 4 r4))) 2367 {neon_vornv2di+77} (expr_list:REG_DEAD (reg:CC
24 cc)
(nil)))
we have MO_VAL_SET with
(concat/v (concat:SI (value/s/u:SI 23753 @0x121b8f0/0x11da460)
(reg:SI 0 r0 [orig:133 iftmp.0 ] [133]))
(set (reg:QI 0 r0 [ iftmp.0 ])
(reg:QI 4 r4)))
The QImode comes from the realdecl being tracked being actually QImode, so
var_lowpart is called on the SET_SRC. VAL_NEEDS_RESOLUTION is true, so
val_resolve (out, val, SET_SRC (uloc), insn); is called which sets a QImode r4
as one of the locations for the VALUE:SI 23753. Then
5309 val_store (out, val, vloc, insn);
is called, and vloc here is SImode, so we have non-matching modes. Not sure
where the bug is, maybe vloc should be QImode as well in that case and
var_lowpart wasn't being called somewhere...
BTW, I wonder how well var-tracking.c handles COND_EXEC, I don't see it ever
mentioned in var-tracking.c, so I assume it handles all the stores as
unconditional.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
