[cfe-dev] [RFC] Extending and improving Clang's undefined behavior checking

Chris Lattner clattner at apple.com
Thu Sep 20 10:10:48 PDT 2012


On Sep 18, 2012, at 2:25 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Tue, Aug 21, 2012 at 4:33 PM, Chris Lattner <clattner at apple.com> wrote:
> <catching up on old email>
> On Aug 10, 2012, at 7:48 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> > 2) Command-line interface. We currently have the following options to enable various flavors of undefined
> 
> > I would like for us to have a single argument which enables all undefined behavior checking which can be performed cheaply and with no changes to address space layout or ABI; I propose we extend -fcatch-undefined-behavior to be that argument.
> 
> +1
> 
> > I think we should support this kind of configuration through a mechanism similar to warning flags: -fcatch-undefined-behavior=c++11 -fno-catch-undefined-behavior=null-reference, for instance.
> 
> +1
> 
> > Also, I think we should consider renaming this switch (and/or possibly the -f*-sanitizer switches) to provide a consistent set of names, but I don't have a concrete proposal for that.
> 
> That would make sense to me.
> 
> Concrete proposal (based on ideas from Chandler): we run with the branding which -faddress-sanitizer and -fthread-sanitizer have established. Our new switch for all optional runtime checking is "-fsanitize=...". This should behave analogously to -W, and in particular, we should have sanitizer groups (as discussed elsewhere on this thread) and -fsanitize=no-<whatever>.
> 
> -faddress-sanitizer becomes a synonym for -fsanitize=address
> -fthread-sanitizer becomes a synonym for -fsanitize=thread
> -fcatch-undefined-behavior becomes a synonym for -fsanitize=undefined-fast
> -ftrapv becomes a synonym for -fsanitize=signed-overflow
> 
> For compatibility with GCC and previous versions of Clang, these existing flags are retained. -fsanitize=address and -fsanitize=thread continue to be incompatible (a diagnostic will be produced for any attempt to combine them).

Makes sense to me,

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120920/0de1f5d6/attachment.html>


More information about the cfe-dev mailing list