Matthew Malcomson <matmal01 at gcc dot> changed:

           What    |Removed                     |Added
             Target|                            |arm
      Known to work|                            |4.9.0

--- Comment #1 from Matthew Malcomson <matmal01 at gcc dot> ---
The "*neon_mov<mode>" patterns for 128 bit sized quantities uses the "Dn"
constraint to match vmov.f32 and vmov.i<vec-width> patterns.

This constraint boils down to using the `neon_immediate_valid` function.
Once the constraint has matched, the output C statement asserts the same

The output C statement calls `neon_immediate_valid` with the mode taken from
iterator, while the constraint takes the mode from the operand.

In the above testcase the operand is a CONST_INT, which means the constraint
passes VOIDmode (treated the same as DImode in `neon_immediate_valid`), while
the C statement passes TImode (the mode of the iterator).

This causes second call to `neon_immediate_valid` to fail as the value provided
is only valid in DImode but not TImode, and that causes the ICE.

The attached patch splits the original "Dn" constraint into three new
constraints, "DN" for TImode CONST_INT, "Dn" for DImode CONST_INT, and "Dm" for
This requires one extra alternative in the "*neon_mov<mode>" patterns, but
makes it clear from the constraint what mode is being used.

We use the "DN" constraint for the define_insn that matches TImode values, and
hence avoid the above problem.

Reply via email to