Error building with recent ARM GCC 14.2.Rel1

[josesimoes]

Summary

I was in the process of updating the GCC version in the build tools of .NET nanoFramework to the recent v14.2.Rel1, when I got this on the build:

[build] In file included from E:/GitHub/nf-interpreter/build/_deps/mbedtls-src/library/bignum_core.c:8:
[build] E:/GitHub/nf-interpreter/build/_deps/mbedtls-src/library/bignum_core.c: In function 'mbedtls_mpi_core_mla':
[build] E:/GitHub/nf-interpreter/build/_deps/mbedtls-src/library/common.h:321:14: error: 'asm' operand has impossible constraints or there are not enough registers
[build]   321 | #define asm  __asm__
[build]       |              ^~~~~~~
[build] E:/GitHub/nf-interpreter/build/_deps/mbedtls-src/library/bn_mul.h:785:9: note: in expansion of macro 'asm'
[build]   785 |         asm volatile (
[build]       |         ^~~
[build] E:/GitHub/nf-interpreter/build/_deps/mbedtls-src/library/bn_mul.h:1082:25: note: in expansion of macro 'MULADDC_X2_INIT'
[build]  1082 | #define MULADDC_X4_INIT MULADDC_X2_INIT
[build]       |                         ^~~~~~~~~~~~~~~
[build] E:/GitHub/nf-interpreter/build/_deps/mbedtls-src/library/bn_mul.h:1088:25: note: in expansion of macro 'MULADDC_X4_INIT'
[build]  1088 | #define MULADDC_X8_INIT MULADDC_X4_INIT
[build]       |                         ^~~~~~~~~~~~~~~
[build] E:/GitHub/nf-interpreter/build/_deps/mbedtls-src/library/bignum_core.c:479:9: note: in expansion of macro 'MULADDC_X8_INIT'
[build]   479 |         MULADDC_X8_INIT
[build]       |         ^~~~~~~~~~~~~~~

System information

Mbed TLS version (number or commit id): mbedtls-3.6.0
Operating system and version:
Configuration (if not default, please attach mbedtls_config.h):
Compiler and options (if you used a pre-built binary, please indicate how you obtained it):
Additional environment information:

Expected behavior

Actual behavior

Steps to reproduce

Additional information

This happened only by changing the GCC to the new version. Before that we were using v13.3.rel1. No other changes in code or build configuration.

[ronald-cron-arm]

Thanks for the report. It seems the compilation error occurs when compiling bignum_core.c. Could you provide the compilation command for that file with all the compilation flags?

[josesimoes]

No problem!
This is the PR with the changes nanoframework/nf-interpreter#3061
You can look at the build log here

[ronald-cron-arm]

Thanks, I can see the compilation command for bignum_core.c and the compilation flags. We should be able to reproduce.

[mpg]

I can reproduce locally with:

arm-none-eabi-gcc-14.2.1 -Iinclude -mcpu=cortex-m7 -mfloat-abi=hard -c library/bignum_core.c

OTOH, the following succeed:

arm-none-eabi-gcc-14.2.1 -Iinclude -mcpu=cortex-m7 -c library/bignum_core.c
arm-none-eabi-gcc-13.2.1 -Iinclude -mcpu=cortex-m7 -mfloat-abi=hard -c library/bignum_core.c

So, the problem is indeed new to ARM GCC 14, and only happens with -mfloat-abi=hard - that last bit is quite a surprise for me, as I can't see how this is related. Perhaps float-abi hard makes some register(s) reserved? But then why does it only happen with version 14 of the toolchain - I'd think the ABI would be a lot more stable than that.

[mpg]

Oh well, the following also succeeds:

arm-none-eabi-gcc-14.2.1 -Iinclude -O1 -mcpu=cortex-m7 -mfloat-abi=hard -c library/bignum_core.c 

or any non-zero optimisation level really (tried 1, 2, 3, s, g).

Would it make sense to just disable asm at -O0? We're already doing so in some places for similar reasons. (Edit: actually here we're not disabling asm, we're preserving r7 (by clobbering r10 instead), but in another place (and in previous versions) we are/were disabling the asm entirely.)

Oh it looks very similar to the place I just linked to, as the following also works:

arm-none-eabi-gcc-14.2.1 -Iinclude -fomit-frame-pointer -mcpu=cortex-m7 -mfloat-abi=hard -c library/bignum_core.c

Which might explain the influence of -mfloat-abi=hard: it might influence the default setting of -f[no-]omit-frame-pointer differently between versions of the toolchain - that would be my guess at least.