Adds an option "malign-pass-aggregate" to make the alignment of the struct and union parameters compatible with the default gcc

[LiuChen3]

Summary

According to i386 System V ABI 2.1: Structures and unions assume the alignment
of their most strictly aligned component. But current implementation always
takes them as 4-byte aligned which will result in incorrect code, e.g:

 1 #include <immintrin.h>
 2 typedef union {
 3         int d[4];
 4         __m128 m;
 5 } M128;
 6 extern void foo(int, ...);
 7 void test(void)
 8 {
 9   M128 a;
10   foo(1, a);
11   foo(1, a.m);
12 }

The first call (line 10) takes the second arg as 4-byte aligned while the
second call (line 11) takes the second arg as 16-byte aligned. There is
oxymoron for the alignment of the 2 calls because they should be the same.

This patch adds an option to pass struct and union following i386 System V ABI and
apply it to Linux only since other System V OS (e.g Darwin, PS4 and FreeBSD) don't
want to spend any effort dealing with the ramifications of ABI breaks at present.

[rnk]

This is, obviously, an ABI break. I think Sony would probably want you to preserve the existing behavior of intentionally underaligning such byval parameters for PS4 targets. +@rjmccall in case he has other ABI thoughts.

lib/CodeGen/TargetInfo.cpp

1496 ↗

