[cfe-commits] adding "-fasan" flag

[Chandler Carruth]

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/08920f71/attachment.html>