On Thu, Jul 25, 2013 at 10:43:30PM +0000, Joseph S. Myers wrote:
> On Thu, 25 Jul 2013, Marek Polacek wrote:
>
> > +@item -fsanitize=undefined
> > +Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector
> > +Various computations will be instrumented to detect
> > +undefined behavior, e.g.@: division by zero or various overflows.
>
> The same issues applies as for bounds-checking options - please give
> sufficient information in the documentation for a user to be able to judge
> the trade-offs between this and -ftrapv (for example).
Ok, I've commited a patch which hopefully makes the documentation better:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5150,8 +5150,11 @@ See
@uref{http://code.google.com/p/data-race-test/wiki/ThreadSanitizer} for
@item -fsanitize=undefined
Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector
-Various computations will be instrumented to detect
-undefined behavior, e.g.@: division by zero or various overflows.
+Various computations will be instrumented to detect undefined behavior
+at runtime, e.g.@: division by zero or various overflows.
+While @option{-ftrapv} causes traps for signed overflows to be emitted,
+@option{-fsanitize=undefined} gives a diagnostic message.
+This currently works only for the C family of languages.
@item -fdump-final-insns@r{[}=@var{file}@r{]}
@opindex fdump-final-insns
> It should also be clear how this interacts with -fwrapv. I'd say that
> -fwrapv makes the semantics of overflow in signed-integer arithmetic no
> longer undefined (of course division by zero is still undefined) and so
> should mean such overflows aren't warned for. Now, you don't currently
> have any checks this would affect (given that INT_MIN / -1 and INT_MIN %
> -1 don't currently work reliably with -fwrapv anyway), but the intention
> should be clear for when overflow checks are added.
Yes, I agree. When the signed overflows checks are in, we shouldn't sanitize
signed overflows when -fwrapv is in effect.
Marek
