From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D5FE53858C2F; Thu, 25 Aug 2022 13:02:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D5FE53858C2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1661432569; bh=sR/UrgkNSNGpDHUV9JyilyEqaFu3Ug6/f9jXUIbbnGk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SqYTWnJgDX821gxlNduORr0vG19199Zn9+d8mUxsxQltfO1zHM7zwr2RJExUvqJ/O Vh9yLxuMyHyEuYvMZQxtOh8CH9ICJy9BX2Q7HKHeUBnUA1jdNTXguExcKpB9hrRb4E IGblCN7d/DurJqP4jkZxUAduXfgVA/2wW6wyW9P0= From: "krebbel at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b Date: Thu, 25 Aug 2022 13:02:49 +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.1.1 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: krebbel at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: krebbel at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.3 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=3D106101 --- Comment #21 from Andreas Krebbel --- I have committed a patch now which accepts only SUBREGs before reload and t= hen also REGs to deal with how LRA operates right now. I've continued a bit with the patch from Comment 18. It bootstraps on s390x= and x86-64. On s390x also the testsuite is clean. However, I see a few failures= in the arch specific tests on x86-64. The cases I looked at so far are the res= ult of several peepholes and splitters not being triggered anymore. I've fixed = most of them I think but there are also cases where I'm not sure what to do exac= tly. In case of a matching constraint between a strict_low_part operand and a no= rmal operand. Reload now (with the patch from Comment 18) would remove the subre= g on the operand with the matching constraint and would leave it in for the strict_low_part operand. (insn 9 8 16 2 (parallel [ (set (strict_low_part (subreg:QI (reg/v:SI 0 ax [orig:86 a ] [8= 6]) 0)) (and:QI (reg:QI 0 ax [orig:86 a ] [86]) (reg:SI 4 si [92]))) (clobber (reg:CC 17 flags)) ]) "/home/andreas/gcc/gcc/testsuite/gcc.target/i386/pr91188-1a.c":2= 0:10 553 {*andqi_1_slp} (nil)) I think this should be addressed separately. Once we solved it I will adjust the s390x backend again if necessary.=