You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When compiling AArch64 targets without hard-float support e.g., -march=armv8-a+nofp+nosimd -mgeneral-regs-only, LLVM generates invalid assembly for C variadic functions when passed floating-point values.
When passing a floating-point value to a variadic function, it passes it as an integer register, and saves it to the integer register block. When fetching the value, it fetches it from the floating register block, which is uninitialized.
It looks like the problem is in the method AArch64ABIInfo::EmitAAPCSVAArg, the check to see if a register is floating or integer only looks at the base type. The check also needs to take into account additional target information such as general-regs-only being enabled.
This has been fixed by #84146. When using -mabi=aapcs-soft (which is now required when using floating-point types without floating-point registers) the generated code for double is the same as for long: https://godbolt.org/z/s1EfPnTTs
When compiling AArch64 targets without hard-float support e.g.,
-march=armv8-a+nofp+nosimd -mgeneral-regs-only
, LLVM generates invalid assembly for C variadic functions when passed floating-point values.When passing a floating-point value to a variadic function, it passes it as an integer register, and saves it to the integer register block. When fetching the value, it fetches it from the floating register block, which is uninitialized.
Keith Packard over at picolibc discovered the problem and provided a minimal example:
https://godbolt.org/z/5Y9qEq437
It looks like the problem is in the method
AArch64ABIInfo::EmitAAPCSVAArg
, the check to see if a register is floating or integer only looks at the base type. The check also needs to take into account additional target information such as general-regs-only being enabled.Additional information:
picolibc/picolibc#467
The text was updated successfully, but these errors were encountered: