https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89141
Bug ID: 89141 Summary: Documentation of -H ignores effect of include guards Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: osemwaro.pedro at ocado dot com Target Milestone: --- Created attachment 45576 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45576&action=edit Four short files with diamond include graph I have recently been trying to figure out how to construct include graphs from the GCC preprocessor's output, so that I can give the preprocessor the options that I would use when compiling my code, to ensure that macros (and comments) are treated correctly. The documentation of the -H option (https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-H) led me to believe that the include stack that it prints would give me the information that I need. But after carefully examining its output, I realised that it omits header files that contain include guards, the second time it encounters them. The attachment demonstrates this. Its four files have the following include graph: +-----> d.hpp <-----+ | | b.hpp <-- a.cpp --> c.hpp and all three .hpp files have include graphs, but GCC prints the following include stack: $ g++ -E -H a.cpp 2>&1 1> /dev/null . b.hpp .. d.hpp . c.hpp I.e. it ignores the fact that c.hpp includes d.hpp. This treatment of include guards should be described in the documentation (as should the fact that the include stack is written to standard error). Googling "gcc include graph" shows that there are a few other people who suggest constructing include graphs based on -H, so I suspect that I'm not the only person who has been (or would be) surprised to learn that this leads to incomplete include graphs. FWIW, I'm using GCC v. 5.4.0 on Ubuntu 16.04.