Should this change be against http://hg.openjdk.java.net/jdk8/build/hotspot or better for http://hg.openjdk.java.net/hsx/hotspot-main/hotspot?
On Mon, Jun 11, 2012 at 12:01 PM, Volker Simonis <[email protected]> wrote: > 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
