[GCC 8,2] Aarch64-none-eabi UCVTF problem

[GCC 8,2] Aarch64-none-eabi UCVTF problem

[Mihailo Stojanovic]

Hi all,

ARM Cortex-A53 CPU stalls during the execution of
a bare metal application containing the following
assembly instruction:

ucvtf    s0, s0

According to the A64 ISA, UCVTF instruction doesn't
allow floating-point registers as source registers, but
executing the same instruction in qemu-arm user mode
yields a correct result. I am wondering whether this
is a compiler bug, or is there something I am missing?

Source code was compiled by the aarch64-none-eabi-gcc
(version 8.2.0) compiler, with -O3 and -fno-strict-aliasing
flags.

I am currently working on creating a minimal reproducer,
so I could provide it if necessary.

Note that manually modifying the assembly file to use
a general-purpose register as a source fixes this behaviour.

Best regards,
Mihailo

Re: [GCC 8,2] Aarch64-none-eabi UCVTF problem

[Richard Earnshaw]

On 18/12/2020 13:39, Mihailo Stojanovic via Gcc-help wrote:
> Hi all,
> 
> ARM Cortex-A53 CPU stalls during the execution of
> a bare metal application containing the following
> assembly instruction:
> 
> ucvtf    s0, s0
> 
> According to the A64 ISA, UCVTF instruction doesn't
> allow floating-point registers as source registers, but
> executing the same instruction in qemu-arm user mode
> yields a correct result. I am wondering whether this
> is a compiler bug, or is there something I am missing?

I think you're missing that there are multiple variants of this instruction.

ucvtf s0, s0

assembles to the opcode

0x7e21d800

which by my reckoning matches to the single-precision sub-variant of
Scalar single-precision and double-precision clause of
  C7.2.353      UCVTF (vector, integer)
In the current armv8 ARM ARM.  This variant is a single lane instance of
the general vector conversion operation.

If the operation is stalling and your processor is running 'bare-metal'
have you enabled the floating-point/simd unit on the processor.  If you
haven't then the CPU will take an undefined instruction trap.

> Source code was compiled by the aarch64-none-eabi-gcc
> (version 8.2.0) compiler, with -O3 and -fno-strict-aliasing
> flags.
> 
> I am currently working on creating a minimal reproducer,
> so I could provide it if necessary.
> 
> Note that manually modifying the assembly file to use
> a general-purpose register as a source fixes this behaviour.
> 
> Best regards,
> Mihailo
> 

R.