When compiling the test with `gcc -std=c11 -fsyntax-only`
compilable/test23616.c:3:20: error: missing binary operator before token "("
3 | #if __has_extension(gnu_asm)
| ^
Test:
```
// https://issues.dlang.org/show_bug.cgi?id=23616
#if __has_extension(gnu_asm)
void _hreset(int __eax)
{
__asm__ ("hreset $0" :: "a"(__eax));
}
#endif
```
Comment #1 by bugzilla — 2023-02-16T08:42:50Z
Shouldn't the C preprocessor remove the #if line? and the #endif line?
Comment #2 by ibuclaw — 2023-02-16T19:03:58Z
(In reply to Walter Bright from comment #1)
> Shouldn't the C preprocessor remove the #if line? and the #endif line?
It's the C preprocessor that's rejecting it. I don't know why dmd compiles this, but gcc doesn't.
If you know, then it should be documented on the importc page here https://dlang.org/spec/importc.html#extensions
Though I suspect maybe under predefined macros would be more appropriate.
Comment #3 by bugzilla — 2023-02-20T07:05:18Z
__has_extension is yet another C compiler extension (not ImportC's invention).
Comment #4 by ibuclaw — 2023-02-20T12:57:11Z
(In reply to Walter Bright from comment #3)
> __has_extension is yet another C compiler extension (not ImportC's
> invention).
It's not GCC's invention either. Whose it is? It should be documented on the ImportC page.
Comment #5 by bugzilla — 2023-12-02T02:40:52Z
importc.h has the following lines in it:
#undef __has_extension
#define __has_extension(x) 0
so:
#if __has_extension(gnu_asm)
should become:
#if 0
I don't know what is going wrong here. Maybe __has_extension cannot be undefined?
Comment #6 by bugzilla — 2023-12-14T06:38:35Z
__has_extension is a clang invention:
https://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros
It is not supported or recognized by ImportC, it is just #undef'd away in importc.h.
You can file a general issue that importc.h should be documented in the ImportC specification, but the contents of the file itself serves as its documentation.
Until then, I'll file this as WONTFIX.