Discussion:
[gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930
(too old to reply)
Sampad Mohapatra
2018-08-13 23:53:52 UTC
Permalink
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
Ciro Santilli
2018-08-14 09:46:08 UTC
Permalink
What is your compiler version?

On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu> 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
> gem5-***@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
Sampad Mohapatra
2018-08-14 12:46:13 UTC
Permalink
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 <***@gmail.com>
wrote:

> What is your compiler version?
>
> On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu> 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
> > gem5-***@gem5.org
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
Gabe Black
2018-08-14 21:25:32 UTC
Permalink
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 <***@psu.edu> 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 <***@gmail.com>
> wrote:
>
> > What is your compiler version?
> >
> > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu>
> 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
> > > gem5-***@gem5.org
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
Sampad Mohapatra
2018-08-16 15:35:44 UTC
Permalink
Hi Gabe,

I am building on a 64 bit cluster.

I might have found the reasons for the issues:

(1) There is no function "const_iterator find(Addr r) const" in
src/base/addr_range_map.hh.

(2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure
virtual function "clone()". This struct is the base for a

lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But
these classes don't define clone(). This results in
the errors I mentioned in (2).

Sampad

On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> 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 <***@psu.edu> 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 <***@gmail.com>
> wrote:
>
> > What is your compiler version?
> >
> > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu>
> 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
> > > gem5-***@gem5.org
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
Jason Lowe-Power
2018-08-16 16:46:03 UTC
Permalink
Hi Sampad,

It looks like you've found a hole in our testing ;). We don't compile HSAIL
regularly, and it looks like some bugs have worked their way in. Tony, do
you think you, or someone else that's familiar with the GPU model could
take a look?

Cheers,
Jason

On Thu, Aug 16, 2018 at 8:36 AM Sampad Mohapatra <***@psu.edu> wrote:

> Hi Gabe,
>
> I am building on a 64 bit cluster.
>
> I might have found the reasons for the issues:
>
> (1) There is no function "const_iterator find(Addr r) const" in
> src/base/addr_range_map.hh.
>
> (2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure
> virtual function "clone()". This struct is the base for a
>
> lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But
> these classes don't define clone(). This results in
> the errors I mentioned in (2).
>
> Sampad
>
> On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> > 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 <***@psu.edu> 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 <***@gmail.com>
> > wrote:
> >
> > > What is your compiler version?
> > >
> > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu>
> > 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
> > > > gem5-***@gem5.org
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> > > _______________________________________________
> > > gem5-dev mailing list
> > > gem5-***@gem5.org
> > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org
> > http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
Gutierrez, Anthony
2018-08-16 16:55:26 UTC
Permalink
Sampad, are you trying to run our GPU model? If so, HSAIL is deprecated. We released an updated version of our GPU simulator at gem5.googlesource.com/amd/gem5 branch agutierr/master-gcn3-staging. I recommend you starting with that.

I don’t think anybody at AMD will have time to look into HSAIL bugs for the time being, but doesn’t the current tester test at least 1 GPU program (gpu hello)? How did the changes get by the tester?

If you encounter issues with our GCN3 model, you can notify us through the gem5 mailing list.

From: Jason Lowe-Power <***@lowepower.com>
Sent: Thursday, August 16, 2018 9:46 AM
To: gem5 Developer List <gem5-***@gem5.org>; Gutierrez, Anthony <***@amd.com>
Subject: Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930

Hi Sampad,

It looks like you've found a hole in our testing ;). We don't compile HSAIL regularly, and it looks like some bugs have worked their way in. Tony, do you think you, or someone else that's familiar with the GPU model could take a look?

Cheers,
Jason

On Thu, Aug 16, 2018 at 8:36 AM Sampad Mohapatra <***@psu.edu<mailto:***@psu.edu>> wrote:
Hi Gabe,

I am building on a 64 bit cluster.

I might have found the reasons for the issues:

(1) There is no function "const_iterator find(Addr r) const" in
src/base/addr_range_map.hh.

(2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure
virtual function "clone()". This struct is the base for a

lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But
these classes don't define clone(). This results in
the errors I mentioned in (2).

Sampad

On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> 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 <***@psu.edu<mailto:***@psu.edu>> 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 <***@gmail.com<mailto:***@gmail.com>>
> wrote:
>
> > What is your compiler version?
> >
> > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu<mailto:***@psu.edu>>
> 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
> > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-***@gem5.org<mailto:gem5-***@gem5.org>
http://m5sim.org/mailman/listinfo/gem5-dev
Jason Lowe-Power
2018-08-16 17:05:02 UTC
Permalink
Hey Tony,

If HSAIL is deprecated, should we remove it from the public repo?

Also, from the nightly regressions the GPU test is broken:

scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.do] Error 1
> scons: *** [build/HSAIL_X86/arch/hsail/gpu_decoder.do] Error 1
> scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.fo] Error 1


Though, we've all been ignoring the emails from zizzer for a while now.
Which reminds me, I would love some help porting tests over to the new
infrastructure that will (hopefully) resolve these issues since it's easier
to use.

Cheers,
Jason

On Thu, Aug 16, 2018 at 9:55 AM Gutierrez, Anthony <
***@amd.com> wrote:

> Sampad, are you trying to run our GPU model? If so, HSAIL is deprecated.
> We released an updated version of our GPU simulator at
> gem5.googlesource.com/amd/gem5 branch agutierr/master-gcn3-staging. I
> recommend you starting with that.
>
> I don’t think anybody at AMD will have time to look into HSAIL bugs for
> the time being, but doesn’t the current tester test at least 1 GPU program
> (gpu hello)? How did the changes get by the tester?
>
> If you encounter issues with our GCN3 model, you can notify us through the
> gem5 mailing list.
>
> From: Jason Lowe-Power <***@lowepower.com>
> Sent: Thursday, August 16, 2018 9:46 AM
> To: gem5 Developer List <gem5-***@gem5.org>; Gutierrez, Anthony <
> ***@amd.com>
> Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Hi Sampad,
>
> It looks like you've found a hole in our testing ;). We don't compile
> HSAIL regularly, and it looks like some bugs have worked their way in.
> Tony, do you think you, or someone else that's familiar with the GPU model
> could take a look?
>
> Cheers,
> Jason
>
> On Thu, Aug 16, 2018 at 8:36 AM Sampad Mohapatra <***@psu.edu<mailto:
> ***@psu.edu>> wrote:
> Hi Gabe,
>
> I am building on a 64 bit cluster.
>
> I might have found the reasons for the issues:
>
> (1) There is no function "const_iterator find(Addr r) const" in
> src/base/addr_range_map.hh.
>
> (2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure
> virtual function "clone()". This struct is the base for a
>
> lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But
> these classes don't define clone(). This results in
> the errors I mentioned in (2).
>
> Sampad
>
> On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> > 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 <***@psu.edu<mailto:
> ***@psu.edu>> 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 <***@gmail.com
> <mailto:***@gmail.com>>
> > wrote:
> >
> > > What is your compiler version?
> > >
> > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu
> <mailto:***@psu.edu>>
> > 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
> > > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> > > _______________________________________________
> > > gem5-dev mailing list
> > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
Gutierrez, Anthony
2018-08-16 18:24:00 UTC
Permalink
Did the recent changes break that? Last time I pushed to the public and ran the tester gpu-hello worked. I'm guessing whichever change broken this was not ever tested using the regression tester?

HSAIL is deprecated meaning we no longer support it, but that said it should still work. We plan on trying to push our GCN3 model to the master branch, which is what removes HSAIL and we'd prefer to remove it from master that way, but as you know there are issues with that currently. We have some problematic changes to SE mode that need to be fixed up, as they are not likely to pass public review, although I believe they are functionally correct.

Brandon may have a better idea of what needs to be done.

-----Original Message-----
From: gem5-dev <gem5-dev-***@gem5.org> On Behalf Of Jason Lowe-Power
Sent: Thursday, August 16, 2018 10:05 AM
To: gem5 Developer List <gem5-***@gem5.org>
Subject: Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930

Hey Tony,

If HSAIL is deprecated, should we remove it from the public repo?

Also, from the nightly regressions the GPU test is broken:

scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.do] Error 1
> scons: *** [build/HSAIL_X86/arch/hsail/gpu_decoder.do] Error 1
> scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.fo] Error 1


Though, we've all been ignoring the emails from zizzer for a while now.
Which reminds me, I would love some help porting tests over to the new infrastructure that will (hopefully) resolve these issues since it's easier to use.

Cheers,
Jason

On Thu, Aug 16, 2018 at 9:55 AM Gutierrez, Anthony < ***@amd.com> wrote:

> Sampad, are you trying to run our GPU model? If so, HSAIL is deprecated.
> We released an updated version of our GPU simulator at
> gem5.googlesource.com/amd/gem5 branch agutierr/master-gcn3-staging. I
> recommend you starting with that.
>
> I don’t think anybody at AMD will have time to look into HSAIL bugs
> for the time being, but doesn’t the current tester test at least 1 GPU
> program (gpu hello)? How did the changes get by the tester?
>
> If you encounter issues with our GCN3 model, you can notify us through
> the
> gem5 mailing list.
>
> From: Jason Lowe-Power <***@lowepower.com>
> Sent: Thursday, August 16, 2018 9:46 AM
> To: gem5 Developer List <gem5-***@gem5.org>; Gutierrez, Anthony <
> ***@amd.com>
> Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Hi Sampad,
>
> It looks like you've found a hole in our testing ;). We don't compile
> HSAIL regularly, and it looks like some bugs have worked their way in.
> Tony, do you think you, or someone else that's familiar with the GPU
> model could take a look?
>
> Cheers,
> Jason
>
> On Thu, Aug 16, 2018 at 8:36 AM Sampad Mohapatra <***@psu.edu<mailto:
> ***@psu.edu>> wrote:
> Hi Gabe,
>
> I am building on a 64 bit cluster.
>
> I might have found the reasons for the issues:
>
> (1) There is no function "const_iterator find(Addr r) const" in
> src/base/addr_range_map.hh.
>
> (2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure
> virtual function "clone()". This struct is the base for a
>
> lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But
> these classes don't define clone(). This results in
> the errors I mentioned in (2).
>
> Sampad
>
> On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> > 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 <***@psu.edu<mailto:
> ***@psu.edu>> 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
> > <***@gmail.com
> <mailto:***@gmail.com>>
> > wrote:
> >
> > > What is your compiler version?
> > >
> > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu
> <mailto:***@psu.edu>>
> > 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
> > > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.
> org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu
> %7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e
> %7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwH
> LzAaMooGIB2kxMU%3D&amp;reserved=0
> > > _______________________________________________
> > > gem5-dev mailing list
> > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.
> org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu
> %7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e
> %7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwH
> LzAaMooGIB2kxMU%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-***@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Potter, Brandon
2018-08-17 01:11:31 UTC
Permalink
Hello all,

The hsail-x86 target will compile with the following changes. I tried running the gpu-hello program with the build and it prints "lelellelelelel" instead of "hello*". FWIW, the code compiles now which is an improvement.

https://gem5-review.googlesource.com/c/public/gem5/+/12107
https://gem5-review.googlesource.com/c/public/gem5/+/12108

We are currently in the process of making the GCN3 implementation public which will supplant the hsail-x86 target entirely. The newer code should appear in the gem5 source within the next few weeks.

Regards,
Brandon

P.S. Buy EPYC instead of Xeon.

-----Original Message-----
From: Gutierrez, Anthony
Sent: Thursday, August 16, 2018 1:24 PM
To: gem5 Developer List <gem5-***@gem5.org>
Cc: Potter, Brandon <***@amd.com>
Subject: RE: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930

Did the recent changes break that? Last time I pushed to the public and ran the tester gpu-hello worked. I'm guessing whichever change broken this was not ever tested using the regression tester?

HSAIL is deprecated meaning we no longer support it, but that said it should still work. We plan on trying to push our GCN3 model to the master branch, which is what removes HSAIL and we'd prefer to remove it from master that way, but as you know there are issues with that currently. We have some problematic changes to SE mode that need to be fixed up, as they are not likely to pass public review, although I believe they are functionally correct.

Brandon may have a better idea of what needs to be done.

-----Original Message-----
From: gem5-dev <gem5-dev-***@gem5.org> On Behalf Of Jason Lowe-Power
Sent: Thursday, August 16, 2018 10:05 AM
To: gem5 Developer List <gem5-***@gem5.org>
Subject: Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930

Hey Tony,

If HSAIL is deprecated, should we remove it from the public repo?

Also, from the nightly regressions the GPU test is broken:

scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.do] Error 1
> scons: *** [build/HSAIL_X86/arch/hsail/gpu_decoder.do] Error 1
> scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.fo] Error 1


