[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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 are
computed before ICF is performed, then if you call function a which makes 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 different
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 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.
> 
> 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 sure,
if we
stream them (and I think we should mostly have code to be able to stream that
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 question 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).