Thanks Michael (and Jeff)
I shared your view about the mode of the output register not
being reflected to the input until I saw
(asm_operands:SI ("") ("=r") 0 [
(reg:HI 30)
]
then I was unsure whether the input was affecting the output or
the output mode wasn't being reflected to the input.
I had assumed that the r value in any assignment would be
promoted to match the L object, but ...
In any case, I really wanted to ensure my changing the '0' to
'0L' was really the proper fix and not just masking another issue.
Thanks again everyone... Paul.
On 29/08/17 04:01, Michael Matz wrote:
Hi,
On Mon, 28 Aug 2017, Paul S wrote:
I've ported gcc to a 16 bit CPU and have all torture tests passing bar one,
pr52286.c
The offending lines of code are
long a, b = 0;
asm ("" : "=r" (a) : "0" (0));
which should cause zero to be assigned to the "a" SI sized variable.
Inspecting the generated code revealed that zero was only being assigned to
the lower 16 bit half of "a".
ld r2,0
I changed the inline asm statement to
asm ("" : "=r" (a) : "0" (0L));
I think this really is the right fix for this testcase. The testcase was
obviously developed for sizeof(int)>2 targets. The involved constant
doesn't fit into int on those, but the #ifdef case for <=2 targets seems
to have been an afterthought. The asm would have needed the adjustment
that you had to do now.
so it seems that the "0" constraint on the input operand is affecting
the inferred mode of the output register operand ?
Or put another way, the required longness (two regs) of the output
constraints isn't reflected back into the input constraint, yes. For
matching constraints the promoted types of the operands need to match, but
nothing checks this :-/
Ciao,
Michael.