(On Diff #195292)

@rjmccall, does this comment need updating in an AVX world?

[rjmccall]

I suspect Darwin also doesn't want to take this. We care very little about 32-bit Intel, and part of caring very little is not wanting to spend any effort dealing with the ramifications of ABI breaks. That would apply both to the rule in general and to the vector rule specifically. @dexonsmith, agreed?

[dexonsmith]

In D60748#1472829, @rjmccall wrote:

I suspect Darwin also doesn't want to take this. We care very little about 32-bit Intel, and part of caring very little is not wanting to spend any effort dealing with the ramifications of ABI breaks. That would apply both to the rule in general and to the vector rule specifically. @dexonsmith, agreed?

Agreed.

[wxiao3]

Ok, I have excluded Darwin and PS4 for the changes.
The fix mainly targets at Linux so that we can compile a project with parts by GCC and parts by LLVM given that they follow the same ABI.

[wxiao3]

Any other comments?

[dim]

Please also exclude FreeBSD from these changes, since we care a lot about backwards compatibility, and specifically about alignment requirements. (We have run into many issues in our ports collection where upstream assumes everything is 16-byte aligned on i386, which is *NOT* ABI compliant.)

[dim]

In fact, it is probably better to turn the OS check around, e.g. *only* increase the alignment for Linux, and nowhere else.

[wxiao3]

Yes, the ABI bug will cause SEGV in Linux where a lot of libraries are built by GCC.
I have restricted the fix to Linux only in the latest revision.

Any other comments?

[wxiao3]

Ok for merge now?

[rjmccall]

Yes, LGTM.

[krytarowski]

lib/CodeGen/TargetInfo.cpp

1501 ↗

(On Diff #201840)

Darwin and BSD are not System V.

CC: @joerg @mgorny for NetBSD. Do we need to do something here?

[joerg]

lib/CodeGen/TargetInfo.cpp

1501 ↗

(On Diff #201840)

It's a misnomer. The ABI standard for i386 was the SysV ABI before GNU decided to silently break the stack alignment and calling it the new ABI. That said, I'm not sure how much copy-by-value of vector types actually happens and that's the only situation affected by this.

[jyknight]

I don't think this was correct (where by "correct", there, I mean "what GCC does", as this patch is intended to match GCC behavior).

I think this change may well break more cases than it fixes, so IMO, this should be reverted, until it's implemented properly.

Consider one example:

#include <immintrin.h>

typedef __attribute__((aligned(16))) int alignedint;

struct __attribute__((aligned(64))) X {
    int x;
//    alignedint y;
//    __m128 y;
};
void g(int x, struct X);

_Static_assert(_Alignof(struct X) == 64);

struct X gx;

void f() {
    g(1, gx);
}

Note that when compiling this as is GCC does _not_ align X when calling g(). But, as of this change, now clang does. If you uncomment either the __m128 or alignedint lines, and now GCC aligns to 64 bytes too.

This is because GCC's algorithm is a whole lot more complex than what you've implemented. See its function ix86_function_arg_boundary.

The way I interpret GCC, it's doing effectively the following:
StackAlignmentForType(T):

1. If T's alignment is < 16 bytes, return 4.
2. If T is a struct/union/array type, then:
   • recursively call StackAlignmentForType() on each member's type (note -- this ignores any attribute((aligned(N))) directly on the fields of a struct, but not those that appear on typedefs, or the underlying types).
   • If all of those calls return alignments < 16, then return 4.
3. Otherwise, return the alignment of T.

[pengfei]

Reverted by https://reviews.llvm.org/rL362186

[wxiao3]

Thanks for the information!
We have reverted the patch and will resubmit it when we have a complete fix.

[RKSimon]

In D60748#1524443, @wxiao3 wrote:

Thanks for the information!
We have reverted the patch and will resubmit it when we have a complete fix.

@wxiao3 Have you investigated this yet?

[wxiao3]

@RKSimon I'm busy with other stuff and my colleague: LiuChen3 will help finish the work.

[emaste]

In D60748#1499756, @dim wrote:

Please also exclude FreeBSD from these changes, since we care a lot about backwards compatibility, and specifically about alignment requirements. (We have run into many issues in our ports collection where upstream assumes everything is 16-byte aligned on i386, which is *NOT* ABI compliant.)

@dim that said I think we'd expect to be able to mix gcc- and clang-built objects, and it seems this is addressing somewhat of a corner case?

[kib]

In fact, can we have an option controlling this ? Does it have anything to do with -malign-data gcc switch ?

We do want to be able to optionally generate code ABI-compatible with modern gcc, per user discretion.

[LiuChen3]

In D60748#1681178, @kib wrote:

In fact, can we have an option controlling this ? Does it have anything to do with -malign-data gcc switch ?

We do want to be able to optionally generate code ABI-compatible with modern gcc, per user discretion.

I found -malign-data option only affects data alignment in data segment. -malign-data has three options: “compat”,“ abi” and “cacheline”. The default in GCC is ”compat,“ and clang’s behavior is consistent with "abi".
And the data alignment on stack and parameters Passing on stack is not affected. This patch only affects the alignment of passing parameter.
Should we add an option just like -malign-data?

[LiuChen3]

rebase.

[LiuChen3]

Ping?

[rjmccall]

Oh, I see you just updated your patch months ago without ever mentioning that it was ready for review.

It sounds to me like GCC retroactively added a switch specifying which version of the ABI to follow on this point, somewhat confusingly called -malign-data. That's probably the right move here for us, too, especially since FreeBSD says they'd like to use it. That also means the condition of when to use your new logic will have to change; basically, we need a CodeGenOption for this that will default to the old ABI, and the driver will pass down a different default on Linux.

[LiuChen3]

In D60748#1924794, @rjmccall wrote:

Oh, I see you just updated your patch months ago without ever mentioning that it was ready for review.

It sounds to me like GCC retroactively added a switch specifying which version of the ABI to follow on this point, somewhat confusingly called -malign-data. That's probably the right move here for us, too, especially since FreeBSD says they'd like to use it. That also means the condition of when to use your new logic will have to change; basically, we need a CodeGenOption for this that will default to the old ABI, and the driver will pass down a different default on Linux.

Thanks for review.
-malign-data is another topic. Just like what I said above, at least -malign-data will not affect the calling convention of struct and union. I agree with you that adding an option to control this new logi. I'll working on it.

[rjmccall]

In D60748#1925907, @LiuChen3 wrote:

In D60748#1924794, @rjmccall wrote:

Oh, I see you just updated your patch months ago without ever mentioning that it was ready for review.

It sounds to me like GCC retroactively added a switch specifying which version of the ABI to follow on this point, somewhat confusingly called -malign-data. That's probably the right move here for us, too, especially since FreeBSD says they'd like to use it. That also means the condition of when to use your new logic will have to change; basically, we need a CodeGenOption for this that will default to the old ABI, and the driver will pass down a different default on Linux.

Thanks for review.
-malign-data is another topic. Just like what I said above, at least -malign-data will not affect the calling convention of struct and union. I agree with you that adding an option to control this new logi. I'll working on it.

Oh, I see, sorry. Yes, I think a different option would be good. We can debate the name when the patch is ready.

[LiuChen3]

Add an option "malign-pass-aggregate" to compatible with gcc default passing struct and union.

[jyknight]

Since the ABI this is trying to match is not documented literally anywhere, I think we need to have some confidence that what this implements is actually the same as what GCC does. While I wrote up what I think the algorithm is, without some sort of script to allow testing it against a bunch of examples, I wouldn't say I'm confident of its correctness.

I'm not sure if you can reverse-engineer what the alignment must have been from the assembly output, or from some debug flags. Or if maybe doing something silly like modifying the source to insert a printf would be the best method to test this.

clang/lib/CodeGen/TargetInfo.cpp

1544–1546

This comment isn't useful. While it may be what the System V ABI document says, that's clearly incorreect, and is not what the code is or should be doing. Please document what is actually implemented, instead.

1561

Also needs to call getTypeStackAlignInBytes?

1569

I think this is wrong and that it should only return Align. The computation of the alignment of the elements is only to see if their alignment is >= 16.

If the alignment of the elements' types is >= 16, but the alignment of the structure is less than the alignment of one of its elements (e.g. due to __attribute__ packed), we should return the alignment of the structure.

1572

If I understood GCC's algorithm correctly, I think this needs to come first?

clang/test/CodeGen/x86_32-align-linux.cpp

10

Confused me that this was a different X1 than in the test-case above. I'm not sure why the tests need to be duplicated here in a .cpp file in the first place?

[rnk]

clang/include/clang/Basic/LangOptions.def

353

If only codegen needs to know, a CodeGenOption would be better.

clang/lib/CodeGen/TargetInfo.cpp

1556

Any time you crack open a record to look at the fields, the code is probably wrong the first time you write it. :( In this case, I suspect you are not looking at base classes. Consider:

struct A {
  MyAlignedType Field;
};
struct B : A {};
void passbyval(B o);

[LiuChen3]

In D60748#1931440, @jyknight wrote:

Since the ABI this is trying to match is not documented literally anywhere, I think we need to have some confidence that what this implements is actually the same as what GCC does. While I wrote up what I think the algorithm is, without some sort of script to allow testing it against a bunch of examples, I wouldn't say I'm confident of its correctness.

I'm not sure if you can reverse-engineer what the alignment must have been from the assembly output, or from some debug flags. Or if maybe doing something silly like modifying the source to insert a printf would be the best method to test this.

I think at least the initial patch is correct.

clang/include/clang/Basic/LangOptions.def

353

The backend does not need this option information.

clang/lib/CodeGen/TargetInfo.cpp

1544–1546

Sorry I forget to change it.

1556

I'm not sure if I understand what you mean.

typedef __attribute__((aligned(16))) int alignedint16;
typedef __attribute__((aligned(64))) int alignedint64;
struct __attribute__((aligned(64))) X2 {
  struct  __attribute__((aligned(32))) {
    int a1;
    alignedint16 a2;
  } a;
  int b;
};
struct B : X2{};
void test(B b)
{
  std::cout << b.a.a2 << std::endl;
}

This can pass.

clang/test/CodeGen/x86_32-align-linux.cpp

10

Sorry that I don't know much about front-end tests. I thought class, struct and union all need to be tested.

[LiuChen3]

I think at least the initial patch is correct.

I re-read your comment above, please ignore this sentence. Sorry for the noise.
My question now is that since we cannot guarantee that we are doing the right thing, is this patch necessary?

[LiuChen3]

clang/lib/CodeGen/TargetInfo.cpp

1561

I think this is enough.

struct __attribute__((aligned(16))) X6 {
 int x;
 struct X1 x1[5];
// alignedint64 y;
};

void test(int a, struct X6 x6)
{
  printf(%u\n", __alignof__(x6));
}

This will output 64.

1569

I write a test, I do n’t know if it matches your meaning.

struct __attribute__((aligned(4))) X6 {
 int x;
 alignedint64 y;
};

void test(int a, struct X6 x6)
{
  printf("%u\n", __alignof__(x6));
}

The output of gcc is 64.

If we use packed attribute:

struct __attribute__((packed)) X6 {
 int x;
 alignedint64 y;
};

Both gcc and clang with this patch output "1". And I found that the packed struct is not processed by this function.
So I think it should return the MaxAlignment .

1572

You mean it should be ?

if (MaxAlignment < 16)
  retrun 4
else
 return std::max(MaxAlignment, Align);

[LiuChen3]

clang/lib/CodeGen/TargetInfo.cpp

1572

I found that the test I wrote above was wrong. Sorry for the noise.

[RKSimon]

@wxiao3 @LiuChen3 Are you still looking at this or should it be abandoned?

[LiuChen3]

In D60748#2310148, @RKSimon wrote:

@wxiao3 @LiuChen3 Are you still looking at this or should it be abandoned?

I will abandon this patch for it is difficult to confirm the behavior of gcc.

clang/include/clang/Basic/LangOptions.def

 LANGOPT(FixedPoint, 1, 0, "fixed point types")
 LANGOPT(PaddingOnUnsignedFixedPoint, 1, 0,
         "unsigned fixed point types having one extra padding bit")
 
 LANGOPT(RegisterStaticDestructors, 1, 1, "Register C++ static destructors")
 
 COMPATIBLE_VALUE_LANGOPT(MaxTokens, 32, 0, "Max number of tokens per TU or 0")
 
+VALUE_LANGOPT(AlignPassingAggregate, 1, 0, "Compatible with gcc default passing struct and union (x86 only).")
+
 #undef LANGOPT
 #undef COMPATIBLE_LANGOPT
 #undef BENIGN_LANGOPT
 #undef ENUM_LANGOPT
 #undef COMPATIBLE_ENUM_LANGOPT
 #undef BENIGN_ENUM_LANGOPT
 #undef VALUE_LANGOPT
 #undef COMPATIBLE_VALUE_LANGOPT
 #undef BENIGN_VALUE_LANGOPT

clang/include/clang/Driver/Options.td

 def mmcu_EQ : Joined<["-"], "mmcu=">, Group<m_Group>;
 def mdynamic_no_pic : Joined<["-"], "mdynamic-no-pic">, Group<m_Group>;
 def mfix_and_continue : Flag<["-"], "mfix-and-continue">, Group<clang_ignored_m_Group>;
 def mieee_fp : Flag<["-"], "mieee-fp">, Group<clang_ignored_m_Group>;
 def minline_all_stringops : Flag<["-"], "minline-all-stringops">, Group<clang_ignored_m_Group>;
 def mno_inline_all_stringops : Flag<["-"], "mno-inline-all-stringops">, Group<clang_ignored_m_Group>;
 def malign_double : Flag<["-"], "malign-double">, Group<m_Group>, Flags<[CC1Option]>,
   HelpText<"Align doubles to two words in structs (x86 only)">;
+def malign_pass_aggregate : Flag<["-"], "malign-pass-aggregate">, Group<f_Group>, Flags<[CC1Option]>,
+  HelpText<"Compatible with gcc default passing struct and union (x86 only).">;
 def mfloat_abi_EQ : Joined<["-"], "mfloat-abi=">, Group<m_Group>, Values<"soft,softfp,hard">;
 def mfpmath_EQ : Joined<["-"], "mfpmath=">, Group<m_Group>;
 def mfpu_EQ : Joined<["-"], "mfpu=">, Group<m_Group>;
 def mhwdiv_EQ : Joined<["-"], "mhwdiv=">, Group<m_Group>;
 def mhwmult_EQ : Joined<["-"], "mhwmult=">, Group<m_Group>;
 def mglobal_merge : Flag<["-"], "mglobal-merge">, Group<m_Group>, Flags<[CC1Option]>,
   HelpText<"Enable merging of globals">;
 def mhard_float : Flag<["-"], "mhard-float">, Group<m_Group>;

clang/lib/CodeGen/TargetInfo.cpp

class X86_32ABIInfo : public SwiftABIInfo {
   bool updateFreeRegs(QualType Ty, CCState &State) const;
 
   bool shouldAggregateUseDirect(QualType Ty, CCState &State, bool &InReg,
                                 bool &NeedsPadding) const;
   bool shouldPrimitiveUseInReg(QualType Ty, CCState &State) const;
 
   bool canExpandIndirectArgument(QualType Ty) const;
 
+  bool alignAggregate() const {
+    return getTarget().getTriple().isOSLinux() &&
+           getContext().getLangOpts().AlignPassingAggregate;
+  }
   /// Rewrite the function info so that all memory arguments use
   /// inalloca.
   void rewriteWithInAlloca(CGFunctionInfo &FI) const;
 
   void addFieldToArgStruct(SmallVector<llvm::Type *, 6> &FrameFields,
                            CharUnits &StackOffset, ABIArgInfo &Info,
                            QualType Type) const;
   void runVectorCallFirstPass(CGFunctionInfo &FI, CCState &State) const;

 
 unsigned X86_32ABIInfo::getTypeStackAlignInBytes(QualType Ty,
                                                  unsigned Align) const {
   // Otherwise, if the alignment is less than or equal to the minimum ABI
   // alignment, just use the default; the backend will handle this.
   if (Align <= MinABIStackAlignInBytes)
     return 0; // Use default alignment.
 
+  // Check if we need to compatible with gcc default(Linux only).
+  if (alignAggregate()) {
+    // i386 System V ABI 2.1: Structures and unions assume the alignment of their
+    // most strictly aligned component.
+    //
+    // Exclude other System V OS (e.g Darwin, PS4 and FreeBSD) since we don't
+    // want to spend any effort dealing with the ramifications of ABI breaks.
+    //
+    // If the type is a struct/union/class type
+    if (const RecordType *RT = Ty->getAs<RecordType>()) {
+      unsigned MaxAlignment = 0;
+      const RecordDecl *RD = RT->getDecl();
+
+      for (RecordDecl::field_iterator i = RD->field_begin(), e = RD->field_end();
+           i != e; ++i) {
+        QualType QT = i->getType();
+        unsigned TempAlignment = 0;
+        if (isAggregateTypeForABI(QT)) {
+          if (const auto *AT = QT->getAsArrayTypeUnsafe())
+            TempAlignment = getContext().getTypeAlign(AT->getElementType()) / 8;
+          else // recursively to get each type's alignment
+            TempAlignment = getTypeStackAlignInBytes(QT, getContext().getTypeAlign(QT) / 8);
+        } else
+          TempAlignment = getContext().getTypeAlign(QT) / 8;
+        MaxAlignment = std::max(MaxAlignment, TempAlignment);
+      }
+      if (MaxAlignment >= 16)
+        return std::max(MaxAlignment, Align);
+      else // return 4 when all the type alignments less than 16 bytes
+        return 4;
+    } else if (Align < 16)
+      return MinABIStackAlignInBytes;
+    else  // Otherwise
+      return Align;
+  }
   // On non-Darwin, the stack type alignment is always 4.
-  if (!IsDarwinVectorABI) {
+  else if (!IsDarwinVectorABI) {
     // Set explicit alignment, since we may need to realign the top.
     return MinABIStackAlignInBytes;
   }
 
   // Otherwise, if the type contains an SSE vector type, the alignment is 16.
   if (Align >= 16 && (isSSEVectorType(getContext(), Ty) ||
                       isRecordWithSSEVectorType(getContext(), Ty)))
     return 16;

clang/lib/Frontend/CompilerInvocation.cpp

#include "clang/Basic/LangStandards.def"
   Opts.ApplePragmaPack = Args.hasArg(OPT_fapple_pragma_pack);
   Opts.ModuleName = std::string(Args.getLastArgValue(OPT_fmodule_name_EQ));
   Opts.CurrentModule = Opts.ModuleName;
   Opts.AppExt = Args.hasArg(OPT_fapplication_extension);
   Opts.ModuleFeatures = Args.getAllArgValues(OPT_fmodule_feature);
   llvm::sort(Opts.ModuleFeatures);
   Opts.NativeHalfType |= Args.hasArg(OPT_fnative_half_type);
   Opts.NativeHalfArgsAndReturns |= Args.hasArg(OPT_fnative_half_arguments_and_returns);
+  Opts.AlignPassingAggregate = Args.hasArg(OPT_malign_pass_aggregate);
   // Enable HalfArgsAndReturns if present in Args or if NativeHalfArgsAndReturns
   // is enabled.
   Opts.HalfArgsAndReturns = Args.hasArg(OPT_fallow_half_arguments_and_returns)
                             | Opts.NativeHalfArgsAndReturns;
   Opts.GNUAsm = !Args.hasArg(OPT_fno_gnu_inline_asm);
   Opts.Cmse = Args.hasArg(OPT_mcmse); // Armv8-M Security Extensions
 
   // __declspec is enabled by default for the PS4 by the driver, and also

clang/test/CodeGen/x86_32-align-linux.c

+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu -malign-pass-aggregate -emit-llvm -o %t %s
+// RUN: FileCheck < %t %s
+
+#include <immintrin.h>
+
+typedef union {
+  int d[4];
+   __m128 m;
+} M128;
+
+typedef __attribute__((aligned(16))) int alignedint16;
+typedef __attribute__((aligned(64))) int alignedint64;
+
+struct __attribute__((aligned(64))) X1 {
+ struct  __attribute__((aligned(32))) {
+  int a1;
+ } a;
+ int b;
+};
+
+
+struct __attribute__((aligned(64))) X2 {
+ struct  __attribute__((aligned(32))) {
+  int a1;
+  alignedint16 a2;
+ } a;
+ int b;
+};
+
+struct __attribute__((aligned(32))) X3 {
+ struct __attribute__((aligned(64))) {
+  int a1;
+  alignedint16 a2;
+ } a;
+ int b;
+};
+
+struct __attribute__((aligned(16))) X4 {
+ struct  __attribute__((aligned(32))) {
+  int a1;
+  alignedint64 a2;
+ } a;
+ int b;
+};
+
+struct __attribute__((aligned(64))) X5 {
+  int x;
+};
+
+struct __attribute__((aligned(64))) X6 {
+ int x;
+ alignedint64 y;
+};
+
+union U1 {
+ struct __attribute__((aligned(32))) {
+  int i;
+  __m128 m;
+ };
+ int b;
+};
+
+extern void foo(int, ...);
+
+M128 a;
+struct X1 x1;
+struct X2 x2;
+struct X3 x3;
+struct X4 x4;
+struct X5 x5;
+struct X6 x6;
+union  U1 u1;
+
+// CHECK-LABEL: define void @test
+// CHECK: entry:
+// CHECK: call void (i32, ...) @foo(i32 1, %union.M128* byval(%union.M128) align 16
+// CHECK: call void (i32, ...) @foo(i32 1, <4 x float>
+// CHECK: call void (i32, ...) @foo(i32 1, %struct.X1* byval(%struct.X1) align 4
+// CHECK: call void (i32, ...) @foo(i32 1, %struct.X2* byval(%struct.X2) align 64
+// CHECK: call void (i32, ...) @foo(i32 1, %struct.X3* byval(%struct.X3) align 64
+// CHECK: call void (i32, ...) @foo(i32 1, %struct.X4* byval(%struct.X4) align 64
+// CHECK: call void (i32, ...) @foo(i32 1, %struct.X5* byval(%struct.X5) align 4
+// CHECK: call void (i32, ...) @foo(i32 1, %struct.X6* byval(%struct.X6) align 64
+// CHECK: call void (i32, ...) @foo(i32 1, %union.U1* byval(%union.U1) align 32
+void test(void)
+{
+  foo(1, a);
+  foo(1, a.m);
+  foo(1, x1);
+  foo(1, x2);
+  foo(1, x3);
+  foo(1, x4);
+  foo(1, x5);
+  foo(1, x6);
+  foo(1, u1);
+}

clang/test/CodeGen/x86_32-align-linux.cpp

+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu -malign-pass-aggregate -emit-llvm -o %t %s
+// RUN: FileCheck < %t %s
+
+#include <immintrin.h>
+
+typedef __attribute__((aligned(16))) int alignedint16;
+typedef __attribute__((aligned(64))) int alignedint64;
+
+class __attribute__((aligned(64))) X1 {
+  class  __attribute__((aligned(32))) {
+   __m128 a1;
+  } a;
+  int b;
+};
+
+class __attribute__((aligned(64))) X2 {
+  class  __attribute__((aligned(32))) {
+    int a1;
+    alignedint16 a2;
+  } a;
+  int b;
+};
+
+class __attribute__((aligned(32))) X3 {
+  class __attribute__((aligned(64))) {
+    int a1;
+    alignedint16 a2;
+  } a;
+ int b;
+};
+
+class __attribute__((aligned(16))) X4 {
+  class  __attribute__((aligned(32))) {
+    int a1;
+    alignedint64 a2;
+  } a;
+  int b;
+};
+
+class __attribute__((aligned(64))) X5 {
+  int x;
+};
+
+class __attribute__((aligned(64))) X6 {
+  int x;
+  alignedint64 y;
+};
+
+extern void foo(int, ...);
+
+class X1 x1;
+class X2 x2;
+class X3 x3;
+class X4 x4;
+class X5 x5;
+class X6 x6;
+
+// CHECK-LABEL: define void @_Z4testv()
+// CHECK: entry:
+// CHECK: call void (i32, ...) @_Z3fooiz(i32 1, %class.X1* byval(%class.X1) align 64
+// CHECK: call void (i32, ...) @_Z3fooiz(i32 1, %class.X2* byval(%class.X2) align 64
+// CHECK: call void (i32, ...) @_Z3fooiz(i32 1, %class.X3* byval(%class.X3) align 64
+// CHECK: call void (i32, ...) @_Z3fooiz(i32 1, %class.X4* byval(%class.X4) align 64
+// CHECK: call void (i32, ...) @_Z3fooiz(i32 1, %class.X5* byval(%class.X5) align 4
+// CHECK: call void (i32, ...) @_Z3fooiz(i32 1, %class.X6* byval(%class.X6) align 64
+
+void test(void)
+{
+  foo(1, x1);
+  foo(1, x2);
+  foo(1, x3);
+  foo(1, x4);
+  foo(1, x5);
+  foo(1, x6);
+}