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.
