Naveen Hurugalawadi wrote:
> The definition of constraint 'X' allows all operands.
> `X' - Any operand whatsoever is allowed.
> However, invalid memory operands should not be valid input for 'X'.
>
> Please find attached the patch "X_constraint.patch" which ignores=20
> invalid memory operands in constraint 'X'.
I don't think this is correct. The internals documentation says:
"Any operand whatsoever is allowed, even if it does not satisfy
@code{general_operand}."
I've seen "X" constraints used in inline assembly where this is
indeed intended. The point of an "X" constraint is usually to
mark the assembly statement as having a data dependency on the
operand, without actually directly refering to operand (e.g.
because it is acessed implicitly/indirectly).
If the compiler were to reject certain forms of memory operands,
it would have to generate extra code (e.g. reloading an address);
but because "X" operands are not actually refered to by the
assembler code, any such preparatory code would be unnecessary.
[ The only operand forms that ought to be rejected even for "X"
are those that imply side-effects like pre-increment. ]
> Fixes the ICE gcc.dg/torture/asm-subreg-1.c on aarch64.
Clearly the compiler shouldn't crash either, but I guess it
really ought to be possible to fix this problem elsewhere.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
[email protected]
