[PATCH 2/2] Implement -fsanitize=signed-integer-overflow (i?86 parts)

[Jakub Jelinek]

On Wed, Dec 04, 2013 at 02:52:25PM +0100, Uros Bizjak wrote:
> On Wed, Dec 4, 2013 at 2:44 PM, Marek Polacek <polacek@redhat.com> wrote:
> > And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
> > split out of the huge patch.  It really is dependent on the generic
> > parts, when commiting, I'll put both parts together.
> 
> Just a question (I will review the patch later today): shouldn't
> generic parts also work without new target patterns and use __addv*
> stuff from libgcc when patterns are not present?

They work (except for multiplication checking with widest supported mode, to
be supported later), but they can't use __addv* and co., because those
functions __builtin_trap () on overflow, while for
-fsanitize=signed-integer-overflow, if we wanted a library solution, we'd
need library functions that would return us both result and bool whether
overflow happened.  As addition/subtraction/negation overflow checking
is short and easily inlinable, that is done always inline now, and
for multiplication the code right now expands WIDEN_MULT_EXPR if possible.

Note that using get_range_info the generic expansion could be supposedly
improved, for add/sub we right now at runtime compare op1 against zero
and do one thing if it is negative and another if non-negative.
If VRP info tells us that either op0 or op1 is known to be non-negative
or known to be negative, we could just simplify the expansion.
I guess similarly for the multiplication, but after all, I think the VRP
info could be useful even for normal multiplication expansion, e.g. if
we want to do a WIDEN_MULT_EXPR, but know that given the operand ranges
we can actually do a MULT_EXPR only and then just sign/zero extend the
result, that will likely be cheaper.

If VRP figures out there will never be an overflow, then we already optimize
the UBSAN_* internal builtins into normal PLUS_EXPR etc.

	Jakub