From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D4F113858C2D; Mon, 12 Feb 2024 13:33:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D4F113858C2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1707744811; bh=qk4Hfm7wwHiCRD/E33d/WEs/gxsVSj+cK8YpkblTt8M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jdDjxekIUsSNj+lR6DvYbzcsdXK7xts6HXeZ5JiPM8NAj6IQkDwtY+2RdtcbJr7fC A1KUW5bgV6pp/yKhOe3MLpX7ijd/agGT16LsvhsaWe/ODHOo67b3AEgjVLq87f1IXm k6CASSBkHgMoJ2VFGH4yKVJ9qLNiGw8uZlWq/EIw= From: "tnfchris at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/113734] [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7 Date: Mon, 12 Feb 2024 13:33:30 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end 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: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: tnfchris 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=3D113734 --- Comment #22 from Tamar Christina --- (In reply to Richard Biener from comment #21) > loop->nb_iterations_upper_bound exactly is an upper bound on the number of > latch executions, so maybe I'm missing the point here. When we update it= it > as > well has to reflect an upper bound on that, whether the last exit (the one > before the latch) is the IV exit or a vectorized early exit. Yes, but the issue here is that the bounds limit is coming from an exit oth= er than the one being chosen as the IV exit. So the latch iterates X times not X - 1. >=20 > But yes, if the last exit is an early one that last iteration might be > partial > (so we drop the -1), but that's what we already do? I don't see where. This code all seems to remove -1 from the iteration cou= nt and assuming the latch iteration count + 1 =3D=3D nbounds. I don't really think this is about partial loops at all. Change parse_tables_n >>=3D 9; parse_tables_n +=3D 11; to parse_tables_n >>=3D 9; parse_tables_n +=3D 10; then loop->nb_iterations_upper_bound is 136 and there is no partial iterati= ons here. You do 17 full vector iterations with no residuals.=