zahiraam wrote: > The way pragma pack works in MSVC is that the pragma overrides the compiler's > alignment computation for builtin types... but not for types which have an > explicit alignas()/__declspec(align())/etc. (In clang, this is > FieldRequiredAlignment.) > > The reason the STL's usage of pragma pack doesn't blow up on MSVC is that > MSVC doesn't have any builtin types with alignment greater than 8. So > `#pragma pack(8)` is effectively a no-op on MSVC. But not for clang, which > has various builtin types with higher alignment. (`long double`, `__m128`, > etc.) > > Maybe Microsoft STL maintainers have some insight about for why these pragmas > are there; CC @StephanTLavavej .
The `memcpy` alignment comes from the `alloca`'s alignment - when we allocate `std::array<Klass, 16>` where `Klass` contains `x86_fp80`, the `alloca` gets `8-byte` alignment (due to `pragma pack`). The `memcpy` operations then use this`8-byte` aligned address with `x86_fp80` operations that require` 16-byte` alignment, causing the crash. The root issue is that the `struct`'s layout alignment is `8 bytes`, so the `alloca` respects that. If we only "fixed" the `memcpy` alignment without fixing the `struct` layout, we'd just be lying about the alignment - the `struct` would still be at an `8-byte` aligned address. On Linux without `-mlong-double-80`, `long double` is typically `__float128` or `double`, which don't have the same `movaps` correctness requirement. The issue manifests on Windows because `MSVC STL` headers use `#pragma pack(8)` among other things. However, you're right that the fix shouldn't be `Windows`-specific. If a user uses `-mlong-double-80` with `#pragma pack` on Linux, they'd hit the same issue. Should I remove the Windows-specific conditions? https://github.com/llvm/llvm-project/pull/208256 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
