-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SOLARIS 11, SPARC] compilation failed #1080
Comments
Can you try compiling with |
@tankf33der Can you post the output of this command?
This will help us to improve the autodetection, see https://stackoverflow.com/a/2224357. (Judging from the error message, I assume |
|
Helped to compile, tests passed.
|
Thanks for the quick reply. The output does not include So the following two are not equivalent if
We took the code partly from https://github.com/rofl0r/endianness.h/blob/9853923246b065a3b52d2c43835f3819a62c7199/endianness.h#L52L73 and changed it slightly. The original code The only place where we have endianness-dependant code is when reading input data for SHA256: https://github.com/bitcoin-core/secp256k1/blob/master/src/hash_impl.h#L54 So we could:
I think we should try 3 and benchmark if it really has an effect on performance. If not, we should favor that approach. It's by far the least brittle. Otherwise 2 could be a solid option, too. For 1, I'm a little bit concerned by the observation in [1] that the macro approach really led to misdetection cases. We have the self-tests but they're not always run (static context). Unfortunately there seems to be no portable C89 expression that we could use in [1] https://fastcompression.blogspot.com/2014/11/portability-woes-endianess-and_24.html |
Recent compilers compile the two new functions to very efficient code on various platforms. In particular, already GCC >= 5 and clang >= 4 understand do this for the read function, which is the one critical for performance (called 16 times per SHA256 transform). Fixes bitcoin-core#1080.
37d3692 tests: Add tests for _read_be32 and _write_be32 (Tim Ruffing) 616b43d util: Remove endianness detection (Tim Ruffing) 8d89b9e hash: Make code agnostic of endianness (Tim Ruffing) Pull request description: Recent compilers compile the two new functions to very efficient code on various platforms. In particular, already GCC >= 5 and clang >= 5 understand do this for the read function, which is the one critical for performance (called 16 times per SHA256 transform). Fixes #1080. ACKs for top commit: sipa: utACK 37d3692 robot-dreams: ACK 37d3692 Tree-SHA512: b03cec67756fb3c94ca8e7e06f974136050efd5065f392dba6eed4d0dbe61dbf93dad054627267225bac1bb302bb025f86588612ef7d4beeb834466686c70b8f
Recent compilers compile the two new functions to very efficient code on various platforms. In particular, already GCC >= 5 and clang >= 5 understand do this for the read function, which is the one critical for performance (called 16 times per SHA256 transform). Fixes bitcoin-core#1080.
Recent compilers compile the two new functions to very efficient code on various platforms. In particular, already GCC >= 5 and clang >= 5 understand do this for the read function, which is the one critical for performance (called 16 times per SHA256 transform). Fixes bitcoin-core#1080.
The text was updated successfully, but these errors were encountered: