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?