Skip to content

Conversation

@maribu
Copy link

@maribu maribu commented Nov 30, 2025

It seems that older versions of GCC did not optimize memory accesses across function calls. That made function calls an implicit memory barrier, even when the function implementation was part of the current compilation unit and the compiler could infer that a function did not touch memory.

With inline assembly, the compiler assumes the clobber list to be exhaustive. If no memory clobber is given and a function does not touch memory except for the inline assembly, the compiler may assume that a function does not change memory contents and optimize accordingly.

Adding the required memory clobbers fixes incorrect computations of vli_mmod_fast_secp256r1() on AVR GCC 15.2.0.

Fixes #236

It seems that older versions of GCC did not optimize memory accesses
across function calls. That made function calls an implicit memory
barrier, even when the function implementation was part of the current
compilation unit and the compiler could infer that a function did not
touch memory.

With inline assembly, the compiler assumes the clobber list to be
exhaustive. If no memory clobber is given and a function does not touch
memory except for the inline assembly, the compiler may assume that
a function does not change memory contents and optimize accordingly.

Adding the required memory clobbers fixes incorrect computations of
`vli_mmod_fast_secp256r1()` on AVR GCC 15.2.0.
@kmackay
Copy link
Owner

kmackay commented Nov 30, 2025

I wonder if using dummy memory operands would be preferable (ie, provide more accurate constraints to the compiler). It looks like the syntax should be "m" (*(const uECC_word_t (*)[num_words]) left) for the input operands, and "=m" (*(uECC_word_t (*)[num_words]) result) for output operands. Let me know if you want to try this (I don't have an AVR device to test with anymore). If not, I'm fine with merging this as-is.

@maribu
Copy link
Author

maribu commented Nov 30, 2025

Thx for the pointer, I'll give it a spin :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

vli_mmod_fast_secp256r1() computes incorrect result on AVR with GCC 15.2.0

2 participants