I wonder if you're building on a 32 bit machine? It could be that somebody made an assumption about how big certain types are, and some function definitions which normally turn out to be the same thing are different if certain types are no longer equivalent. That would be my gut reaction to the second problem. Maybe add "override" in places where a virtual function is being overridden in the GPU code related to the error? I bet the compiler complains about at least one of them.
Gabe On Tue, Aug 14, 2018 at 5:46 AM Sampad Mohapatra <[email protected]> wrote: > I have tried building with both gcc 7.1 and gcc 5.4 and get the same set of > errors. > I am also using scons v3.1, Python 2.7.13, swig 3.0.12. All of these were > built from source. > > I use a cluster running Red Hat 4.4.7-18 (Linux version > 2.6.32-696.6.3.el6.x86_64). > > Thanks > Sampad > > > > On Tue, Aug 14, 2018 at 5:46 AM Ciro Santilli <[email protected]> > wrote: > > > What is your compiler version? > > > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <[email protected]> > wrote: > > > > > Hi All, > > > > > > I am facing compile issues while trying to compile > > > commit e02ec0c24d56bce4a0d8636a340e15cd223d1930 . > > > There are two types of errors in the Gem5 source: > > > > > > (1) *no matching function for call to : find(uint64_t&)* > > > > > > build/HSAIL_X86/gpu-compute/hsail_code.cc: In member function > > > 'StorageElement* StorageSpace::findSymbol(uint64_t)': > > > build/HSAIL_X86/gpu-compute/hsail_code.cc:336:41: error: no matching > > > function for call to 'AddrRangeMap<StorageElement*>::find(uint64_t&)' > > > auto se = elements_by_addr.find(addr); > > > ^ > > > In file included from build/HSAIL_X86/gpu-compute/hsail_code.hh:47:0, > > > from build/HSAIL_X86/gpu-compute/hsail_code.cc:36: > > > build/HSAIL_X86/base/addr_range_map.hh:225:5: note: candidate: > > > AddrRangeMap<V, max_cache_size>::const_iterator AddrRangeMap<V, > > > max_cache_size>::find(const AddrRange&, std::function<bool(AddrRange)>) > > > const [with V = StorageElement*; int max_cache_size = 0; > AddrRangeMap<V, > > > max_cache_size>::const_iterator = > > > std::_Rb_tree_const_iterator<std::pair<const AddrRange, > StorageElement*> > > > >] > > > find(const AddrRange &r, std::function<bool(const AddrRange)> > cond) > > > const > > > ^ > > > build/HSAIL_X86/base/addr_range_map.hh:225:5: note: candidate > expects 2 > > > arguments, 1 provided > > > > > > > > > (2) *Multiple issues due to object creation from virtual classes. For > > > example:* > > > > > > In file included from > > build/HSAIL_X86/gpu-compute/gpu_static_inst.hh:53:0, > > > from > > > build/HSAIL_X86/arch/hsail/insts/gpu_static_inst.hh:46, > > > from build/HSAIL_X86/arch/hsail/insts/branch.hh:39, > > > from build/HSAIL_X86/arch/hsail/gpu_decoder.cc:2: > > > build/HSAIL_X86/gpu-compute/gpu_dyn_inst.hh: In instantiation of > > > 'AtomicOpFunctor* GPUDynInst::makeAtomicOpFunctor(c0*, c0*) [with c0 = > > > long > > > unsigned int]': > > > build/HSAIL_X86/arch/hsail/insts/mem.hh:1625:54: required from 'void > > > HsailISA::AtomicInst<MemDataType, AddrOperandType, NumSrcOperands, > > > HasDst>::execAtomic(GPUDynInstPtr) [with MemDataType = > > > HsailISA::HsailDataType<HsailISA::HsailOperandType<DRegOperand, > > > RegOrImmOperand<DRegOperand, long unsigned int> >, long unsigned int, > > > (Enums::MemType)3u, (vgpr_type)1u, 1>; AddrOperandType = > > > RegAddrOperand<DRegOperand>; int NumSrcOperands = 1; bool HasDst = > true; > > > GPUDynInstPtr = std::shared_ptr<GPUDynInst>]' > > > build/HSAIL_X86/arch/hsail/gpu_decoder.cc:887:1: required from here > > > build/HSAIL_X86/gpu-compute/gpu_dyn_inst.hh:358:45: error: invalid > > > new-expression of abstract class type 'AtomicOpAnd<long unsigned int>' > > > return new AtomicOpAnd<c0>(*reg0); > > > ^ > > > build/HSAIL_X86/gpu-compute/gpu_dyn_inst.hh:50:7: note: because the > > > following virtual functions are pure within 'AtomicOpAnd<long unsigned > > > int>': > > > class AtomicOpAnd : public TypedAtomicOpFunctor<T> > > > > > > > > > Any help or pointers is highly appreciated. > > > > > > > > > Thanks and Regards, > > > Sampad Mohapatra > > > _______________________________________________ > > > gem5-dev mailing list > > > [email protected] > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&reserved=0 > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&reserved=0 > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
