GNU Tools for STM32 14.3.rel1 was miscompiling secp256k1.c at the project default -O2 (secp256k1.c compiles with O1 works)

[dingchaojie]

Last year I integrated secp256k1 algorithm to my cold wallet project link, everything works somoothly with GNU Tools for STM32 13.3.rel1. Today when I recompile the project again with updated STM32 14.3.rel1, it failed on "secp256k1_check_ecdsa: invalid signature". With help of ChatGPT CodeX the issue is fixed as mentioned in the topic. Just share the issue in case other guys also have the same issue

[dingchaojie]

[real-or-random]

I can't see this picture.

[dingchaojie]

[real-or-random]

Can you provide further background?

• The full code.
• The compiler version.
• The ChatGPT CodeX output?

I could imagine that your code has undefined behavior, so it just happens to work -O1 instead of -O2. But if that's a genuine compiler bug, we may be interested to hear about it.

[dingchaojie]

ChatGPT CodeX generated message:

Thanks. I should clarify: I have not reduced this to a minimal reproducer yet, so I am not claiming this is definitely a libsecp256k1 bug or definitely a GCC bug. It may still
be undefined behavior in my integration/build.

Background:

Target:

• STM32L476RG, Cortex-M4
• STM32CubeIDE project
• Bare-metal embedded firmware for an NFC cold-wallet prototype

Compiler:

• Failing rebuild: GNU Tools for STM32 14.3.rel1
• Previously working build: GNU Tools for STM32 13.3.rel1
• Project default optimization: -O2

libsecp256k1 integration:

• Vendored copy of bitcoin-core/secp256k1 in the firmware tree
• Built directly into the STM32 firmware
• The failing translation unit is secp256k1/src/secp256k1.c
• The older project also had SECP256K1_ASM=arm32 enabled

Observed failure:

• On boot, firmware runs crypto self-checks.
• RNG, micro-ecc, Ed25519 all pass.
• secp256k1 self-check generates a private key, derives the public key, signs, then immediately verifies.
• With the GCC 14.3.rel1 rebuild, secp256k1 ECDSA verify fails for the signature generated in the same run.
• The private key, public key, and signature differ each boot because the self-check uses RNG.
• The same project/code previously worked when built with GNU Tools for STM32 13.3.rel1.

Workaround that made the firmware pass again:

1. Removed SECP256K1_ASM=arm32 from the STM32CubeIDE build config.
2. Compiled only secp256k1/src/secp256k1.c with lower optimization:

#if defined(GNUC) && !defined(clang)
#pragma GCC optimize ("O1")
#pragma GCC optimize ("no-strict-aliasing")
#endif

After that, the secp256k1 self-check passed again with GNU Tools for STM32 14.3.rel1.

I agree that this may point to undefined behavior in my integration or build configuration. I have not yet tested the full matrix:

• GCC 14.3 + O2 + no arm32 asm
• GCC 14.3 + O1 + arm32 asm
• GCC 14.3 + O2 + no strict aliasing only
• upstream secp256k1 test suite on the same ARM compiler

So the current status is: workaround confirmed in my firmware, root cause not proven.

The ChatGPT/Codex part:

• Codex helped compare the old working backup and the current project.
• It noticed the toolchain changed from 13.3.rel1 to 14.3.rel1.
• It suggested narrowing the workaround to the secp256k1 translation unit instead of lowering optimization for the whole firmware.
• It also suggested removing SECP256K1_ASM=arm32.
• The final workaround was then tested on hardware and the boot self-check passed.

I can try to produce a small standalone STM32/GCC reproducer if that would be useful.

I would not paste the full wallet project publicly unless you are comfortable exposing it. Better to offer a minimal reproducer. Also avoid saying “this is a GCC bug” until you
test those four matrix cases.

[real-or-random]

Thanks, so if you could produce a minimal reprocuder, this will be very helpful.

[dingchaojie]

secp256k1-stm32-gcc143-reproducer.zip
still CodeX generated ...

[real-or-random]

Thanks.

The README suggests to run these tests:

1. GCC 14.3.rel1, `src/secp256k1.c` at `-O2`, no `SECP256K1_ASM=arm32`
2. GCC 14.3.rel1, `src/secp256k1.c` at `-O1`, no `SECP256K1_ASM=arm32`
3. GCC 14.3.rel1, `src/secp256k1.c` at `-O2 -fno-strict-aliasing`, no `SECP256K1_ASM=arm32`
4. GCC 14.3.rel1, `src/secp256k1.c` at `-O2`, with `SECP256K1_ASM=arm32`
5. GCC 13.3.rel1, same flags as the old working build

Are you willing to test these with your setup and report which test cases pass? We don't have the hardware, so it's much harder for us to test. (We'd need to set up emulators, etc.)

[dingchaojie]

1. GCC 14.3.rel1, -O2, no SECP256K1_ASM=arm32: FAIL
2. GCC 14.3.rel1, secp256k1.c forced to -O1, no SECP256K1_ASM=arm32: PASS
3. GCC 14.3.rel1, -O2 -fno-strict-aliasing, no SECP256K1_ASM=arm32: FAIL
4. GCC 14.3.rel1, -O2, with SECP256K1_ASM=arm32: FAIL
5. GCC 13.3.rel1, -O2, with SECP256K1_ASM=arm32: PASS

For detail test data, please check attachment
secp256k1_test_data-all.zip