User account creation filtered due to spam.

Bug 14238 - Dependency tracking and PCH
Summary: Dependency tracking and PCH
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: pch (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-21 17:24 UTC by Carlo Wood
Modified: 2004-04-14 06:14 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2004-04-13 04:21:24


Attachments
Example case (548 bytes, application/x-gz)
2004-02-21 17:25 UTC, Carlo Wood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Carlo Wood 2004-02-21 17:24:14 UTC
As automake generates, the usual way to create
automatic dependencies is by adding something like
-MD -MP -MT a.o -MF a.deps
to the normal compilation line, giving the benefit
of gcc's one-pass compile + make depend.

If we use PCH, one might need a compilation like:

g++ -include pch.h -c a.cc

and thus end up with doing:

g++ -include pch.h -c a.cc -MD -MP -MT a.o -MF a.deps

Often, the PCH (pch.h in this case) contains a LOT of header files,
and we don't want to recompile every compilation unit when we
touch a single header, even when all source files are including
this pch.h.  So, correctly, the dependency tracking is ignoring both
pch.h and whatever it includes.

The real dependency information is therefore gathered from
the #include's inside a.cc.  And here is the problem, when a.cc
does include "a.h", then this is recorded - but when a.h uses the
usual inclusion gard macros, and it is including "a2.h", then we
don't see that back in the output to a.deps!  After all, the pre-
processor thinks that gard macro of a.h is defined (which is the
case because a.h was included before from pch.h) and there does
not process the #include's in a.h for the same of dependency
tracking.

I've included a simple test case that demonstrates this.
Please untar and execute the commands:

make depend-pch
cat a.deps

The output will be:

a.o: a.cc a.h

a.h:

Compare this with:

>make depend-nopch
g++-cvs-3.4 -c a.cc -MD -MP -MT a.o -MF a.deps
g++-cvs-3.4 -c b.cc -MD -MP -MT b.o -MF b.deps

>cat a.deps
a.o: a.cc a.h a2.h

a.h:

a2.h:
Comment 1 Carlo Wood 2004-02-21 17:25:30 UTC
Created attachment 5781 [details]
Example case
Comment 2 Andrew Pinski 2004-04-13 04:21:24 UTC
Confirmed, related to bug 14933.
Comment 3 Geoff Keating 2004-04-13 18:35:43 UTC
This is correct behaviour.  When the PCH is in use, a2.h is not directly used in the compilation of a.o.  
You could delete a2.h and the compilation would still succeed.
Comment 4 Carlo Wood 2004-04-13 23:51:25 UTC
It is not correct behaviour.
If you delete a2.h then the PCH file SHOULD be made
(it depends on a2.h) and would fail.  Deleting it is
no different than changing it.  When you change it,
then you want both, the PCH file to be remade as well
as all compilation units depending on a2.h (not pch.h).
Comment 5 Geoff Keating 2004-04-14 06:14:51 UTC
> It is not correct behaviour.
> If you delete a2.h then the PCH file SHOULD be made
> (it depends on a2.h) and would fail.  Deleting it is
> no different than changing it.  When you change it,
> then you want both, the PCH file to be remade as well
> as all compilation units depending on a2.h (not pch.h).

Right, but a.o does not directly depend on a2.h.  a.o depends on pch.h.gch which depends on a2.h.

It sounds like what you want is the answer to the question "if the -include was not passed, what would 
the dependencies of a.o be?"  You can get that answer by asking that question: by using

g++-cvs-3.4 -E a.cc -MD -MP -MT a.o -MF a.deps -o /dev/null

Alternatively, you might be wanting the answer to the question "if PCH was not used, what would the 
dependencies of a.o be?"  You can get the answer to that question by using the -fpch-deps flag.

Bug 14933 already covers the problem that pch.h.gch is not mentioned in the dependency list of a.o.