From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 86A7D385DC26; Thu,  2 Apr 2020 02:28:41 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 86A7D385DC26
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1585794521;
 bh=vdb4KRduexYmkjO81+srTvvWkNcwvNO1k8AOBAipvQc=;
 h=From:To:Subject:Date:From;
 b=iXQyeiVy+mkfSsH1iZNGiYVizJt0labKOILdtfzlN+2FvEzHEguUWDllbvg2im1fC
 Z/kkNKKDTIqugJIUN27YKWJ8ietBEDW1ONQRqxh1lgk2PSiGoNR4+RT8cDfsHTVsPR
 hWQL7Hcssvg8pGc1zNpqKDZsh8Ez1LoF5U8qfjY4=
From: "chen3.liu at intel dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: =?UTF-8?B?W0J1ZyB0YXJnZXQvOTQ0NTJdIE5ldzogSTM4NiBBQkk6IEhvdyB0?=
 =?UTF-8?B?byBkZXRlcm1pbmUgdGhlIGFsaWdubWVudCBvZiBzdHJ1Y3Qgb3IgdW5pb24g?=
 =?UTF-8?B?ZGV0ZXJtaW5lZCB3aGVuIHBhc3NlcyB0aGVtIG9uIHN0YWNr77yf?=
Date: Thu, 02 Apr 2020 02:28:41 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: chen3.liu at intel dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-94452-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <http://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 02:28:41 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94452

            Bug ID: 94452
           Summary: I386 ABI: How to determine the alignment of struct or
                    union determined when passes them on stack=EF=BC=9F
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chen3.liu at intel dot com
  Target Milestone: ---

For example:

#include <immintrin.h>

typedef __attribute__((aligned(16))) int alignedint;
struct __attribute__((aligned(64))) X {
    int x;
//    __m128 y;
// alignedint y;
};

void g(int x, struct X);
_Static_assert(_Alignof(struct X) =3D=3D 64);

struct X gx;

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

In this case, the gx  will align to 4 byte. If we uncomment either the __m1=
28
or alignedint y, and  gcc aligns to 64 bytes.

The logic of gcc alignment we now think is as below:=20

StackAlignmentForType(T):
1.      If T's alignment is < 16 bytes(any type, including struct and union=
),
return 4.
2.      If T is a struct/union/array type, then:
=E2=80=A2       recursively calculate on each member's type ( ignores any
attribute((aligned(N))) directly on the fields of a struct, but not those t=
hat
appear on typedefs, or the underlying types ?).
=E2=80=A2       If all of those calls return alignments < 16, then return 4.
3.      Otherwise, return the alignment of T.

Is this logic correct for gcc?  We want to make clang compatible with gcc.

Thanks.=