On Wed, May 18, 2022 at 3:16 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > On 5/18/22 02:41, Richard Biener wrote: > > On Tue, May 17, 2022 at 8:41 PM Andrew MacLeod via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > >> This patch implements side effects of the second operand of a shift > >> operation. > >> > >> given A >> B or A << B, the range of B is restricted to [0, PRECISION_A). > >> > >> Fortran is currently more permissive than this, allowing the range to be > >> [0, PRECISION_A], so this si the value we currently default to in this > >> patch. If the fortran front end were adjusted, we could adjust the end > >> point. > >> > >> This currently bootstraps with no regressions on x86_64-pc-linux-gnu. > >> > >> Is this sufficient, or should I also be checking some other flags which > >> may allow other values outside this range to be valid? > > I think the "undefined behavior" side-effects are dangerous since > > I know of no code that makes sure to clamp the shift argument when > > hoisting it. sanitizing shifts will also not help to discover such latent > > issues since sanitizing is happening early and it will most definitely > > avoid the hoisting itself. > > > > As to that we _definitely_ want a way to disable this [assumption > > that the shift operand is in-range] if we make that assumption > > even on IL state after optimizations. > > > > Candidates to look for are invariant motion, ifcombine, > > partial PRE, PRE in general (we possibly hoist such expressions > > across function calls that might terminate the program normally). > > > > That is, what prevents > > > > if (n > 32) > > abort (); > > x = i << n; > > > > to be transformed to > > > > x = i << n; > > if (n > 32) > > abort (); > > > > ? Yes, that's probably a latent issue in some sense but you would > > now optimize the if (n > 32) abort () away while previously x would > > have an undetermined value but we'd still abort. > > > > Do you have some statistics on how this particular side-effect > > improves code generation? > > > > Richard. > > None whatsoever... just a PR requesting it that has been open for 15 > years :-) > > If we don't want to do this optimization, then we should kill the PR. I > can also attach the path to the PR than if anyone cares enough about > this functionality, they could pursue the other effects...
Linking from the bug to this patch submission and the discussion would certainly be helpful. I think most of the undefined behavior exploiting we do would benefit from a mode where the code exploiting the undefined behavior would instead instrument the code to abort the program. That way it would be much easier to detect GCCs wrongdoing (introducing such undefined behavior when sanitizers are otherwise clean) rather than waiting on the rare occasion where the bogus exploitation triggers a miscompile in actual code. Richard. > Andrew > > >
