[clang] Fix mis alignment fp80 (PR #208256)

[Zahira Ammarguellat via cfe-commits]

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