From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 919683864C5B; Thu, 15 Feb 2024 14:36:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 919683864C5B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708007793; bh=RzNPcg0vI1EMrwpPgrWhihEoStMzOSKSCyBvu48CuFA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=k1rkLvv1fH2SVzA6BfVziPSudjMwS6+Jboqs7k3rkrsmLv42PTt+X89VXIqTGElBK sL1O2oEwzbYG83XaPARsO2BrPOfqYy7ixuLEK9MZHpZq9bZAeT4O69+Pf5rb8wQpkC Odku/Id6GzWsNqK41cOQSuvqTsyDzm+AA+dTNqGc= 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 14:36:32 +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 #32 from Jakub Jelinek --- (In reply to Jan Hubicka from comment #31) > 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. Maybe my imagination is too limited, but if the ipa-prop's jump functions a= re computed before ICF is performed, then if you call function a which makes s= ome 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 different range, then even if the two functions are merged and either the range info is thro= wn away or unioned, I think if some functions call one or the other functions then still the original range assumptions still apply, depending on which one actually called. > Let me see if I can modify the testcase to also trigger problem with value > ranges in ipa-prop jump functions. >=20 > Not streaming value ranges is an omission on my side (I mistakely assumed= we > do stream them). We ought to stream them, since otherwise we will lose > propagated return value ranges in partitioned programs, which is pity. Not sure if it is a good idea to start streaming them now in stage4, but su= re, if we stream them (and I think we should mostly have code to be able to stream th= at because we can stream the ranges in the jump functions, just unsure about points-to stuff), then I still think best approach would be to merge regardless of range info, but in that case preferrably union instead of throw away. The only questio= n is where to do the merging for the LTO case (where to stream the union of the ranges and where to read it in and update for the SSA_NAMEs).=