gcc torture test pr52286.c

[Paul S]

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.
>