Version of Clang used for compiling gem5 about ramulator

[wky]

Hi, thanks for your question. I used Clang 3.4, and another author used G++
on his system.
I believe the "template specialization" error with Ramulator is due to
C++11 implementation differences between g++ and Clang (or different
versions). Could you specify which lines triggered the error, best with
original compiler output? Also, since we used many C++11 features, the
standard library matters too. Which one are you using? (libc++ by LLVM or
libstdc++ by GNU)

I've also encountered several compilation errors with gem5 (without our
patch). You might need to modify the offending lines.

2015-05-14 6:51 GMT+08:00 dhiraj113 [email protected]:

I have tried to compile gem5 with ramulator patched in. I am encountering
compilation error while using both g++ and clang compilers.

While using g++, the ramulator code gives a compile time error saying :
template specialization not allowed in a different namespace.

While using clang, the gem5 part of the code fails with several several
compilation errors. I tried using clang version 3.3, 3.4 and 3.5. Each
fails with a different kind of compilation error.

I am curious to know what version of clang you used to compile gem5.

—
Reply to this email directly or view it on GitHub
#1.

[henryzh]

Hi all, I also happened to compilation errors when trying to compile the code with gcc 4.8.3. I prefer to use gcc, since I'd like to incorporate the code with other simulators later. Here I post the error information as follows, and hope it would be the hint to address these issues. Thank you!

