From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 641963858C50; Tue, 23 Jan 2024 17:06:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 641963858C50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706029592; bh=r9XkClBHrXsVsn5NUG63VwbBobMrbZBrY9UoJt986dg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n9h1yuR9NhBT46v7dgXvcPStKgbVdHoloTZSLZTmxbfWe56uzKizGjh75oxYGOhVq T/zJg+dWB9AFs4csfSy1hZa8or7+8d4ADAU1ipfccwdHtoNg8Oig0b9OL/0Q1sAeyo BwmqDHNIGkdClCxm475n/47+n0oMiZJ008k7mZeI= From: "tnfchris at gcc dot gnu.org" 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:06:32 +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: tnfchris at gcc dot gnu.org 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 #18 from Tamar Christina --- (In reply to Richard Biener from comment #7) > I do wonder whether LOOP_VINFO_EARLY_BREAKS_VECT_PEELED actually works (s= ince > without early exits we cannot handle a non-empty latch because of correct= ness > issues). I'd very much have preferred to deal with these by loop rotation > (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 anywa= y). >=20 > Does the following fix the issue? 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 i= t. 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 thing and maybe pick another exit while the main exit would have worked.=