From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D4AC2385842D; Thu, 2 Sep 2021 10:24:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D4AC2385842D From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/88085] User alignments on var decls not respected if smaller than type alignment Date: Thu, 02 Sep 2021 10:24:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 9.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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 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: Thu, 02 Sep 2021 10:24:43 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D88085 --- Comment #15 from rguenther at suse dot de --- On Thu, 2 Sep 2021, petro.karashchenko at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D88085 >=20 > --- Comment #13 from Petro Karashchenko --- > Sorry that I brought some confusion. I was reading some latest comments a= nd > didn't fully payed attention to a ticket description. The reason for my c= omment > is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94662 that was closed a= s a > duplicate of this issue. >=20 > For the variable alignment vs type alignment when it is specified your > statement seems to be correct, however I agree that it still has a lot of= open > points. For example what should be the code if we put variable into a str= ucture >=20 > typedef int __attribute__((vector_size(16))) v4si;=20 >=20 > struct { > v4si a __attribute__((aligned(4))); > } b; >=20 > Should it still get aligned on 16 bytes or 4 bytes? >=20 > In my case I was seeking for a way to generate alignment tolerant code wi= thout > using > struct { > int a; > } __attribute__((packed)); >=20 > Obviously "int a __attribute__((packed));" does not work, so I tried to s= olve > it via "__attribute__((aligned(1)))" attribute. I don't think it makes much sense to generate alignment "tolerant" code for declarations, so when it is about indirect accesses via pointers then simply use a pointer to a type with appropriate alignment. Then the access will be "tolerant" but when the compiler sees the object accessed is actually of bigger alignment it isn't forced to honor your "tolerant" minimum alignment. When you're facing the situation that you have to access data at some symbol and that symbol can end up with alignment less than what its type specifies then you cannot just do extern int possibly_misaligned_data __attribute__((aligned(1))); which seems to be the case kernel folks run into with hppa. Instead you have to put the "tolerance" on the type again: typedef int tolerant_int __attribute__((aligned(1))); extern tolerant_int possibly_misaligned_data;=