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 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%2F12107data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326sdata=LaslfnQGn5DmoYop8Knf3zcul4OUs9C8fVpq9VH5GFU%3Dreserved=0 > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F12108data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326sdata=lw5cTUcyavi80bxe8EBh62u2kwY3FdbPnzmKLBXa8xY%3Dreserved=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 > Cc: Potter, Brandon > 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 On Behalf Of Jason Lowe-Power > Sent: Thursday, August 16, 2018 10:05 AM > To: gem5 Developer List > 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 < > anthony.gutier...@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 > > Sent: Thursday, August 16, 2018 9:46 AM > > To: gem5 Developer List ; Gutierrez, Anthony < > > anthony.gutier...@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 > su
Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930
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 Cc: Potter, Brandon 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 On Behalf Of Jason Lowe-Power Sent: Thursday, August 16, 2018 10:05 AM To: gem5 Developer List 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 < anthony.gutier...@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 > Sent: Thursday, August 16, 2018 9:46 AM > To: gem5 Developer List ; Gutierrez, Anthony < > anthony.gutier...@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 su...@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. > > &
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 On Behalf Of Jason Lowe-Power Sent: Thursday, August 16, 2018 10:05 AM To: gem5 Developer List 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 < anthony.gutier...@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 > Sent: Thursday, August 16, 2018 9:46 AM > To: gem5 Developer List ; Gutierrez, Anthony < > anthony.gutier...@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 su...@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 su...@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 > > <mailto:ciro.santi...@gmail.com>> > > wrote: > > > > > What is your compiler version? > > > > > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <mailto:su...@psu.edu>> > > wrote: > > > > >
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 < anthony.gutier...@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 > Sent: Thursday, August 16, 2018 9:46 AM > To: gem5 Developer List ; Gutierrez, Anthony < > anthony.gutier...@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 su...@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 su...@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 <mailto:ciro.santi...@gmail.com>> > > wrote: > > > > > What is your compiler version? > > > > > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra <mailto:su...@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::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: >
Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930
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 Sent: Thursday, August 16, 2018 9:46 AM To: gem5 Developer List ; Gutierrez, Anthony 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 mailto:su...@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 mailto:su...@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 > mailto:ciro.santi...@gmail.com>> > wrote: > > > What is your compiler version? > > > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra > > mailto:su...@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::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::const_iterator AddrRangeMap > > max_cache_size>::find(const AddrRange&, std::function) > > > const [with V = StorageElement*; int max_cache_size = 0; > AddrRangeMap > > max_cache_size>::const_iterator = > > > std::_Rb_tree_const_iterator StorageElement*> > > > >] > > > find(const AddrRange , std::function > 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_
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 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 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 > > wrote: > > > > > What is your compiler version? > > > > > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra > > 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::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::const_iterator AddrRangeMap > > > max_cache_size>::find(const AddrRange&, > std::function) > > > > const [with V = StorageElement*; int max_cache_size = 0; > > AddrRangeMap > > > max_cache_size>::const_iterator = > > > > std::_Rb_tree_const_iterator > StorageElement*> > > > > >] > > > > find(const AddrRange , std::function > > 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 > > > HasDst>::execAtomic(GPUDynInstPtr) [with MemDataType = > > > > HsailISA::HsailDataType > > > RegOrImmOperand >, long unsigned int, > > > > (Enums::MemType)3u, (vgpr_type)1u, 1>; AddrOperandType = > > > > RegAddrOperand; int NumSrcOperands = 1; bool HasDst = > > true; > > > > GPUDynInstPtr = std::shared_ptr]' > > > > 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 int>' > > > > return new AtomicOpAnd(*reg0); > > > > ^ > > > > build/HSAIL_X86/gpu-compute/gpu_dyn_inst.hh:50:7: note: because the > > > > following virtual functions are pure within 'AtomicOpAnd unsigned > > > > int>': > > > > class AtomicOpAnd : public TypedAtomicOpFunctor > > > > > >
Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930
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 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 > wrote: > > > What is your compiler version? > > > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra > 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::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::const_iterator AddrRangeMap > > max_cache_size>::find(const AddrRange&, std::function) > > > const [with V = StorageElement*; int max_cache_size = 0; > AddrRangeMap > > max_cache_size>::const_iterator = > > > std::_Rb_tree_const_iterator StorageElement*> > > > >] > > > find(const AddrRange , std::function > 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 > > HasDst>::execAtomic(GPUDynInstPtr) [with MemDataType = > > > HsailISA::HsailDataType > > RegOrImmOperand >, long unsigned int, > > > (Enums::MemType)3u, (vgpr_type)1u, 1>; AddrOperandType = > > > RegAddrOperand; int NumSrcOperands = 1; bool HasDst = > true; > > > GPUDynInstPtr = std::shared_ptr]' > > > 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' > > > return new AtomicOpAnd(*reg0); > > > ^ > > > build/HSAIL_X86/gpu-compute/gpu_dyn_inst.hh:50:7: note: because the > > > following virtual functions are pure within 'AtomicOpAnd > > int>': > > > class AtomicOpAnd : public TypedAtomicOpFunctor > > > > > > > > > Any help or pointers is highly appreciated. > > > > > > > > > Thanks and Regards, > > > Sampad Mohapatra > > > ___ > > > gem5-dev mailing list > > > gem5-dev@gem5.org > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-devdata=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3Dreserved=0 > >
Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930
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 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 > wrote: > > > What is your compiler version? > > > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra > 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::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::const_iterator AddrRangeMap > > max_cache_size>::find(const AddrRange&, std::function) > > > const [with V = StorageElement*; int max_cache_size = 0; > AddrRangeMap > > max_cache_size>::const_iterator = > > > std::_Rb_tree_const_iterator StorageElement*> > > > >] > > > find(const AddrRange , std::function > 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 > > HasDst>::execAtomic(GPUDynInstPtr) [with MemDataType = > > > HsailISA::HsailDataType > > RegOrImmOperand >, long unsigned int, > > > (Enums::MemType)3u, (vgpr_type)1u, 1>; AddrOperandType = > > > RegAddrOperand; int NumSrcOperands = 1; bool HasDst = > true; > > > GPUDynInstPtr = std::shared_ptr]' > > > 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' > > > return new AtomicOpAnd(*reg0); > > > ^ > > > build/HSAIL_X86/gpu-compute/gpu_dyn_inst.hh:50:7: note: because the > > > following virtual functions are pure within 'AtomicOpAnd > > int>': > > > class AtomicOpAnd : public TypedAtomicOpFunctor > > > > > > > > > Any help or pointers is highly appreciated. > > > > > > > > > Thanks and Regards, > > > Sampad Mohapatra > > > ___ > > > gem5-dev mailing list > > > gem5-dev@gem5.org > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-devdata=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3Dreserved=0 > > ___ > > gem5-dev mailing list > > gem5-dev@gem5.org > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-devdata=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3Dreserved=0 > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930
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 wrote: > What is your compiler version? > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra 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::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::const_iterator AddrRangeMap > max_cache_size>::find(const AddrRange&, std::function) > > const [with V = StorageElement*; int max_cache_size = 0; AddrRangeMap > max_cache_size>::const_iterator = > > std::_Rb_tree_const_iterator > > >] > > find(const AddrRange , std::function 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 > HasDst>::execAtomic(GPUDynInstPtr) [with MemDataType = > > HsailISA::HsailDataType > RegOrImmOperand >, long unsigned int, > > (Enums::MemType)3u, (vgpr_type)1u, 1>; AddrOperandType = > > RegAddrOperand; int NumSrcOperands = 1; bool HasDst = true; > > GPUDynInstPtr = std::shared_ptr]' > > 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' > > return new AtomicOpAnd(*reg0); > > ^ > > build/HSAIL_X86/gpu-compute/gpu_dyn_inst.hh:50:7: note: because the > > following virtual functions are pure within 'AtomicOpAnd > int>': > > class AtomicOpAnd : public TypedAtomicOpFunctor > > > > > > Any help or pointers is highly appreciated. > > > > > > Thanks and Regards, > > Sampad Mohapatra > > ___ > > gem5-dev mailing list > > gem5-dev@gem5.org > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-devdata=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3Dreserved=0 > ___ > gem5-dev mailing list > gem5-dev@gem5.org > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm5sim.org%2Fmailman%2Flistinfo%2Fgem5-devdata=02%7C01%7Csum94%40psu.edu%7Ce8c4c86e86d04874552408d601cad230%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636698367962416116sdata=%2BMpSxLHBDda0f6iz2TBrGAmeaUwHLzAaMooGIB2kxMU%3Dreserved=0 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930
What is your compiler version? On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra 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::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::const_iterator AddrRangeMap max_cache_size>::find(const AddrRange&, std::function) > const [with V = StorageElement*; int max_cache_size = 0; AddrRangeMap max_cache_size>::const_iterator = > std::_Rb_tree_const_iterator > >] > find(const AddrRange , std::function 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 HasDst>::execAtomic(GPUDynInstPtr) [with MemDataType = > HsailISA::HsailDataType RegOrImmOperand >, long unsigned int, > (Enums::MemType)3u, (vgpr_type)1u, 1>; AddrOperandType = > RegAddrOperand; int NumSrcOperands = 1; bool HasDst = true; > GPUDynInstPtr = std::shared_ptr]' > 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' > return new AtomicOpAnd(*reg0); > ^ > build/HSAIL_X86/gpu-compute/gpu_dyn_inst.hh:50:7: note: because the > following virtual functions are pure within 'AtomicOpAnd int>': > class AtomicOpAnd : public TypedAtomicOpFunctor > > > Any help or pointers is highly appreciated. > > > Thanks and Regards, > Sampad Mohapatra > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930
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::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::const_iterator AddrRangeMap::find(const AddrRange&, std::function) const [with V = StorageElement*; int max_cache_size = 0; AddrRangeMap::const_iterator = std::_Rb_tree_const_iterator >] find(const AddrRange , std::function 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::execAtomic(GPUDynInstPtr) [with MemDataType = HsailISA::HsailDataType >, long unsigned int, (Enums::MemType)3u, (vgpr_type)1u, 1>; AddrOperandType = RegAddrOperand; int NumSrcOperands = 1; bool HasDst = true; GPUDynInstPtr = std::shared_ptr]' 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' return new AtomicOpAnd(*reg0); ^ build/HSAIL_X86/gpu-compute/gpu_dyn_inst.hh:50:7: note: because the following virtual functions are pure within 'AtomicOpAnd': class AtomicOpAnd : public TypedAtomicOpFunctor Any help or pointers is highly appreciated. Thanks and Regards, Sampad Mohapatra ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
