From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 23C1B3858C2F; Tue, 23 Jan 2024 17:42:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 23C1B3858C2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706031773; bh=6kYcqHqnI5VjkZc54Gw2SQ3NKZlBCeW+5moNQMnZeQw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LGqQJWc49s1bLdOnRCpx8GuUjbmipLu3r2R0ptcQyDv5C+rk1QrFrA09aVJMZI9xq +N6MFeNCXCVXP1tDZ0TRq4Id/KILl2T7oMEw6SlOAoDSCIQqCw1qGT4PYSSSGTpu1U 3oUsf5Mpy2QlEzKom7MSCCvnnkgNFm7Pq1o2ur/g= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled Date: Tue, 23 Jan 2024 17:42:52 +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: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org 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=3D113467 --- Comment #19 from rguenther at suse dot de --- > Am 23.01.2024 um 18:06 schrieb tnfchris at gcc dot gnu.org : >=20 > =EF=BB=BFhttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113467 >=20 > --- Comment #18 from Tamar Christina --- > (In reply to Richard Biener from comment #7) >> I do wonder whether LOOP_VINFO_EARLY_BREAKS_VECT_PEELED actually works (= since >> without early exits we cannot handle a non-empty latch because of correc= tness >> issues). I'd very much have preferred to deal with these by loop rotati= on >> (there's the loop_ch pass). We're still doing this, even when >> LOOP_VINFO_EARLY_BREAKS_VECT_PEELED: >>=20 >> /* We assume that the loop exit condition is at the end of the loop. i.= e, >> that the loop is represented as a do-while (with a proper if-guard >> before the loop if needed), where the loop header contains all the >> executable statements, and the latch is empty. */ >> if (!empty_block_p (loop->latch) >> || !gimple_seq_empty_p (phi_nodes (loop->latch))) >> return opt_result::failure_at (vect_location, >> "not vectorized: latch block not >> empty.\n"); >>=20 >> so that's a bit odd (but loop_ch tries to ensure the latch is empty anyw= ay). >>=20 >> Does the following fix the issue? >=20 > Not really sure I understand what the latch being empty has to do with > LOOP_VINFO_EARLY_BREAKS_VECT_PEELED as the latch is still empty even with= it. The latch is everything after the IV exit. > I guess if it's just going to disabled it then wouldn't it better to just > always pick the latch exit rather than trying to do the whole analysis th= ing > and maybe pick another exit while the main exit would have worked. The point was to quickly see whether a peeled early exit vectorization is t= he issue here.=