https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #38 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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.
> >
> > 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.
>
> 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 above
testcase could help make it exploitable, with -minline-all-stringops (at least
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.
