From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B816C3858C53; Tue, 22 Aug 2023 21:41:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B816C3858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1692740485; bh=cZRYihD7lV6RiNgqLM18Z0RXUeMo1YjjKwQhYxVb+BE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Bf3qSjD1Xv/TFzWz5Noy9sOdFxZH4PXwfAnRaSR9Pb2FgiwBaz+yzZ/obz3KzvaZ7 ybVAntw7v08mIrQM4w3o6aWl1fqz8tLLIqWdw1vPxZmRXnUBnEuLctRyvvvqEcQpcL oIuvLsWWDorko4njFGkbl9FKwHgv8h6lnpzysud4= From: "zfigura at codeweavers 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: Tue, 22 Aug 2023 21:41:25 +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: zfigura at codeweavers 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 #2 from Zebediah Figura --- (In reply to Andrew Pinski from comment #1) > This on purpose, it is only callbacks (from libc) and main that needs the > realignment here. I don't understand what you mean? It's not just libc and main that needs th= is. As mentioned, this is *the* 32-bit x86 ABI on Windows. Win32 programs compi= led with MSVC don't assume 16-byte alignment (if they do now, they didn't historically, and we do regularly run across programs in Wine that do not k= eep the stack aligned to 16 bytes). And again, gcc does not, as a blanket statement, assume 16-byte stack align= ment for i386. If we think that gcc *should* assume 16-byte stack alignment, the= n we should also get rid of the existing code in gcc that assumes 4-byte stack alignment. I think this is a bad idea, for the reasons I've been describing, but if that's the decision then let's please at least be consistent and cle= ar about it. I'm sure this is something of a canned response since, as you say, this iss= ue has been reported before (although I couldn't actually find any such report= s, just from searching the gcc Bugzilla?). I wouldn't report this as a bug per= se if gcc wasn't currently being *inconsistent* about what it assumes the stack alignment is.=