From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1C1443857423; Tue, 25 Oct 2022 12:46:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1C1443857423 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1666701977; bh=Y51SaYuJKcAGHIiRGwQ1CTGoT1fAsvzyaUc3TOIuz0M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=geUML6VYgXnIbMziz2iiS6ibHb1Lx2V6BIj+e3YZ3rjoLwPVOvv0g6/IcH9I1OQg5 KfSqjHsr9xSaNaXhEUTlN7NCA8JYnxVBG3cneynMdO/rm4Wdbq1OD4SPnpFpWoZFCr 3W/cj6Apwq+aA2ip0EqirPkfjROyGrlj5fhSxzk0= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/107389] Alignment not inferred from type at -O0 Date: Tue, 25 Oct 2022 12:46:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: unknown X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org 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: keywords cc 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=3D107389 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |missed-optimization CC| |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Yes, that's definitely a no-go since pointer types have no semantic meaning= s. I don't understand s390 assembly much but I see calls to __atomic_load_16@P= LT for both -O0 and -O2 so I wonder if it is the testcase you are seeing a difference for? If __atomic_load_n (and others) imply certain alignment of the pointer arguments then their expanders have to explicitely add that. But I guess there's no requirement that __builtin_atomic_load (p, 16) has p 16 byte aligned? There was talks to "rectify" specified type alignment for pointers in function arguments but IIRC that has never materialized. See duplicate bugreports about memcpy involving properly align-typed function parameters. That said, iff __atomic_* constraints are not exploited we should do that.=