Re: [PATCH] Fix tree-loop-distribution.c ICE with -ftrapv (PR tree-optimization/89278)

["Bin.Cheng" <amker.cheng@gmail.com>]

On Fri, Feb 15, 2019 at 3:48 PM Jakub Jelinek <jakub@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