Though, we've all been ignoring the emails from zizzer for a while now.
Which reminds me, I would love some help porting tests over to the new infrastructure that will (hopefully) resolve these issues since it's easier to use.

Cheers,
Jason

On Thu, Aug 16, 2018 at 9:55 AM Gutierrez, Anthony < ***@amd.com> wrote:

> Sampad, are you trying to run our GPU model? If so, HSAIL is deprecated.
> We released an updated version of our GPU simulator at
> gem5.googlesource.com/amd/gem5 branch agutierr/master-gcn3-staging. I
> recommend you starting with that.
>
> I don’t think anybody at AMD will have time to look into HSAIL bugs
> for the time being, but doesn’t the current tester test at least 1 GPU
> program (gpu hello)? How did the changes get by the tester?
>
> If you encounter issues with our GCN3 model, you can notify us through
> the
> gem5 mailing list.
>
> From: Jason Lowe-Power <***@lowepower.com>
> Sent: Thursday, August 16, 2018 9:46 AM
> To: gem5 Developer List <gem5-***@gem5.org>; Gutierrez, Anthony <
> ***@amd.com>
> Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Hi Sampad,
>
> It looks like you've found a hole in our testing ;). We don't compile
> HSAIL regularly, and it looks like some bugs have worked their way in.
> Tony, do you think you, or someone else that's familiar with the GPU
> model could take a look?
>
> Cheers,
> Jason
>
> On Thu, Aug 16, 2018 at 8:36 AM Sampad Mohapatra <***@psu.edu<mailto:
> ***@psu.edu>> wrote:
> Hi Gabe,
>
> I am building on a 64 bit cluster.
>
> I might have found the reasons for the issues:
>
> (1) There is no function "const_iterator find(Addr r) const" in
> src/base/addr_range_map.hh.
>
> (2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure
> virtual function "clone()". This struct is the base for a
>
> lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But
> these classes don't define clone(). This results in
> the errors I mentioned in (2).
>
> Sampad
>
> On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> > 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 <***@psu.edu<mailto:
> ***@psu.edu>> 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
> > <***@gmail.com
> <mailto:***@gmail.com>>
> > wrote:
> >
> > > What is your compiler version?
> > >
> > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu
> <mailto:***@psu.edu>>
> > 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
> > > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.
> org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu
> %7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e
> %7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwH
> LzAaMooGIB2kxMU%3D&amp;reserved=0
> > > _______________________________________________
> > > gem5-dev mailing list
> > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.
> org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu
> %7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e
> %7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwH
> LzAaMooGIB2kxMU%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-***@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Sampad Mohapatra
2018-08-17 17:31:44 UTC
Permalink
Hi all,

Thank you for your help.
As Brandon pointed out that the test prog prints wrong values, can anyone
point out the commit that contains a relatively stable GPU model (HSAIL).

Regards
Sampad

On Thu, Aug 16, 2018 at 9:11 PM Potter, Brandon <***@amd.com>
wrote:

> Hello all,
>
> The hsail-x86 target will compile with the following changes. I tried
> running the gpu-hello program with the build and it prints "lelellelelelel"
> instead of "hello*". FWIW, the code compiles now which is an improvement.
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F12107&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=LaslfnQGn5DmoYop8Knf3zcul4OUs9C8fVpq9VH5GFU%3D&amp;reserved=0
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F12108&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=lw5cTUcyavi80bxe8EBh62u2kwY3FdbPnzmKLBXa8xY%3D&amp;reserved=0
>
> We are currently in the process of making the GCN3 implementation public
> which will supplant the hsail-x86 target entirely. The newer code should
> appear in the gem5 source within the next few weeks.
>
> Regards,
> Brandon
>
> P.S. Buy EPYC instead of Xeon.
>
> -----Original Message-----
> From: Gutierrez, Anthony
> Sent: Thursday, August 16, 2018 1:24 PM
> To: gem5 Developer List <gem5-***@gem5.org>
> Cc: Potter, Brandon <***@amd.com>
> Subject: RE: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Did the recent changes break that? Last time I pushed to the public and
> ran the tester gpu-hello worked. I'm guessing whichever change broken this
> was not ever tested using the regression tester?
>
> HSAIL is deprecated meaning we no longer support it, but that said it
> should still work. We plan on trying to push our GCN3 model to the master
> branch, which is what removes HSAIL and we'd prefer to remove it from
> master that way, but as you know there are issues with that currently. We
> have some problematic changes to SE mode that need to be fixed up, as they
> are not likely to pass public review, although I believe they are
> functionally correct.
>
> Brandon may have a better idea of what needs to be done.
>
> -----Original Message-----
> From: gem5-dev <gem5-dev-***@gem5.org> On Behalf Of Jason Lowe-Power
> Sent: Thursday, August 16, 2018 10:05 AM
> To: gem5 Developer List <gem5-***@gem5.org>
> Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Hey Tony,
>
> If HSAIL is deprecated, should we remove it from the public repo?
>
> Also, from the nightly regressions the GPU test is broken:
>
> scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.do] Error 1
> > scons: *** [build/HSAIL_X86/arch/hsail/gpu_decoder.do] Error 1
> > scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.fo] Error 1
>
>
> Though, we've all been ignoring the emails from zizzer for a while now.
> Which reminds me, I would love some help porting tests over to the new
> infrastructure that will (hopefully) resolve these issues since it's easier
> to use.
>
> Cheers,
> Jason
>
> On Thu, Aug 16, 2018 at 9:55 AM Gutierrez, Anthony <
> ***@amd.com> wrote:
>
> > Sampad, are you trying to run our GPU model? If so, HSAIL is deprecated.
> > We released an updated version of our GPU simulator at
> > gem5.googlesource.com/amd/gem5 branch agutierr/master-gcn3-staging. I
> > recommend you starting with that.
> >
> > I don’t think anybody at AMD will have time to look into HSAIL bugs
> > for the time being, but doesn’t the current tester test at least 1 GPU
> > program (gpu hello)? How did the changes get by the tester?
> >
> > If you encounter issues with our GCN3 model, you can notify us through
> > the
> > gem5 mailing list.
> >
> > From: Jason Lowe-Power <***@lowepower.com>
> > Sent: Thursday, August 16, 2018 9:46 AM
> > To: gem5 Developer List <gem5-***@gem5.org>; Gutierrez, Anthony <
> > ***@amd.com>
> > Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> > e02ec0c24d56bce4a0d8636a340e15cd223d1930
> >
> > Hi Sampad,
> >
> > It looks like you've found a hole in our testing ;). We don't compile
> > HSAIL regularly, and it looks like some bugs have worked their way in.
> > Tony, do you think you, or someone else that's familiar with the GPU
> > model could take a look?
> >
> > Cheers,
> > Jason
> >
> > On Thu, Aug 16, 2018 at 8:36 AM Sampad Mohapatra <***@psu.edu<mailto:
> > ***@psu.edu>> wrote:
> > Hi Gabe,
> >
> > I am building on a 64 bit cluster.
> >
> > I might have found the reasons for the issues:
> >
> > (1) There is no function "const_iterator find(Addr r) const" in
> > src/base/addr_range_map.hh.
> >
> > (2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure
> > virtual function "clone()". This struct is the base for a
> >
> > lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But
> > these classes don't define clone(). This results in
> > the errors I mentioned in (2).
> >
> > Sampad
> >
> > On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> > > 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 <***@psu.edu<mailto:
> > ***@psu.edu>> 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
> > > <***@gmail.com
> > <mailto:***@gmail.com>>
> > > wrote:
> > >
> > > > What is your compiler version?
> > > >
> > > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu
> > <mailto:***@psu.edu>>
> > > 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
> > > > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > > > >
> > > >
> > >
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.
> > org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu
> > %7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e
> > %7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwH
> > LzAaMooGIB2kxMU%3D&amp;reserved=0
> > > > _______________________________________________
> > > > gem5-dev mailing list
> > > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > > >
> > > >
> > >
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.
> > org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu
> > %7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e
> > %7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwH
> > LzAaMooGIB2kxMU%3D&amp;reserved=0
> > > _______________________________________________
> > > gem5-dev mailing list
> > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=K1MV8MYu0GlBfXd9QIB36PYyBFp2zZLPZnZpXNcdD%2FE%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=K1MV8MYu0GlBfXd9QIB36PYyBFp2zZLPZnZpXNcdD%2FE%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=K1MV8MYu0GlBfXd9QIB36PYyBFp2zZLPZnZpXNcdD%2FE%3D&amp;reserved=0
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=K1MV8MYu0GlBfXd9QIB36PYyBFp2zZLPZnZpXNcdD%2FE%3D&amp;reserved=0
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=K1MV8MYu0GlBfXd9QIB36PYyBFp2zZLPZnZpXNcdD%2FE%3D&amp;reserved=0
Gutierrez, Anthony
2018-08-17 14:26:11 UTC
Permalink
That print was always that way if I remember correctly. It may be a problem with the application itself.
________________________________
From: gem5-dev <gem5-dev-***@gem5.org> on behalf of Sampad Mohapatra <***@psu.edu>
Sent: Friday, August 17, 2018 10:31:44 AM
To: gem5-***@gem5.org
Subject: Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930

Hi all,

Thank you for your help.
As Brandon pointed out that the test prog prints wrong values, can anyone
point out the commit that contains a relatively stable GPU model (HSAIL).

Regards
Sampad

On Thu, Aug 16, 2018 at 9:11 PM Potter, Brandon <***@amd.com>
wrote:

> Hello all,
>
> The hsail-x86 target will compile with the following changes. I tried
> running the gpu-hello program with the build and it prints "lelellelelelel"
> instead of "hello*". FWIW, the code compiles now which is an improvement.
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F12107&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=LaslfnQGn5DmoYop8Knf3zcul4OUs9C8fVpq9VH5GFU%3D&amp;reserved=0
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F12108&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=lw5cTUcyavi80bxe8EBh62u2kwY3FdbPnzmKLBXa8xY%3D&amp;reserved=0
>
> We are currently in the process of making the GCN3 implementation public
> which will supplant the hsail-x86 target entirely. The newer code should
> appear in the gem5 source within the next few weeks.
>
> Regards,
> Brandon
>
> P.S. Buy EPYC instead of Xeon.
>
> -----Original Message-----
> From: Gutierrez, Anthony
> Sent: Thursday, August 16, 2018 1:24 PM
> To: gem5 Developer List <gem5-***@gem5.org>
> Cc: Potter, Brandon <***@amd.com>
> Subject: RE: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Did the recent changes break that? Last time I pushed to the public and
> ran the tester gpu-hello worked. I'm guessing whichever change broken this
> was not ever tested using the regression tester?
>
> HSAIL is deprecated meaning we no longer support it, but that said it
> should still work. We plan on trying to push our GCN3 model to the master
> branch, which is what removes HSAIL and we'd prefer to remove it from
> master that way, but as you know there are issues with that currently. We
> have some problematic changes to SE mode that need to be fixed up, as they
> are not likely to pass public review, although I believe they are
> functionally correct.
>
> Brandon may have a better idea of what needs to be done.
>
> -----Original Message-----
> From: gem5-dev <gem5-dev-***@gem5.org> On Behalf Of Jason Lowe-Power
> Sent: Thursday, August 16, 2018 10:05 AM
> To: gem5 Developer List <gem5-***@gem5.org>
> Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Hey Tony,
>
> If HSAIL is deprecated, should we remove it from the public repo?
>
> Also, from the nightly regressions the GPU test is broken:
>
> scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.do] Error 1
> > scons: *** [build/HSAIL_X86/arch/hsail/gpu_decoder.do] Error 1
> > scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.fo] Error 1
>
>
> Though, we've all been ignoring the emails from zizzer for a while now.
> Which reminds me, I would love some help porting tests over to the new
> infrastructure that will (hopefully) resolve these issues since it's easier
> to use.
>
> Cheers,
> Jason
>
> On Thu, Aug 16, 2018 at 9:55 AM Gutierrez, Anthony <
> ***@amd.com> wrote:
>
> > Sampad, are you trying to run our GPU model? If so, HSAIL is deprecated.
> > We released an updated version of our GPU simulator at
> > gem5.googlesource.com/amd/gem5 branch agutierr/master-gcn3-staging. I
> > recommend you starting with that.
> >
> > I don’t think anybody at AMD will have time to look into HSAIL bugs
> > for the time being, but doesn’t the current tester test at least 1 GPU
> > program (gpu hello)? How did the changes get by the tester?
> >
> > If you encounter issues with our GCN3 model, you can notify us through
> > the
> > gem5 mailing list.
> >
> > From: Jason Lowe-Power <***@lowepower.com>
> > Sent: Thursday, August 16, 2018 9:46 AM
> > To: gem5 Developer List <gem5-***@gem5.org>; Gutierrez, Anthony <
> > ***@amd.com>
> > Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> > e02ec0c24d56bce4a0d8636a340e15cd223d1930
> >
> > Hi Sampad,
> >
> > It looks like you've found a hole in our testing ;). We don't compile
> > HSAIL regularly, and it looks like some bugs have worked their way in.
> > Tony, do you think you, or someone else that's familiar with the GPU
> > model could take a look?
> >
> > Cheers,
> > Jason
> >
> > On Thu, Aug 16, 2018 at 8:36 AM Sampad Mohapatra <***@psu.edu<mailto:
> > ***@psu.edu>> wrote:
> > Hi Gabe,
> >
> > I am building on a 64 bit cluster.
> >
> > I might have found the reasons for the issues:
> >
> > (1) There is no function "const_iterator find(Addr r) const" in
> > src/base/addr_range_map.hh.
> >
> > (2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure
> > virtual function "clone()". This struct is the base for a
> >
> > lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But
> > these classes don't define clone(). This results in
> > the errors I mentioned in (2).
> >
> > Sampad
> >
> > On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> > > 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 <***@psu.edu<mailto:
> > ***@psu.edu>> 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
> > > <***@gmail.com
> > <mailto:***@gmail.com>>
> > > wrote:
> > >
> > > > What is your compiler version?
> > > >
> > > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu
> > <mailto:***@psu.edu>>
> > > 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
> > > > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > > > >
> > > >
> > >
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.
> > org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu
> > %7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e
> > %7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwH
> > LzAaMooGIB2kxMU%3D&amp;reserved=0
> > > > _______________________________________________
> > > > gem5-dev mailing list
> > > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > > >
> > > >
> > >
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.
> > org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu
> > %7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e
> > %7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwH
> > LzAaMooGIB2kxMU%3D&amp;reserved=0
> > > _______________________________________________
> > > gem5-dev mailing list
> > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=K1MV8MYu0GlBfXd9QIB36PYyBFp2zZLPZnZpXNcdD%2FE%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=K1MV8MYu0GlBfXd9QIB36PYyBFp2zZLPZnZpXNcdD%2FE%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=K1MV8MYu0GlBfXd9QIB36PYyBFp2zZLPZnZpXNcdD%2FE%3D&amp;reserved=0
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=K1MV8MYu0GlBfXd9QIB36PYyBFp2zZLPZnZpXNcdD%2FE%3D&amp;reserved=0
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&amp;sdata=K1MV8MYu0GlBfXd9QIB36PYyBFp2zZLPZnZpXNcdD%2FE%3D&amp;reserved=0
_______________________________________________
gem5-dev mailing list
gem5-***@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Sampad Mohapatra
2018-08-17 14:41:05 UTC
Permalink
Ok.

Thanks a lot.

On Fri, Aug 17, 2018 at 10:37 AM Gutierrez, Anthony <
***@amd.com> wrote:

> That print was always that way if I remember correctly. It may be a
> problem with the application itself.
> ________________________________
> From: gem5-dev <gem5-dev-***@gem5.org> on behalf of Sampad Mohapatra <
> ***@psu.edu>
> Sent: Friday, August 17, 2018 10:31:44 AM
> To: gem5-***@gem5.org
> Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Hi all,
>
> Thank you for your help.
> As Brandon pointed out that the test prog prints wrong values, can anyone
> point out the commit that contains a relatively stable GPU model (HSAIL).
>
> Regards
> Sampad
>
> On Thu, Aug 16, 2018 at 9:11 PM Potter, Brandon <***@amd.com>
> wrote:
>
> > Hello all,
> >
> > The hsail-x86 target will compile with the following changes. I tried
> > running the gpu-hello program with the build and it prints
> "lelellelelelel"
> > instead of "hello*". FWIW, the code compiles now which is an improvement.
> >
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F12107&amp;data=02%7C01%7Csum94%40psu.edu%7Ce0a1a0d4a46c45c6e32408d6044ef10c%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636701134429317598&amp;sdata=cvBKigh7YGWdomYJBiimjJgJklUlcXRosAnJ9XtS8lo%3D&amp;reserved=0
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F12108&amp;data=02%7C01%7Csum94%40psu.edu%7Ce0a1a0d4a46c45c6e32408d6044ef10c%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636701134429317598&amp;sdata=WevEQjiGO4BAQ9mXO27DmMETcVmfZb9Gkt349P%2BIPAk%3D&amp;reserved=0
> >
> > We are currently in the process of making the GCN3 implementation public
> > which will supplant the hsail-x86 target entirely. The newer code should
> > appear in the gem5 source within the next few weeks.
> >
> > Regards,
> > Brandon
> >
> > P.S. Buy EPYC instead of Xeon.
> >
> > -----Original Message-----
> > From: Gutierrez, Anthony
> > Sent: Thursday, August 16, 2018 1:24 PM
> > To: gem5 Developer List <gem5-***@gem5.org>
> > Cc: Potter, Brandon <***@amd.com>
> > Subject: RE: [gem5-dev] Gem5 Compile issue : Commit :
> > e02ec0c24d56bce4a0d8636a340e15cd223d1930
> >
> > Did the recent changes break that? Last time I pushed to the public and
> > ran the tester gpu-hello worked. I'm guessing whichever change broken
> this
> > was not ever tested using the regression tester?
> >
> > HSAIL is deprecated meaning we no longer support it, but that said it
> > should still work. We plan on trying to push our GCN3 model to the master
> > branch, which is what removes HSAIL and we'd prefer to remove it from
> > master that way, but as you know there are issues with that currently. We
> > have some problematic changes to SE mode that need to be fixed up, as
> they
> > are not likely to pass public review, although I believe they are
> > functionally correct.
> >
> > Brandon may have a better idea of what needs to be done.
> >
> > -----Original Message-----
> > From: gem5-dev <gem5-dev-***@gem5.org> On Behalf Of Jason Lowe-Power
> > Sent: Thursday, August 16, 2018 10:05 AM
> > To: gem5 Developer List <gem5-***@gem5.org>
> > Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> > e02ec0c24d56bce4a0d8636a340e15cd223d1930
> >
> > Hey Tony,
> >
> > If HSAIL is deprecated, should we remove it from the public repo?
> >
> > Also, from the nightly regressions the GPU test is broken:
> >
> > scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.do] Error 1
> > > scons: *** [build/HSAIL_X86/arch/hsail/gpu_decoder.do] Error 1
> > > scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.fo] Error 1
> >
> >
> > Though, we've all been ignoring the emails from zizzer for a while now.
> > Which reminds me, I would love some help porting tests over to the new
> > infrastructure that will (hopefully) resolve these issues since it's
> easier
> > to use.
> >
> > Cheers,
> > Jason
> >
> > On Thu, Aug 16, 2018 at 9:55 AM Gutierrez, Anthony <
> > ***@amd.com> wrote:
> >
> > > Sampad, are you trying to run our GPU model? If so, HSAIL is
> deprecated.
> > > We released an updated version of our GPU simulator at
> > > gem5.googlesource.com/amd/gem5 branch agutierr/master-gcn3-staging. I
> > > recommend you starting with that.
> > >
> > > I don’t think anybody at AMD will have time to look into HSAIL bugs
> > > for the time being, but doesn’t the current tester test at least 1 GPU
> > > program (gpu hello)? How did the changes get by the tester?
> > >
> > > If you encounter issues with our GCN3 model, you can notify us through
> > > the
> > > gem5 mailing list.
> > >
> > > From: Jason Lowe-Power <***@lowepower.com>
> > > Sent: Thursday, August 16, 2018 9:46 AM
> > > To: gem5 Developer List <gem5-***@gem5.org>; Gutierrez, Anthony <
> > > ***@amd.com>
> > > Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> > > e02ec0c24d56bce4a0d8636a340e15cd223d1930
> > >
> > > Hi Sampad,
> > >
> > > It looks like you've found a hole in our testing ;). We don't compile
> > > HSAIL regularly, and it looks like some bugs have worked their way in.
> > > Tony, do you think you, or someone else that's familiar with the GPU
> > > model could take a look?
> > >
> > > Cheers,
> > > Jason
> > >
> > > On Thu, Aug 16, 2018 at 8:36 AM Sampad Mohapatra <***@psu.edu
> <mailto:
> > > ***@psu.edu>> wrote:
> > > Hi Gabe,
> > >
> > > I am building on a 64 bit cluster.
> > >
> > > I might have found the reasons for the issues:
> > >
> > > (1) There is no function "const_iterator find(Addr r) const" in
> > > src/base/addr_range_map.hh.
> > >
> > > (2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure
> > > virtual function "clone()". This struct is the base for a
> > >
> > > lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But
> > > these classes don't define clone(). This results in
> > > the errors I mentioned in (2).
> > >
> > > Sampad
> > >
> > > On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> > > > 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 <***@psu.edu
> <mailto:
> > > ***@psu.edu>> 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
> > > > <***@gmail.com
> > > <mailto:***@gmail.com>>
> > > > wrote:
> > > >
> > > > > What is your compiler version?
> > > > >
> > > > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <***@psu.edu
> > > <mailto:***@psu.edu>>
> > > > 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
> > > > > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > > > > >
> > > > >
> > > >
> > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.
> > > org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu
> > > %7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e
> > > %7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwH
> > > LzAaMooGIB2kxMU%3D&amp;reserved=0
> > > > > _______________________________________________
> > > > > gem5-dev mailing list
> > > > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > > > >
> > > > >
> > > >
> > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.
> > > org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu
> > > %7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e
> > > %7C0%7C0%7C636698367962416116&amp;sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwH
> > > LzAaMooGIB2kxMU%3D&amp;reserved=0
> > > > _______________________________________________
> > > > gem5-dev mailing list
> > > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce0a1a0d4a46c45c6e32408d6044ef10c%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636701134429317598&amp;sdata=a04UY0z5MRHxachFzxNoZpIS1koxUiHlYoraVVpwcEQ%3D&amp;reserved=0
> > > _______________________________________________
> > > gem5-dev mailing list
> > > gem5-***@gem5.org<mailto:gem5-***@gem5.org>
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce0a1a0d4a46c45c6e32408d6044ef10c%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636701134429317598&amp;sdata=a04UY0z5MRHxachFzxNoZpIS1koxUiHlYoraVVpwcEQ%3D&amp;reserved=0
> > > _______________________________________________
> > > gem5-dev mailing list
> > > gem5-***@gem5.org
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce0a1a0d4a46c45c6e32408d6044ef10c%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636701134429317598&amp;sdata=a04UY0z5MRHxachFzxNoZpIS1koxUiHlYoraVVpwcEQ%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce0a1a0d4a46c45c6e32408d6044ef10c%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636701134429317598&amp;sdata=a04UY0z5MRHxachFzxNoZpIS1koxUiHlYoraVVpwcEQ%3D&amp;reserved=0
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-***@gem5.org
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce0a1a0d4a46c45c6e32408d6044ef10c%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636701134429317598&amp;sdata=a04UY0z5MRHxachFzxNoZpIS1koxUiHlYoraVVpwcEQ%3D&amp;reserved=0
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce0a1a0d4a46c45c6e32408d6044ef10c%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636701134429317598&amp;sdata=a04UY0z5MRHxachFzxNoZpIS1koxUiHlYoraVVpwcEQ%3D&amp;reserved=0
> _______________________________________________
> gem5-dev mailing list
> gem5-***@gem5.org
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-dev&amp;data=02%7C01%7Csum94%40psu.edu%7Ce0a1a0d4a46c45c6e32408d6044ef10c%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636701134429317598&amp;sdata=a04UY0z5MRHxachFzxNoZpIS1koxUiHlYoraVVpwcEQ%3D&amp;reserved=0
Continue reading on narkive:
Loading...