From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CEA623857804; Tue, 15 Dec 2020 14:02:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CEA623857804 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/98287] [10/11 Regression] ICE: in expand_expr_real_2, at expr.c:10000 with -O2 -fno-tree-ccp -fno-tree-forwprop Date: Tue, 15 Dec 2020 14:02:54 +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: 11.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc target_milestone priority 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, 15 Dec 2020 14:02:54 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98287 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org Target Milestone|--- |10.3 Priority|P3 |P2 --- Comment #1 from Jakub Jelinek --- Started with r10-2805-ge944354ec05891474b0d204c6c239c04ee7b527b I think this is another case of harmful folding after last veclower, in this case during vrp2. After last veclower we need to be careful not to introdu= ce vector arithmetics that isn't supported by the target, as the expander does= n't have fallback for that, it relies on tree-vect-generic.c doing its job. So, either we need to guard all such match.pd etc. simplifications with che= cks whether the operations are supported on the vectors if we are after last veclower - in this particular case it is the x >> 1 << 1 optimization to x & { ~1 }, where the backend announces V1DImode >> and << but not AND, or schedule ano= ther veclower right before *.optimized dump to cover anything that got broken (or before isel and hope isel doesn't fold things?), or add fallback to the expander (the V1* vectors would be fairly easy, but anything else would be = hard and ugly).=