https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93452
Bug ID: 93452
Summary: [10 Regression] __has_include changes broke
compilation of -fdirectives-only preprocessed sources
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
$ cat a.c
int main () { return 0; }
$ ./xgcc -B ./ -E -fdirectives-only a.c -o a2.c; ./xgcc -B ./ -w -S a2.c -o
a2.s
works just fine in GCC 9 and earlier (the -w is just to shut up warnings about
redefined macros). But it is rejected by the trunk
<built-in>: error: "__has_include" cannot be used as a macro name
<built-in>: error: "__has_include_next" cannot be used as a macro name
As -fdirectives-only preprocessing is something that is extremely useful for
preserving token locations, macro origins etc., which normal preprocessing
throws away, I think this is pretty serious.
Can't we just not define __has_include/__has_include_next as macros through
#define at all and just let defined/ifdef/ifndef special case those, or
alternative not print the #define __has_include __has_include in -dD or
-fdirectives-only?
