[clang] [Clang][Windows] Preserve x86_fp80 and vector alignment under #pragma pack. (PR #208256)

Oliver Hunt via cfe-commits cfe-commits at lists.llvm.org
Tue Aug 11 13:09:03 PDT 2026


================
@@ -2539,9 +2548,22 @@ TypeInfo ASTContext::getTypeInfoImpl(const Type *T) const {
     const ASTRecordLayout &Layout = getASTRecordLayout(RD);
     Width = toBits(Layout.getSize());
     Align = toBits(Layout.getAlignment());
-    AlignRequirement = RD->hasAttr<AlignedAttr>()
-                           ? AlignRequirementKind::RequiredByRecord
-                           : AlignRequirementKind::None;
+    // Check if the record has an aligned attribute, or if it contains
+    // fields with ABI-required alignment (e.g., x86_fp80).
+    if (RD->hasAttr<AlignedAttr>()) {
+      AlignRequirement = AlignRequirementKind::RequiredByRecord;
+    } else {
+      // Check if any field has RequiredByABI alignment requirement.
+      // If so, propagate it to the record.
----------------
ojhunt wrote:

The different behavior here is not relevant. The packing behavior is defined by the target platform, not the compiler.

I cannot emphasize this enough: comparing object layout across different operating systems is not relevant to correctness. Correctness is defined as matching what the target platform specifies as the ABI.

As a few examples to make this clear

```cpp
struct MatchingUnderlyingStorage {
  int first: 7;
  int second: 25;
};

struct MismatchingUnderlyingStorage {
  char first: 7;
  int second: 25;
};
```

`sizeof(MatchingUnderlyingStorage)` is 4 bytes on windows and linux, but `sizeof(MismatchingUnderlyingStorage)` is 8 bytes on windows, and 4 bytes on linux. This is correct behavior.

or as another case

```cpp
enum Foo {
  Foo1 = 0,
  Foo2 = 1
};

struct EnumHolder {
  Foo f: 1;
};

result = EnumHolder{Foo2}.f;
```

On linux `result` is `Foo2`, on windows it is -1. This is again *correct*.

Different results on different operating systems is not a sign of incorrect behavior.

https://github.com/llvm/llvm-project/pull/208256


More information about the cfe-commits mailing list