On 12/03/13 15:05, Jakub Jelinek wrote:
On Tue, Dec 03, 2013 at 02:14:17PM -0700, Jeff Law wrote:
--- gcc/ubsan.h.mp 2013-11-27 08:46:28.046629473 +0100
+++ gcc/ubsan.h 2013-11-27 08:46:57.578753342 +0100
@@ -21,6 +21,12 @@ along with GCC; see the file COPYING3.
#ifndef GCC_UBSAN_H
#define GCC_UBSAN_H
+/* From predict.c. */
+#define PROB_VERY_UNLIKELY (REG_BR_PROB_BASE / 2000 - 1)
+#define PROB_EVEN (REG_BR_PROB_BASE / 2)
+#define PROB_VERY_LIKELY (REG_BR_PROB_BASE - PROB_VERY_UNLIKELY)
+#define PROB_ALWAYS (REG_BR_PROB_BASE)
Seems like this should factor out rather than get duplicated.
Yeah, the question is where, predict.h?
I'd think that'd be a fine place for them ;-)
+/* Add sub/add overflow checking to the statement STMT.
+ CODE says whether the operation is +, or -. */
+
+void
+ubsan_expand_si_overflow_addsub_check (tree_code code, gimple stmt)
Does this need to use Jakub's recent changes for pr58864 (pending
stack adjustment stuff). The code seems to have the same kind of
structure Jakub was cleaning up already.
No, the code always emits conditional jumps and one of the branches
will do a call, so we always want no pending stack adjustment
before the conditional jump and again no pending stack adjustment
after the library call, so that we don't make the stack pointer
inconsistent.
OK. Just making sure.
--- gcc/fold-const.c.mp 2013-11-27 08:46:27.941629031 +0100
+++ gcc/fold-const.c 2013-11-27 08:46:57.548753215 +0100
@@ -10335,14 +10335,16 @@ fold_binary_loc (location_t loc,
case PLUS_EXPR:
/* A + (-B) -> A - B */
- if (TREE_CODE (arg1) == NEGATE_EXPR)
+ if (TREE_CODE (arg1) == NEGATE_EXPR
+ && (flag_sanitize & SANITIZE_SI_OVERFLOW) == 0)
return fold_build2_loc (loc, MINUS_EXPR, type,
fold_convert_loc (loc, type, arg0),
fold_convert_loc (loc, type,
TREE_OPERAND (arg1, 0)));
/* (-A) + B -> B - A */
if (TREE_CODE (arg0) == NEGATE_EXPR
- && reorder_operands_p (TREE_OPERAND (arg0, 0), arg1))
+ && reorder_operands_p (TREE_OPERAND (arg0, 0), arg1)
+ && (flag_sanitize & SANITIZE_SI_OVERFLOW) == 0)
return fold_build2_loc (loc, MINUS_EXPR, type,
fold_convert_loc (loc, type, arg1),
fold_convert_loc (loc, type,
Presumably because you want to see the original arithmetic to
instrument it?
Yes. Dunno if Marek has added testcase for it, but if we have say:
int a = -10, b = INT_MIN;
then
int c = a - b;
isn't supposed to overflow, while
int d = a + (-b);
is. The signed integer overflow is in the latter case already
on the negation. Without -fsanitize=undefined we just assume
that it is undefined behavior and therefore ignore that case,
but with -fsanitize=undefined we actually want to diagnose it at runtime to
the user.
OK, that's basically what I figured.
So just a couple trivial issues for Marek to run down. Final review of
the stuff outside the x86 port ought to be trivial.
jeff
