Hi Jeffrey, > On SPARC, 64-bit words can be loaded and saved through one of two > instructions. The first version is optimized, the second version is > not. The optimized version is faster, but the 64-bit words have to be > aligned to 8-byte boundaries. I.e., naturally aligned. > > If you are performing unaligned loads of 64-bit words, then you have > to specify the compiler option -xmemalign=4i. -xmemalign=4i will > generate the inefficient load, but it will avoid the SIGBUS. > > When using the default toolchain settings, -xmemalign=8s is used, > which causes the toolchain to use the optimized loads. I think that is > what is generating the UBsan finding "runtime error: member access > within misaligned address ... which requires 8 byte alignment." > > Also see "3.4.151 –xmemalign[=<a><b>]", > <https://docs.oracle.com/cd/E37069_01/html/E37076/aevkc.html>, in the > Solaris manual.
I know that you wanted to be helpful, but these details about the Solaris Studio compiler option miss the point. * We are discussing a problem on Linux/glibc/sparc64 [1][2], not on Solaris. * For gnulib, we generally assume the default compiler settings, except for a few essentially mandatory options on some platforms.[3] It is futile to even read about '-xmemalign' and similar options because - Gnulib cannot make use of them without excessive Makefile.am hacking. - Gnulib cannot support people who use such arbitrary compiler options, as it would vastly increase the number of build configurations that we would need to support. We can use compiler-specific built-ins, intrinsics, asms, etc. because that is limited to the .h / .c file source code. But not compiler-specific options. Bruno [1] https://lists.gnu.org/archive/html/bug-texinfo/2023-11/msg00000.html [2] https://lists.gnu.org/archive/html/bug-texinfo/2023-11/msg00076.html [3] https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration