From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5763938618BE; Thu, 15 Feb 2024 15:02:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5763938618BE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708009325; bh=0tnaCAbDRklIjOXwxymatggvjlCsrgHbpHqXxgmb30Y=; h=From:To:Subject:Date:In-Reply-To:References:From; b=egNP1e5J0qkIHW610zul52R1gc0Smo9CA95s6olCSRSpFT6FgwDwOv+DlrolBndTz sQx/+WsuMyxYkO/zgoofyyS9NMp5aybOTGPYjfBvwOP5VYYlr9gmMMJl8g+SkUtzgB 9sNs9r3W6OH32zCXFwVsKemwNGDGc4UlM4/rtK7Y= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41 Date: Thu, 15 Feb 2024 15:02:05 +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: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW 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=3D113907 --- Comment #38 from Jakub Jelinek --- (In reply to Jan Hubicka from comment #36) > > > Having a testcase is great. I was just playing with crafting one. > > > I am still concerned about value ranges in ipa-prop's jump functions. > >=20 > > Maybe my imagination is too limited, but if the ipa-prop's jump functio= ns are > > computed before ICF is performed, then if you call function a which mak= es some > > assumptions about its arguments and SSA_NAMEs used within the function = and > > results in some return range > > and another one which makes different assumptions and results in a diff= erent > > range, > > then even if the two functions are merged and either the range info is = thrown > > away > > or unioned, I think if some functions call one or the other functions t= hen > > still the original range assumptions still apply, depending on which one > > actually called. >=20 > I think the tescase should have functions A1 and A2 calling function B. > We need to arrange A1 to ICF into A2 and make A2 to have narrower value > range of parameter of B visible to ipa-prop. Since ICF happens first, > ipa-prop will not see A1's value range and specialize B for A2's range. > Which sould make it possible to trigger wrong code. If you manage to get wrong ranges in such case, then reusing part of the ab= ove testcase could help make it exploitable, with -minline-all-stringops (at le= ast in some tunings?) memcpy emits if (len < 8) rep movsb; else { if (dst & 1) movsb; if (dst & 2) movsb; etc. } and so if incorrect value range results in the len < 8 check to be optimized away, the rest misbehaves if destination = is aligned to 8 with misalignment 1 and length is smaller than 8.=