Re: [PR 80005] __has_include parsing

2020-01-21 Thread Jim Wilson
On Tue, Jan 21, 2020 at 12:22 AM Jakub Jelinek wrote: > I only see one spot where it has been added and then > 2019-06-06 Florian Weimer > > * sysdeps/unix/sysv/linux/riscv/flush-icache.c: Do not use > internal GCC preprocessor identifier __has_include__. > which corrected it to

Re: [PR 80005] __has_include parsing

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

Re: [PR 80005] __has_include parsing

2020-01-21 Thread Jakub Jelinek
On Mon, Jan 20, 2020 at 06:01:27PM -0800, Jim Wilson wrote: > On Mon, Jan 20, 2020 at 5:44 AM Nathan Sidwell 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 longe

Re: [PR 80005] __has_include parsing

2020-01-20 Thread Jim Wilson
On Mon, Jan 20, 2020 at 5:44 AM Nathan Sidwell 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

[PR 80005] __has_include parsing

2020-01-20 Thread Nathan Sidwell
I've pushed this to master, to address 80005 __has_include is funky in that it is macro-like from the POV of #ifdef and friends, but lexes its parenthesize argument #include-like. We were failing the second part of that, because we used a forwarding macro to an internal name, and hence always