From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BCB473858D38; Thu, 11 Apr 2024 06:33:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BCB473858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712817198; bh=NvcEq1ABxLGvBKU+LEA30GfcpHKth3Uu2fIrfPRnilc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=c8YJ9fP0Y87hupheILUaMbLlFoD6RboYDrnko10umSLEK8krv8vrQrQ8kZbVzUZBh fLZQ3Y5bbJ64Byy6USgPZ+cEirfFhYWXelqCzTC/PzGSSHZ57t19aRmd5F1KGLgPDI hAvm7EgkiA1+2x+GTEDcXjS4kLKfwQ8Jy9pjHN9U= From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/112560] [14 Regression] ICE in try_combine on pr112494.c Date: Thu, 11 Apr 2024 06:33:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: ice-checking, ice-on-valid-code, patch X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: ubizjak at gmail dot com X-Bugzilla-Target-Milestone: 14.0 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=3D112560 --- Comment #13 from Uro=C5=A1 Bizjak --- (In reply to Segher Boessenkool from comment #12) > You cannot use a :CC value as argument of an unspec, as explained before. >=20 > The result of a comparison is expressed as a comparison, in RTL. This pa= tch > allows malformed RTL in more places than before, not progress at all. During our discussion we determined that this form with UNSPEC is actually a copy operation, so it is not an use [1] of CC register, because "use" is in= the form of cc-compared-to-0. [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647426.html Now, let's see the part my patch fixes. The original change that introduced= the functionality (See Comment #1) updates the "use" of the CC register. It ass= umes exclusively cc-compared-to-0 use, but there are several patterns in various target .md files that use naked CC register. The "???" comment suggests that the transformation tripped on this and thus the "verify the zero_rtx" was bolted on. The zero_rtx is inherent part of the regular CC reg "use", so th= is addition _mostly_ weeded out invalid access with naked CC reg. If the CC reg is used as the source of copy operation ("move"), with or wit= hout UNSPEC, then the unpatched compiler will blindly use: SUBST (XEXP (*cc_use_loc, 0), newpat_dest); which *assumes* the certain form of the changed expression. Failed assumpti= on will lead to memory corruption, and this is what my patch prevents. Patched compiler will find the sole use of the naked CC reg (due to find_single_use) in the RTX, and update its mode at the right place. If the= new mode is not recognized by the insn pattern, then the combination is rejecte= d. In any case, we are trading silent memory corruption with failed combine attempt. In my rule book, this is "progress" with bold, capital letters.=