On Fri, Feb 15, 2019 at 3:48 PM Jakub Jelinek <ja...@redhat.com> wrote: > > 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). Thanks very much for the explanation, that explains all questions I had.
Thanks, bin > > Jakub
