This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gcc torture test pr52286.c


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));

(note the change 0 to 0L) which caused the correct code to be generated ...

ld    r2,0
ld    r3,0

Curious, I performed an RTL dump and found that without the trailing 'L' following the '0' the output of the expand pass looks like this ...

(insn 6 5 7 2 (set (reg:SI 29 [ a ])
        (asm_operands:SI ("") ("=r") 0 [
                (reg:HI 30)
            ]
             [
(asm_input:HI ("0") ../gcc/testsuite/gcc.c-torture/execute/pr52286.c:14)
            ]

compared to

(insn 6 5 7 2 (set (reg:SI 29 [ a ])
        (asm_operands:SI ("") ("=r") 0 [
                (reg:SI 30)
            ]
             [
(asm_input:SI ("0") ../gcc/testsuite/gcc.c-torture/execute/pr52286.c:14)
            ]

when 0L is used instead of just 0.

so it seems that the "0" constraint on the input operand is affecting the inferred mode of the output register operand ?

Am I reading this correctly or have I missed something ?

Thanks, Paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]