[PR 80005] __has_include parsing

Nathan Sidwell nathan@acm.org
Tue Jan 21 12:10:00 GMT 2020


On 1/20/20 9:01 PM, Jim Wilson wrote:
> On Mon, Jan 20, 2020 at 5:44 AM Nathan Sidwell <nathan@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.

tl;dr; glibc is broken.

AFAICT __has_include__ was an undocumented piece of internal 
implementation goop, that didn't really work anyway.  I'm sure it's 
presence has confused users.

I guess I have to add compatibility ...

> 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>)

yup, 'cos as I'm sure you're aware __has_include__ will now be a regular 
identifier, and treated as a literal '0' in this context.

nathan

-- 
Nathan Sidwell



More information about the Gcc-patches mailing list