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

[Richard Smith]

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).

Thoughts?
-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120918/ba884f5e/attachment.html>