I found the problem! It's related to the use of precompiled headers. We need to use '-fpch-deps' in order to get the full dependencies, otherwise all the dependencies from the pch file are omitted.
I'm currently preparing a webrev which fixes the problem. It would be nice if somebody could meanwhile open a bug for the problem (e.g. "Usage of gcc with precompiled headers produces wrong build dependencies") and provide a bug-id. Regards, Volker On Fri, Jun 8, 2012 at 7:50 PM, Volker Simonis <[email protected]> wrote: > Yes, that's really strange. You're right, the dependency file should > contain ".. the names of all the included files" (gcc -man page). > > So it seems to be a bug in gcc and how it handles '-MMD' although I > couldn't find a bug report for it and I can't believe that nobody else > has noticed this before. I've tried gcc 4.4.3 and 4.1.2 and they both > produce a wrong dependency file which only contains the direct > includes of the processed .cpp file (with "-c -MMD -MP -MF > ../generated/dependencies/frame.o.d -o frame.o"). > > If I compile with "-c -MM -MP -MF ../generated/dependencies/frame.o.d > -o frame.o" the generated dependency file is much bigger and looks ok, > but of course I get no object file. I also get he same wrong behavior > for -MD vs -M. The only reason behind -MD and -MMD is that it "..can > be used to generate a dependency output file as a side-effect of the > compilation process" (from the GCC man page) - but that doesn't seem > to work.. > > Does anybody has an explanation for this behavior? > > Regards, > Volker > > On Fri, Jun 8, 2012 at 6:25 PM, Keith McGuigan > <[email protected]> wrote: >> >> I don't understand why gcc doesn't put frame_x86.inline.hpp into the >> generated/dependencies/frame.o.d file. Isn't the point of -MMD to calculate >> the full closer of header files used for listing as a dependency? Is this a >> bug in gcc or are we using it wrong? >> >> I notice that Sun Studio compiler does put the arch-specific header file in >> the generated dependency file. Weird. >> >> -- >> - Keith >> >> >> On 6/8/2012 11:58 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> I've just stumbled across the problem that changing the implementation >>> of an inline function in HotSpot does not necessarily rebuild all the >>> call sites of that function. This is because because of the way how >>> the build dependencies are handled within the HotSpot. As an example >>> you may have a look at frame.cpp: >>> >>> frame.cpp includes frame.inline.hpp >>> frame.inline.hpp includes frame_x86.inline.hpp >>> >>> However frame.cpp only depends on frame.inline.hpp directly (i.e. >>> frame.cpp only includes frame.inline.hpp directly and this is where >>> the dependencies generated by gcc with '-MMD' are computed from). >>> So if an inline function in frame_x86.inline.hpp will be changed (e.g. >>> the constructor frame::frame()), frame.cpp will not be recompiled in >>> an incremental build, although it uses the constructor frame::frame(). >>> This makes incremental builds useless (or dangerous, depending on the >>> view point) when inline functions are changed. >>> >>> I think this is a non-trivial problem which is deeply rooted in the >>> way how C++ implements inlining and the way how inline functions are >>> defined in HotSpot (i.e. .hpp, .inline.hpp, _<cpu>.hpp and >>> _<cpu>.inline.hpp files). I don't have a solution for it but just >>> wanted to ask if somebody else already stumbled upon this problem >>> and/or has solution for it? >>> >>> Regards, >>> Volker
