From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D3ED93858013; Tue, 8 Feb 2022 17:01:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D3ED93858013 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct Date: Tue, 08 Feb 2022 17:01:09 +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: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 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: Tue, 08 Feb 2022 17:01:09 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103147 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org, | |jonathan.wright at arm dot= com, | |wirkus at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Note, -fpack-struct is an ABI changing option, so it should be used with ex= tra care. Anyway, I guess the backends (both aarch64 and arm) need to decide what exa= ctly they want. Either for these internal lang_hooks.types.simulate_record_decl created typ= es temporarily rest to default the -fpack-struct stuff, or allow them to have smaller alignment, or increase the alignment afterwards. Because those tree t =3D lang_hooks.types.simulate_record_decl (input_location, tuple_type_name, make_array_slice (&field, 1)); gcc_assert (TYPE_MODE_RAW (t) =3D=3D TYPE_MODE (t) && TYPE_ALIGN (t) =3D=3D alignment); and ls64_arm_data_t =3D lang_hooks.types.simulate_record_decl (input_location, tuple_type_name, make_array_slice (&field, 1)); gcc_assert (TYPE_MODE (ls64_arm_data_t) =3D=3D V8DImode); gcc_assert (TYPE_MODE_RAW (ls64_arm_data_t) =3D=3D TYPE_MODE (ls64_arm_da= ta_t)); gcc_assert (TYPE_ALIGN (ls64_arm_data_t) =3D=3D 64); assertions otherwise of course fail. Now, seems the arm backend actually doesn't assert this. Note, when those types were defined in arm_neon.h, -fpack-struct usedd to be applied to those. The changes were done in r12-4907-g8197ab94b47c814632d758dd36a121ad4114ff70 and r12-5955-gfdcddba8f29ea3878851b8b4cd37d0fd3476d3bf=