gcc -O3 -std=c++11 -g -Wall -c -o src/Controller.o src/Controller.cpp
In file included from src/Controller.h:13:0,
from src/Controller.cpp:1:
src/Refresh.h:134:42: error: specialization of ‘template void ramulator::Refresh::tick_ref()’ in different namespace [-fpermissive]
template<> void Refresh::tick_ref();
^
src/Refresh.h:71:8: error: from definition of ‘template void ramulator::Refresh::tick_ref()’ [-fpermissive]
void tick_ref() {
^
src/Controller.cpp:27:90: error: specialization of ‘template std::vector ramulator::Controller::get_addr_vec(typename T::Command, std::listramulator::Request::iterator)’ in different namespace [-fpermissive]
vector Controller::get_addr_vec(SALP::Command cmd, list::iterator req){
^
In file included from src/Controller.cpp:1:0:
src/Controller.h:221:17: error: from definition of ‘template std::vector ramulator::Controller::get_addr_vec(typename T::Command, std::listramulator::Request::iterator)’ [-fpermissive]
vector get_addr_vec(typename T::Command cmd, list::iterator req){
^
src/Controller.cpp:36:60: error: specialization of ‘template bool ramulator::Controller::is_ready(std::listramulator::Request::iterator)’ in different namespace [-fpermissive]
bool Controller::is_ready(list::iterator req){
^
In file included from src/Controller.cpp:1:0:
src/Controller.h:172:10: error: from definition of ‘template bool ramulator::Controller::is_ready(std::listramulator::Request::iterator)’ [-fpermissive]
bool is_ready(list::iterator req)
^
src/Controller.cpp:47:70: error: specialization of ‘template void ramulator::Controller::update_temp(ramulator::ALDRAM::Temp)’ in different namespace [-fpermissive]
void Controller::update_temp(ALDRAM::Temp current_temperature){
^
In file included from src/Controller.cpp:1:0:
src/Controller.h:183:10: error: from definition of ‘template void ramulator::Controller::update_temp(ramulator::ALDRAM::Temp)’ [-fpermissive]
void update_temp(ALDRAM::Temp current_temperature)
^
src/Controller.cpp:53:31: error: specialization of ‘template void ramulator::Controller::tick()’ in different namespace [-fpermissive]
void Controller::tick(){
^
In file included from src/Controller.cpp:1:0:
src/Controller.h:110:10: error: from definition of ‘template void ramulator::Controller::tick()’ [-fpermissive]
void tick()

[akgun1]

Hello,

I am getting the same error that henryzh mentioned above when I try to compile gem5 after applying the Ramulator patch. I tried compiling gem5 using scons as suggested by this website: http://www.m5sim.org/Introduction

Below you can find the tool versions that I am using:
SCons: v2.3.0, gcc: 4.8.2, clang: 3.7.0

Any help is appreciated.

Thanks,
Itir

[xhongyi]

Dear users,

We have seen this bug before and we believe this is a bug in gcc 4.8.
Currently there is known no work around of this issue with gcc. The best
suggestion would be using clang (this means giving up 3rd party libraries
like boost).

Alternatively, you can try to hack the code and avoid using template
specialization.

Unfortunately, we do not provide support of fixing gcc bugs. You might want
to submit a ticket to the gcc community.

Best regard,
Hongyi
On May 28, 2015 9:36 PM, "akgun1" [email protected] wrote:

Hello,

I am getting the same error that henryzh mentioned above when I try to
compile gem5 after applying the Ramulator patch. I tried compiling gem5
using scons as suggested by this website:
http://www.m5sim.org/Introduction

Below you can find the tool versions that I am using:
SCons: v2.3.0, gcc: 4.8.2, clang: 3.7.0

Any help is appreciated.

Thanks,
Itir

—
Reply to this email directly or view it on GitHub
#1 (comment).

[henryzh]

Dear Hongyi,

Thanks a lot for your response. As one of your suggestion, I have hacked the source code to disable the errors I mentioned, by moving partial template specialization into ramulator namespace. The good news is that these errors are eliminated, while the bad news is that it raised another internal compiler error. It seems there indeed exist bugs of gcc 4.8.

In file included from src/Controller.h:15:0,
from src/Memory.h:6,
from src/MemoryFactory.h:8,
from src/Gem5Wrapper.cpp:6:
src/Scheduler.h: In instantiation of ‘struct ramulator::Schedulerramulator::DDR3::__lambda0’:
src/Scheduler.h:32:47: required from ‘ramulator::Scheduler::Scheduler(ramulator::Controller) [with T = ramulator::DDR3]’
src/Controller.h:62:37: required from ‘ramulator::Controller::Controller(ramulator::DRAM) [with T = ramulator::DDR3]’
src/MemoryFactory.h:43:13: required from ‘static ramulator::Memory* ramulator::MemoryFactory::populate_memory(T_, int, int) [with T = ramulator::DDR3]’
src/MemoryFactory.h:66:67: required from ‘static ramulator::MemoryBase_ ramulator::MemoryFactory::create(std::mapstd::basic_string<char, std::basic_string >&, int) [with T = ramulator::DDR3]’
src/Gem5Wrapper.cpp:21:36: required from here
src/Scheduler.h:50:10: internal compiler error: in tsubst_copy, at cp/pt.c:12136
[this](ReqIter req1, ReqIter req2) {
^
Please submit a full bug report,

[xhongyi]

Is it a lamda function issue?

I think it's best to stick with clang at the moment.
On May 30, 2015 2:06 PM, "henryzh" [email protected] wrote:

Dear Hongyi,

Thanks a lot for your response. As one of your suggestion, I have hacked
the source code to disable the errors I mentioned, by moving partial
template specialization into ramulator namespace. The good news is that
these errors are eliminated, while the bad news is that it raised another
internal compiler error. It seems there indeed exist bugs of gcc 4.8.

In file included from src/Controller.h:15:0,
from src/Memory.h:6,
from src/MemoryFactory.h:8,
from src/Gem5Wrapper.cpp:6:
src/Scheduler.h: In instantiation of ‘struct
ramulator::Schedulerramulator::DDR3::__lambda0’:
src/Scheduler.h:32:47: required from
‘ramulator::Scheduler::Scheduler(ramulator::Controller
) [with T = ramulator::DDR3]’ src/Controller.h:62:37: required from
‘ramulator::Controller::Controller(ramulator::DRAM) [with T =
ramulator::DDR3]’
src/MemoryFactory.h:43:13: required from ‘static ramulator::Memory*
ramulator::MemoryFactory::populate_memory(T
, int, int) [with T = ramulator::DDR3]’ src/MemoryFactory.h:66:67:
required from ‘static ramulator::MemoryBase
ramulator::MemoryFactory::create(std::mapstd::basic_string<char,
std::basic_string >&, int) [with T = ramulator::DDR3]’
src/Gem5Wrapper.cpp:21:36: required from here
src/Scheduler.h:50:10: internal compiler error: in tsubst_copy, at
cp/pt.c:12136
this http://ReqIter%20req1,%20ReqIter%20req2 {
^
Please submit a full bug report,

—
Reply to this email directly or view it on GitHub
#1 (comment).

[yarcod]

I am also having the same issue with ramulator. This problem occurs no matter if I compile it as cpu-trace, dram-trace driven or through gem5. All three ways give errors, mostly regarding specialization and namespace (like OP). I should mention that I do not get exactly the same errors compiling for gem5.

I have tried different versions of Clang and tried both libc++ and libstdc++. Libc++ gives loads of errors, while libstdc++ gives 1 error and a few warnings.

How can I solve this?

[henryzh]

Hi all,
I also tried to compile ramulator along gem5 using clang 3.7.0, however I encountered some errors regarding to the gem5 code. It seems some code of gem5 (rev: 10231 as suggested by ramulator) is not compatible with clang. Need I hack the gem5 code to cope with it? I assume there would be much code needs to be processed after fixing them. I was wondering the how developers address this issue. Thanks.

For instance, the error appears like this,
build/X86/base/inet.hh:327:35: error: use of undeclared identifier 'opt_type'
uint8_t type() const { return opt_type; }
^
build/X86/base/inet.hh:328:55: error: use of undeclared identifier 'opt_type'
uint8_t typeNumber() const { return IP_OPT_NUMBER(opt_type); }

[SaugataGhose]

I am working on updating the gem5 patch to solve these issues (which includes a few changes to the gem5 code itself). I will upload a modified version of this patch shortly. After these changes, I have been able to compile gem5 with Ramulator successfully using the following configuration:

• Ubuntu 14.04 LTS
• clang 3.4.1
• libstdc++ 3.4.19 (somewhat older versions should be fine...)
• SCons 2.3.0
• SWIG 2.0.12 (_newer_ than the most recent package in Ubuntu 14.04)
• Google Performance Tools 2.1 (libgoogle-perftools-dev package in Ubuntu)

Unfortunately, as @xhongyi mentioned, I have not had any luck compiling the source code with gcc due to the template specialization bug.

[henryzh]

Thanks for answering. I'm looking forward to that fixed patch.

However, to make this simulator more popular in the community, I don't think sticking to clang complier and modifying gem5 code to adapt are a good choice. This makes ramulator enjoy the features of new version gem5 hard, since developers have to keep maintaining such patch according to different versions of gem5. On the contrary, changing ramulator to adapt for GNU gcc might be a better solution. From my experience, fixing these template specialization for gcc is not hard. The internal compiler error can also be fixed if gcc 5.1.0 is used. Currently, gcc 5.1.0 can compile the source code well after fixing these template specialization issue. The only problem for using gcc 5.1.0 is I happened to some assertion failure and segment fault. I'll continue working on that.

[i7mist]

Hi, I made a patch based on the latest gem5-stable version, which has better support for clang.(https://github.com/i7mist/ramulator/blob/root/gem5-2adc17b55ed4-ramulator.patch) Maybe you can try it.
Here is my configuration
Ubuntu 14.04 LTS
clang version 3.3
libc++ (linux-libc-dev version 3.13.0-46.77)
SCons 2.3.4
SWIG 3.0.5

(clang 3.7 might be a version too high for gem5)

[i7mist]

For the assertion failure, I have also met with some. If the error log is something like "gem5.opt: build/X86/mem/xbar.cc:290: void BaseXBar::Layer<SlavePort, MasterPort>::recvRetry() [SrcType = SlavePort, DstType = MasterPort]: Assertion `waitingForPeer != __null' failed.
", then I think it is caused by calling Ramulator::tick() at the first time without initialize the class member of Ramulator: req_stall and resp_stall as false. So there isn't really a packet waiting to be retried to receive when port.sendRetry() is called.

[SaugataGhose]

Just a quick update for everyone. My apologies for not addressing this issue sooner - I was on travel all of last week.

In the next day or so, I will provide an update of the gem5 patch that fixes the compilation issues for clang, as well as the assertion failures that @i7mist encountered. The patch is working on my system, but I want to test a few remaining things before I release it to you guys.

@henryzh - Can you please provide examples of the assertion failures and seg faults you encountered? Hopefully they stem from the same issues that we'll be patching. I agree that gcc compatibility will greatly help adoption. Would you be willing to post the modifications you made to get Ramulator to compile under GCC 5.1? I'd like to incorporate these into the code (you, of course, would receive credit for these changes).

[SaugataGhose]

I just pushed the fixes for the gem5 patch to a new branch (bugfix). Could all of you please check out this branch and see if it solves the compilation issues for clang? Any feedback would be appreciated before we merge this fix into the master branch.

We will roll in the changes that @henryzh made to support GCC 5.1 sometime early next week.

Thanks, and sorry for the wait!

[i7mist]

I applied the patch to gem5 and build the ALPHA version under the configuration stated before and experience the following compile error.

In file included from build/ALPHA/mem/dram_ctrl.cc:50:
build/ALPHA/mem/dram_ctrl.hh:471:16: error: private field 'tCK' is not used [-Werror,-Wunused-private-field]

[SaugataGhose]

This latest patch (721df87) should address all of the issues that people were experiencing with gem5 compilation. This also includes changes that enable compilation on GCC 5 (see #3, and thanks to @henryzh for his help with that). We have successfully compiled with clang 3.5/3.6, using both libstdc++ and libc++, as well as with GCC 5.1 with libstdc++.

Before you start compilation, you must make sure that you have SWIG 2.0.12+ installed, as well as the gperftools library (this was optional for gem5, but is required for gem5+Ramulator).

Note that GCC 4.x support will not be implemented in the near future, as there are known, unpatched bugs in the way that it handles lambda functions. The use of clang 3.4 with libstdc++ is unsupported, because of an issue it has with properly processing the latest libstdc++ libraries. (While it should work with libc++, we are currently not supporting it at this time.)