[cfe-commits] adding "-fasan" flag

[Kostya Serebryany]

Meanwhile, I removed -DADDRESS_SANITIZER from the patch.
Please take another look.

We can reinstate the macro or implement __has_feature/__has_extension when
we decide what is the right thing to do.

--kcc

On Tue, Nov 15, 2011 at 9:11 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Tue, Nov 15, 2011 at 9:02 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>>
>>
>> On Tue, Nov 15, 2011 at 8:51 PM, Chandler Carruth <chandlerc at google.com>wrote:
>>
>>> On Tue, Nov 15, 2011 at 8:46 PM, Kostya Serebryany <kcc at google.com>wrote:
>>>
>>>>
>>>>> See http://clang.llvm.org/docs/LanguageExtensions.html#feature_check-- it should be completely compiler neutral.
>>>>>
>>>>
>>>> So, the user code will have to look like this?
>>>>
>>>> #ifndef __has_feature
>>>> # define __has_feature(x) 0
>>>> #endif
>>>> ...
>>>>
>>>>  #if __has_feature(address_sanitizer)
>>>> ..
>>>> #endif
>>>>
>>>
>>> I would hope it could be simplified as:
>>>
>>> #if defined(__has_feature) && __has_feature(address_sanitizer)
>>> ...
>>> #endif
>>>
>>
>> What is the status of __has_feature?
>> Is it a pure clang extension?
>> Is it suggested for standardization?
>> If other compilers are not going to accept/implement __has_feature I
>> afraid that the user code will actually have to look like this:
>>
>> #if defined(__has_feature) && __has_feature(address_sanitizer)
>> # define ADDRESS_SANITIZER 1
>> # elif defined(__gcc_analog_of_has_feature)
>> && __gcc_analog_of_has_feature(address_sanitizer)
>> # define ADDRESS_SANITIZER 1
>> # elif defined(__msvc_analog_of_has_feature)
>> && __msvc_analog_of_has_feature(address_sanitizer)
>> # define ADDRESS_SANITIZER 1
>> #endif
>>
>> #ifdef ADDRESS_SANITIZER
>> <code>
>> #endif
>>
>> Argument 'can be easily implemented in gcc' does not work.
>> We need something like 'will most likely be accepted by gcc' for any
>> value of 'gcc'.
>>
>
> Looping in Diego who seems most likely to both have insight into what GCC
> would do here, and know others who would be interested in this discussion.
>
> I would very much like to see __has_feature (and its ilk) become widely
> available specifically to ease the problem of collisions between existing
> tokens and preprocessor macros, and to give some more semantic clarity to
> what exactly people are testing.
>
> I don't think 'ADDRESS_SANITIZER' being defined, or even
> '__ADDRESS_SANITIZER' being defined really helps the problem you mention
> above. If we keep making up arbitrary systems for marking features as on or
> off, any project striving for broad compatibility with many different
> compilers will *have* have have piles of if-def code like you describe.
> Moving (even one feature) toward a systematic pattern for detecting and
> enabling functionality when available seems like the only reasonable way to
> make progress.
>
>
> I also don't think we need to get complete agreement among all of the tool
> chains that may ever implement Address Sanitizer like features in order to
> make forward progress. Past a certain point, other tool chains can simply
> grow as much of this feature as they need if/when they want to support the
> syntax.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111115/663f07ca/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: issue5396042_3001.diff
Type: text/x-patch
Size: 4766 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111115/663f07ca/attachment.bin>