Missing/wrong build dependencies for inline functions in HotSpot

[Volker Simonis]

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
<keith.mcguigan at oracle.com> 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