Trouble finding the definition for class BarrierSet

[John Paul Adrian Glaubitz]

On 06/04/2018 10:18 PM, Erik Österlund wrote:
>> On 06/04/2018 09:47 PM, Erik Österlund wrote:
>>> Can't you just #include "gc/shared/barrierSet.hpp" in library_call.cpp?
>> Hmm. Let me try. But why would it be necessary on linux-sparc and not
>> anywhere else?
> 
> Not sure. But regardless of the case, that include should be in there anyway.

That fixes it. However, I then get:

/srv/openjdk/jdk/src/hotspot/share/opto/macroArrayCopy.cpp: In member function ‘Node* PhaseMacroExpand::generate_arraycopy(ArrayCopyNode*, AllocateArrayNode*,
Node**, MergeMemNode*, Node**, const TypePtr*, BasicType, Node*, Node*, Node*, Node*, Node*, bool, bool, RegionNode*)’:
/srv/openjdk/jdk/src/hotspot/share/opto/macroArrayCopy.cpp:553:36: error: incomplete type ‘BarrierSet’ used in nested name specifier
     BarrierSetC2* bs = BarrierSet::barrier_set()->barrier_set_c2();
                                    ^~~~~~~~~~~

I really wonder where the other architectures are getting it from.

There must be one feature/header etc that the other architectures are
including but that's being used on linux-sparc. But I cannot figure out what
we're missing.

>>> It is forward declared in oop.hpp, c1_LIRAssembler.hpp and  collectedHeap.hpp. Perhaps
>>> you got one of those accidentally.
>> You mean, I'm somehow pulling either of those headers in in library_call.cpp?
> 
> That sounds like the most natural explanation to me.

But why would these forward declarations hurt?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913