> So really we could do all manner of nasty things here and watch all > manner of performance results and cool coredumps and it would be fun to > try. However the option -xmemalign=8s will enforce "There should be no > misaligned accesses in the program". And "the default for all v9 architectures is -xmemalign=8s". Other values are effectively for those who are lazy enough to fix broken code taken from x86[_64]. Values other than 8s are also kind of "whole application" things, i.e. it would be inappropriate to compile a *library* [such as OpenSSL] with any other flag than -xmemalign=8s. Which is why it *is* the default, has to be, so you don't have to actually specify it. In other words assertion that not specifying -xmemalign=8s is somehow wrong is not actually substantiated. Not specifying it is perfectly appropriate. On related note OpenSSL is periodically tested on RISC platforms and misalignment issues get ironed out in time. [That's why I wondered how come it went unnoticed so far.] Just in case for reference, default for 32-bit code is 8i. I assume that it implies 4s, which would be consistent with expected RISC behaviour, i.e. SIGBUS on register-sized loads/stores. Though there is ambiguity. One would expect SIGBUG on double-precision floating point load/store even on 32-bit system. So does 8i mean that it would actually tolerate misaligned doubles? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
