arm: Rename internal ARM ROL/ROR/LSR/LSL functions with a SIMDE prefix. #1252
Conversation
There was a problem hiding this comment.
@Syonyk Can you look at https://github.com/simd-everywhere/simde/actions/runs/12564616889/job/35027928010?pr=1252#step:8:2991 ?
../test/arm/neon/../../../simde/arm/neon/sm3.h: In function ‘test_simde_vsm3tt1aq_u32’:
../test/arm/neon/../../../simde/arm/neon/sm3.h:70:7: error: ‘r_.values’ may be used uninitialized [-Werror=maybe-uninitialized]
70 | r_,
|
Yeah, I'll take a look at that - not sure why my changes would have impacted that, but it shouldn't be a hard fix. |
Thank you!
Welcome to the wonderful world of testing with many different compilers & configurations 😭 😃 |
|
Possible fix for it pushed, I don't see r_ being used uninitialized, but I've set it to zero on creation. Now to see if the tests all pass... |
Maybe better to use If you want the experience, you could also file a bug with the GCC people, letting them know of this spurious warning in gcc-14 using the riscv64 target and |
|
I see that... let me try your approach. I'll gate it on RISCV for now, and see if that makes things happy. |
|
Does this pass at head? I don't know how to kick off a set of tests against current master. |
I'm going to debug locally and I'll force push any needed changes; thank you! |
Most SIMDe functions have the SIMDE_ or simde_ prefix internally. Several of the ARM hash functions do not have this prefix, and this means that the standard names of ROR32/ROL32 can conflict with other projects using the library. This is purely a cosmetic change with internal function renaming. It changes no external interfaces, simply removes a source of potential conflict with other projects that have similarly named macros.
…eon SM3 functions r_.values _is_ being initialized. The compiler is missing this. Possible compiler bug. Co-authored-by: Michael R. Crusoe <[email protected]>
Most SIMDe functions/macros/etc have the SIMDE_ or simde_ prefix internally. Several of the ARM hash functions do not have this prefix on their ROR/ROL/LSR/LSL macros, and this means that the standard names of can conflict with other projects using the library. This was an issue on an internal tool using the library, and while SIMDe undefines the macros after the file uses them, this is not compatible with other declarations of these macros before the SIMDe library is included.
This is purely a cosmetic change with internal function renaming. It changes no external interfaces, simply removes a source of potential conflict with other projects that have similarly named macros. Tests have not been changed, as there are no changes that would require test modification.