From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DC0B13858CDB; Sat, 25 Nov 2023 17:40:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DC0B13858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1700934026; bh=YzAtcAhtzubJTzkbB0mvv9uVa+wwJKj17+zG/EMd7I0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bCHENHgMFJrRLE1NdulOrQxHrQhDaBwU2v+Svx8O9unZqDPENZDs3I6zTQfWX7iIT 87FiDZ6AkKGsW7L3S8Gl49kdNPxkU6vk1OR9a0vKRkE8whkpftUUH2gqm6fHh2BJvP caEYpLqJbH+eVwRnZZkXM+tpcvk4OfG+qtuB12xI= From: "gabrielopcode at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used Date: Sat, 25 Nov 2023 17:40:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 12.2.0 X-Bugzilla-Keywords: ABI, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: gabrielopcode at gmail 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: Message-ID: In-Reply-To: References: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111107 --- Comment #10 from Gabriel Iv=C4=83ncescu --- (In reply to Alexander Monakov from comment #9) > -mpreferred-stack-boundary=3Dn means that functions consume stack in > increments of 2**n. This is sufficient to ensure that once stack is align= ed > to that boundary, it will keep it without the need for dynamic realignmen= t. >=20 > -mincoming-stack-boundary specifies the guaranteed alignment on entry. If > the function needs to place local variables with greater alignment > requirement on the stack, it has perform dynamic realignment. Yeah, but on 32-bit x86 Windows ABI, the stack is only guaranteed to be ali= gned to 4 bytes (mincoming-stack-boundary=3D2). We don't control the callers, an= d apps compiled with MSVC (i.e. the majority of them, including Windows' own libraries) only adhere to this alignment, nothing more than that. Therefore -mincoming-stack-boundary=3D2 should be the default on MinGW for = this target. In general, setting -mpreferred-stack-boundary=3D2 is also preferable becau= se the vast majority of functions do *not* use SSE or AVX or whatever. If you set -mpreferred-stack-boundary=3D4 it will *always* align the stack on entry, a= nd that's simply too much overhead. It's better only for functions that actual= ly need it to do it. The point is, -mpreferred-stack-boundary=3D2 (and consequently -mincoming-stack-boundary=3D2) is the default on MSVC and Windows 32-bit x8= 6 ABI, and that's for a reason. MinGW should follow that. By default, at least. I've compiled Wine with those options for years now without trouble.=