On Mon, Jan 20, 2020 at 5:44 AM Nathan Sidwell <nat...@acm.org> wrote:
> I've pushed this to master, to address 80005
>
> __has_include is funky in that it is macro-like from the POV of #ifdef
> ...
With this patch, __has_include__ no longer works. There is a use of
this in the RISC-V glibc port. I see the docs only mention
__has_include, so maybe this has always been a silent bug in the
RISC-V glibc port? If glibc is broken I can submit a patch. This
might cause trouble for other people too though.
Given the testcase,
#if __has_include__ (<stdio.h>)
#error "yes"
#else
#error "no"
#endif
#if __has_include (<stdio.h>)
#error "yes"
#else
#error "no"
#endif
Without this patch I get
rohan:2212$ ./xgcc -B./ -O -S tmp4.c
tmp4.c:2:2: error: #error "yes"
2 | #error "yes"
| ^~~~~
tmp4.c:8:2: error: #error "yes"
8 | #error "yes"
| ^~~~~
and with this patch I get
gamma05:2206$ build-install/bin/riscv64-unknown-linux-gnu-gcc -O -S tmp4.c
tmp4.c:1:21: error: missing binary operator before token "("
1 | #if __has_include__ (<stdio.h>)
| ^
tmp4.c:4:2: error: #error "no"
4 | #error "no"
| ^~~~~
tmp4.c:8:2: error: #error "yes"
8 | #error "yes"
| ^~~~~
Jim
