[cfe-commits] adding "-fasan" flag

[Chandler Carruth]

On Tue, Nov 15, 2011 at 8:25 PM, Kostya Serebryany <kcc at google.com> wrote:

>
>
> On Tue, Nov 15, 2011 at 7:10 PM, John McCall <rjmccall at apple.com> wrote:
>
>> On Nov 15, 2011, at 6:40 PM, Eli Friedman wrote:
>> > On Tue, Nov 15, 2011 at 6:22 PM, Kostya Serebryany <kcc at google.com>
>> wrote:
>> >> Hello,
>> >> Please review the following patch which adds -fasan (AddressSanitizer)
>> flag
>> >> to clang.
>> >> (Mostly prepared by Chandler Carruth).
>> >> The LLVM part of AddressSanitizer has been submitted as r144758.
>> >> This patch will allow to enable AddressSanitizer from the clang command
>> >> line.
>> >> http://codereview.appspot.com/5396042
>> >> Coming next in separate patches:
>> >>   - a patch to clang driver to pass linker flags for AddressSanitizer
>> >> (small)
>> >>   - the run-time library and the tests (big)
>> >> Thanks,
>> >> --kcc
>> >
>> > I would prefer -faddress-sanitizer over -fasan; shorter isn't really
>> > better here.
>> >
>> > +  if (Args.hasFlag(options::OPT_fasan, options::OPT_fno_asan, false)) {
>> > +    CmdArgs.push_back("-DADDRESS_SANITIZER=1");
>> > +  }
>> > }
>> >
>> > Why would a program need this?  Can a program that's aware of the
>> > address sanitizer actually do anything usefully different?  Also,
>> > since this define doesn't start with an underscore, it's possible this
>> > could break a program using the identifier ADDRESS_SANITIZER for
>> > something else.
>>
>> It would be reasonable to make this a has_feature check.
>>
>
> Is that supported by gcc?
> I'd prefer to have a compiler-neutral thing.
>

See http://clang.llvm.org/docs/LanguageExtensions.html#feature_check -- it
should be completely compiler neutral. It's just a mechanism that compilers
can use to hide feature tests behind a known-safe macro, thereby avoiding
keyword clobbers etc. GCC could be trivially extend to directly support
this test pattern, and code can be written to work even with compilers that
don't support it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111115/e3441028/attachment.html>