From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3EF343858D1E; Thu, 10 Feb 2022 22:27:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3EF343858D1E From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a Date: Thu, 10 Feb 2022 22:27:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization 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: Thu, 10 Feb 2022 22:27:27 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102586 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |redi at gcc dot gnu.org, | |rodgertq at gcc dot gnu.org --- Comment #17 from Jakub Jelinek --- I guess for the purposes restricting __builtin_clear_padding to trivially copyable types is ok, http://eel.is/c++draft/atomics.types.generic#general-1.1 requires that. But we use __builtin_clear_padding or the infrastructure also for: 1) __builtin_bit_cast constant evaluation 2) OpenMP atomics 3) -fauto-var-init=3D I don't remember the std::bit_cast case right now, OpenMP atomics are about scalar floats only, 3) will always call it with address of a variable and therefore know the complete object. So perhaps go with your patch and diagnose if the builtin is called on non-trivially copyable type unless it is called with address of a decl?=