On Fri, Feb 15, 2019 at 08:33:44AM +0100, Jakub Jelinek wrote:
> On Fri, Feb 15, 2019 at 03:25:33PM +0800, Bin.Cheng wrote:
> > So with what condition we can safely rewrite trapping operations into
> > non trapping one? Does the rewrite nullify -ftrapv which requires
> > trap behavior?
>
> For the particular expression? Yes, otherwise no.
>
> -ftrapv should be either replaced with -fsanitize=signed-integer-overflow
> -fsanitize-undefined-trap-on-error, or at least implemented that way in the
> middle-end (perhaps with a separate ifn, so that we can pattern recognize it
> during expansion and use library calls where the inline call is not small
> enough). We haven't done that yet though.
To clarify, the current -ftrapv implementation doesn't guarantee you get
traps on overflow, it will happily optimize computations away at any time
during GIMPLE optimizations, or turn stuff into unsigned computations etc.
(not just through this rewrite function, but many other ways).
For -fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error
there are no guarantees either, but we try hard not to optimize those away,
we have TYPE_OVERFLOW_SANITIZED checks that punt certain optimizations in
fold-const.c/match.pd and early (right after going into ssa form) we turn
the arithmetics into ifns, which are optimized away only if we can prove
there will be no overflow. On the other side, it can hinder other
optimizations (a lot). And possibly overflowing computations introduced
during later optimizations are not sanitized.
The question is what -ftrapv users want, plus right now they have a choice,
catch perhaps less UB with more optimization opportunities (-ftrapv)
or catch more optimize less (UBSan).
Jakub
