I've submitted http://llvm.org/viewvc/llvm-project?view=revision&revision=175263
If it survives a few days of testing I'll do another merge to gcc.
--kcc
On Fri, Feb 15, 2013 at 1:47 PM, Konstantin Serebryany
<konstantin.s.serebry...@gmail.com> wrote:
> On Fri, Feb 15, 2013 at 1:37 PM, Jakub Jelinek <ja...@redhat.com> wrote:
>> On Fri, Feb 15, 2013 at 01:30:18PM +0400, Konstantin Serebryany wrote:
>>> > OT, unrelated thing, in include/asan_interface.h there is one
>>> > #if __has_feature(address_sanitizer)
>>> > which for GCC should better be:
>>> > #if (defined __has_feature && __has_feature(address_sanitizer)) \
>>> > || defined(__SANITIZE_ADDRESS__)
>>> > (and similarly in asan_internal.h).
>>>
>>> z.c:1:44: error: missing binary operator before token "("
>>> #if (defined __has_feature && __has_feature(address_sanitizer)) \
>>>
>>> This should be more like the code below
>>>
>>> #if !defined(__has_feature)
>>> #define __has_feature(x) 0
>>> #endif
>>> #if __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__)
>>
>> I don't care much. Would
>> #if (defined(__has_feature) && __has_feature(address_sanitizer)) \
>> || defined(__SANITIZE_ADDRESS__)
>> work? In any case, that looks like clang bug, if you have something that
>> behaves like a function-like macro, #if defined macro or #ifdef macro
>> or #if defined macro || 1 and similar should work just fine, only if
>> the macro is followed by ( it should behave differently.
>
> That's gcc:
>
> % cat z.c
> #if (defined __has_feature && __has_feature(address_sanitizer)) \
> || defined(__SANITIZE_ADDRESS__)
> #error OK
> #else
> #error NOOOOO
> #endif
> % gcc -c -fsanitize=address z.c
> z.c:1:44: error: missing binary operator before token "("
> #if (defined __has_feature && __has_feature(address_sanitizer)) \
> ^
> z.c:5:2: error: #error NOOOOO
> #error NOOOOO
> ^
> % clang -c -fsanitize=address z.c
> z.c:3:2: error: OK
> #error OK
> ^
> 1 error generated.
> %
>
>
>>
>>> [hopefully not starting a holly war] Any chance to teach gcc/cpp about
>>> __has_feature?
>>
>> Not for GCC 4.8, that is a new feature, so certainly too late for that.
>
> How about 4.9?
>
>>
>> Jakub
