From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 549E13858401; Sun, 7 Nov 2021 11:04:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 549E13858401 From: "vries at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/103095] Option to force no overalignment Date: Sun, 07 Nov 2021 11:04:29 +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.0 X-Bugzilla-Keywords: ABI X-Bugzilla-Severity: enhancement X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: REOPENED 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: everconfirmed bug_status resolution cf_reconfirmed_on cf_gcctarget 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 11:04:29 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103095 Tom de Vries changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|RESOLVED |REOPENED Resolution|INVALID |--- Last reconfirmed| |2021-11-07 Target|x86_64 | --- Comment #3 from Tom de Vries --- This is not an x86_64-specific feature request, so removing the x86_64 from= the target field. Thanks for pointing out -malign-data=3Dabi, that's interesting. I think though that it doesn't entirely match the feature request I've described here. Let's call the new one -fprecise-align for the moment. It may be that -fprecise-align should imply -malign-data=3Dabi, I'm not sure, but for the purposes of this discussion, I'll assume not. AFAIU, the -malign-data=3Dabi option has the effect that the compiler doesn= 't require more alignment than required by the abi (which is one interpretatio= n of no overalignment). The additional idea of this feature request is that the toolchain guarantees that if some alignment is required, the actual address fits that alignment,= but not a greater alignment (which is another interpretation of no overalignmen= t.=20 Perhaps there's a better term for what I'm describing here?). To be more concrete, take a float var, according to abi: size 4, alignment = 4. If we use -malign-data=3Dabi and the variable at runtime is found at addres= s 0x8, we consider that the option is obeyed. In contrast, if we use -malign=3Dabi and -fprecise-align, and the variable = at runtime is found at address 0x8, we consider that the latter option is not obeyed.=