From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6F25B3858D3C; Mon, 5 Sep 2022 10:15:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6F25B3858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662372924; bh=FbnM9Tlqzz1TqzN4rpXyyPqwQJ+vIb1YRuK+HxlhHhk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PUBkd3VLnNG/EEis1e+kHDWhIBUeBZHDJLEALEyAu4JUgnq7RDjMs94tOby0xi0f5 QJWjULz+zx0QSkCJyNAc70cscmgIh5eNI5A3fDjYnymUwhKrgx476Z7N0+w7S3dy8q doe1h/LxQMDPkQh6xGO5Vdm14jZAXL3PibsJQqVY= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/106818] code is genereated differently with or without 'extern' Date: Mon, 05 Sep 2022 10:15:23 +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: 12.0 X-Bugzilla-Keywords: wrong-code 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: 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=3D106818 --- Comment #9 from Richard Biener --- (In reply to baoshan from comment #5) > Per Andrew's request: >=20 > For GCC built for RISC-V, > With the following code: > struct sss_t { > int i; > int j; > } sss; > extern char array[sizeof(struct sss_t )]; > void foo() > { > struct sss_t *p =3D (struct sss_t *)array; > p->i =3D 10; Note we should know here that p->i =3D 10 accesses memory aligned according to the alignment of an 'int' (unless riscv is packed by default and doesn't have 'sss' aligned to an 'int'). That's because C guarantees this. We lose this fact because get_object_alignment_2 "knows better", aka in some places GCC tries to work like a DWIM compiler, saving people from mistakes. Here get_inner_reference sees we access 'array' and adjusts alignment according to its alignment, ignoring what the language standard guarantees.=