This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Request to merge Undefined Behavior Sanitizer in


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]