[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression --scratch all

2017-02-26 Thread Cron Daemon 
* 
build/SPARC/tests/opt/long/fs/80.solaris-boot/sparc/solaris/t1000-simple-atomic:
 FAILED!
* build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-o3-dual: 
CHANGED!
* build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO: 
CHANGED!
scons: *** [build/ALPHA/encumbered/eio/eio.do] Error 1
scons: *** [build/ALPHA/encumbered/eio/eio.fo] Error 1
scons: *** [build/ALPHA/encumbered/eio/eio.o] Error 1
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic: passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: 
passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem: passed.
* build/NULL/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby: passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter: passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest: passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl: passed.
* build/NULL/tests/opt/quick/se/51.memcheck/null/none/memcheck: passed.
* 
build/NULL_MOESI_hammer/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_hammer:
 passed.
* 
build/NULL_MESI_Two_Level/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MESI_Two_Level:
 passed.
* 
build/NULL_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory:
 passed.
* 
build/NULL_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_token:
 passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby: 
passed.
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-two-level:
 passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic: passed.
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple:
 passed.
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: passed.
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-atomic: 
passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-timing-mp:
 passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp:
 passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp:
 passed.
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing: 
passed.
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-atomic: 
passed.
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/10.mcf/sparc/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-timing: 
passed.
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-timing: passed.
* build/SPARC/tests/opt/long/se/10.mcf/sparc/linux/simple-timing: passed.
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-simple:
 passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing: passed.
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-atomic: passed.
* build/X86/tests/opt/quick/se/10.mcf/x86/linux/simple-atomic: passed.
* build/X86/tests/opt/long/se/10.mcf/x86/linux/simple-timing: passed.
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-timing: passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing: passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic: passed.
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-two-level:
 passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby: 
passed.
* build/X86/tests/opt/long/se/20.parser/x86/linux/simple-atomic: passed.
* build/X86/tests/opt/long/se/10.mcf/x86/linux/o3-timing: passed.
* build/X86/tests/opt/long/se/20.parser/x86/linux/simple-timing: passed.
* build/X86/tests/opt/long/se/70.twolf/x86/linux/o3-timing: passed.
* 
build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing-dual:
 passed.
* build/ARM/tests/opt/long/se/50.vortex/arm/linux/minor-timing: passed.
* build/X86/tests/opt/long/se/60.bzip2/x86/linux/simple-atomic: passed.
* 
build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-switcheroo-o3: 
passed.
*

Re: [gem5-dev] Review Request 3812: ext: Include SystemC 2.3.1 into gem5

2017-02-26 Thread Andreas Hansson 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3812/#review9485
---


I think this is a good step in the right direction, and it has the potential of 
greatly enhancing the support for gem5 in SystemC environments. The only 
question is have is with respect to our current build process for gem5-SystemC, 
and how it interacts with the with/without Python build.

Could we eventually have one executable that can do both SC and non-SC, and 
then only leave the with/without Python as an option? What combinations 
actually make sense, and what is the overhead if we were to always include SC?

I think having "one executable to rule them all" would also help tremendously 
with testing, but perhaps there are other ways of keeping this working.

On a separate note, I think it would be really interesting if someone skilled 
in the arts could take a stab at moving gem5 to use the SystemC event kernel. 
This would enable a more elaborate set of tools and modelling paradirms, 
including SC_THREAD/SC_CTHREAD style concepts that work very well for state 
machines. Clearly this is off topic for the patch, but I am keen to know if 
anyone has already progress this train of thought, or would be keen to discuss 
the options.

- Andreas Hansson


On Feb. 14, 2017, 8:33 p.m., Matthias Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3812/
> ---
> 
> (Updated Feb. 14, 2017, 8:33 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11837:f68a638dd4c7
> ---
> ext: Include SystemC 2.3.1 into gem5
> 
> In the past it happened several times that some changes in gem5 broke the
> SystemC coupling. Recently Accelera has changed the licence for SystemC from
> their own licence to Apache2.0, which is compatible with gem5. However, 
> SystemC
> usually relies on the Boost library, but I was able to exchange the boost 
> calls
> by c++11 alternatives. The recent SystemC version is placed into /ext and is
> integrated into gem5's build system. The goal is to integrate some SystemC
> tests for the CI in some following patches.
> 
> 
> Diffs
> -
> 
>   ext/systemc/src/sysc/utils/sc_pq.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_pvector.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_report.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_report.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_report_handler.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_report_handler.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_stop_here.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_stop_here.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_string.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_string.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_temporary.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_utils_ids.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_utils_ids.cpp PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_vector.h PRE-CREATION 
>   ext/systemc/src/sysc/utils/sc_vector.cpp PRE-CREATION 
>   ext/systemc/src/systemc PRE-CREATION 
>   ext/systemc/src/systemc.h PRE-CREATION 
>   ext/systemc/src/tlm PRE-CREATION 
>   ext/systemc/src/tlm.h PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm.pc.in PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/README.txt PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_analysis.h PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_analysis_fifo.h 
> PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_analysis_if.h PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_analysis_port.h 
> PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_analysis_triple.h 
> PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_analysis/tlm_write_if.h PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_core_ifs.h 
> PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_fifo_ifs.h 
> PRE-CREATION 
>   
> ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_master_slave_ifs.h
>  PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_tag.h 
> PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_adapters/tlm_adapters.h 
> PRE-CREATION 
>   
> ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/circular_buffer.h
>  PRE-CREATION 
>   ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/tlm_fifo.h 
> PRE-CREATION 
>   
> ext/systemc/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/tlm_fifo_peek.h
>  PRE-CREATION 
>   
>

Re: [gem5-dev] Review Request 3827: python: Use PyBind11 instead of SWIG for Python wrappers

2017-02-26 Thread Andreas Hansson 


> On Feb. 23, 2017, 9:37 p.m., Tony Gutierrez wrote:
> > This seems like a welcome change. A question: are there any requirements 
> > for using PyBind besides Python 2.7 or 3.x and the std clibs? I see that 
> > the PyBind GitHub only mentions these dependencies, and I wanted to get 
> > confirmation based on your experiences using it.
> 
> Andreas Sandberg wrote:
> There shouldn't be any external dependencies other than Python 2.7/3.x 
> and C++11. I have tested it with gcc 4.8 our CI system (RHEL 6.6), gcc 6.2, 
> and clang 3.8. I haven't seen any issues other than a weird clang error 
> (possibly a clang bug) related to the PyEventDeleter class. I have updated 
> the patch to work around that issue.

Great stuff!

Could we get some coverage from devs to make sure this works across the board:

1) BSD, Bjoern et al?
2) macOS (OSX works on my machine, so likely not a problem)
3) anyone else that has a less-well-tested build environment?


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3827/#review9469
---


On Feb. 24, 2017, 10:20 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3827/
> ---
> 
> (Updated Feb. 24, 2017, 10:20 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11884:e0f1c63a8440
> ---
> python: Use PyBind11 instead of SWIG for Python wrappers
> 
> Use the PyBind11 wrapping infrastructure instead of SWIG to generate
> wrappers for functionality that needs to be exported to Python. This
> has several benefits:
> 
>   * PyBind11 can be redistributed with gem5, which means that we have
> full control of the version used. This avoid a large number of
> hard-to-debug SWIG issues we have seen in the past.
> 
>   * PyBind11 doesn't rely on a custom C++ parser, instead it relies on
> wrappers being explicitly declared in C++. The leads to slightly
> more boiler-plate code in manually created wrappers, but doesn't
> doesn't increase the overall code size. A big benefit is that this
> avoids strange compilation errors when SWIG doesn't understand
> modern language features.
> 
>   * Unlike SWIG, there is no risk that the wrapper code incorporates
> incorrect type casts (this has happened on numerous occasions in
> the past) since these will result in compile-time errors.
> 
> As a part of this change, the mechanism to define exported methods has
> been redesigned slightly. New methods can be exported either by
> declaring them in the SimObject declaration and decorating them with
> the cxxMethod decorator or by adding an instance of
> PyBindMethod/PyBindProperty to the cxx_exports class variable. The
> decorator has the added benefit of making it possible to add a
> docstring and naming the method's parameters.
> 
> The new wrappers has the following known issues:
> 
>   * Global events can't be memory managed correctly. This was the
> case in SWIG as well.
> 
> Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Andreas Hansson 
> Reviewed-by: Andrew Bardsley 
> 
> 
> Diffs
> -
> 
>   src/cpu/BaseCPU.py ba90ffa751b6 
>   src/arch/arm/ArmPMU.py ba90ffa751b6 
>   src/SConscript ba90ffa751b6 
>   src/python/pybind11/stats.cc PRE-CREATION 
>   src/python/swig/core.i ba90ffa751b6 
>   src/python/swig/debug.i ba90ffa751b6 
>   src/python/swig/drain.i ba90ffa751b6 
>   src/python/swig/event.i ba90ffa751b6 
>   src/python/swig/inet.i ba90ffa751b6 
>   src/python/swig/pyevent.hh ba90ffa751b6 
>   src/python/swig/pyevent.cc ba90ffa751b6 
>   src/python/swig/pyobject.hh ba90ffa751b6 
>   src/python/swig/pyobject.cc ba90ffa751b6 
>   src/python/swig/pyobject.i ba90ffa751b6 
>   src/python/swig/range.i ba90ffa751b6 
>   src/python/swig/serialize.i ba90ffa751b6 
>   src/python/swig/stats.i ba90ffa751b6 
>   src/python/swig/time.i ba90ffa751b6 
>   src/python/swig/trace.i ba90ffa751b6 
>   src/sim/Process.py ba90ffa751b6 
>   src/sim/System.py ba90ffa751b6 
>   src/sim/init.hh ba90ffa751b6 
>   src/sim/init.cc ba90ffa751b6 
>   src/sim/power/PowerModel.py ba90ffa751b6 
>   src/sim/power/PowerModelState.py ba90ffa751b6 
>   src/sim/power/ThermalDomain.py ba90ffa751b6 
>   src/sim/power/ThermalModel.py ba90ffa751b6 
>   src/unittest/SConscript ba90ffa751b6 
>   src/unittest/stattest.cc ba90ffa751b6 
>   src/unittest/stattest.i ba90ffa751b6 
>   tests/configs/switcheroo.py ba90ffa751b6 
>   src/cpu/kvm/BaseKvmCPU.py ba90ffa751b6 
>   src/cpu/kvm/X86KvmCPU.py ba90ffa751b6 
>   src/python/SConscript

Re: [gem5-dev] Review Request 3838: ext: Update DRAMPower

2017-02-26 Thread Andreas Hansson 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3838/#review9483
---

Ship it!


Great. Thanks Matthias!

How can we best make sure the functionality is matched by the DRAMCtrl? Is 
there anyone that already played around with bank-wise refresh?

- Andreas Hansson


On Feb. 24, 2017, 9:56 p.m., Matthias Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3838/
> ---
> 
> (Updated Feb. 24, 2017, 9:56 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11881:910b9376009a
> ---
> ext: Update DRAMPower
> 
> This patch syncs the DRAMPower library of gem5 to the external
> one on github (https://github.com/ravenrd/DRAMPower) of which
> I am one of the maintainers.
> 
> The version used is the commit:
> 90d6290f802c29b3de9e10233ceee22290907ce6
> from 30. Oct. 2016.
> 
> The new version features a bank-wise power estimation.
> Furthermore, PASR and Per-Bank Refresh is supported.
> 
> More Informtation can be found in the following papers:
> 
> A Bank-Wise DRAM Power Model for System Simulations
> Deepak M. Mathew, Eder F. Zulian, Subash. Kannoth, Matthias Jung, Christian 
> Weis, Norbert Wehn.
> International Conference on High-Performance and Embedded Architectures and 
> Compilers 2016 (HiPEAC), Workshop on: Rapid Simulation and Performance 
> Evaluation: Methods and Tools (RAPIDO), Stockholm, 2017.
> 
> A New Bank Sensitive DRAMPower Model for Efficient Design Space Exploration
> Matthias Jung, Deepak M. Mathew, Eder F. Zulian, Christian Weis, Norbert Wehn.
> International Workshop on Power And Timing Modeling, Optimization and 
> Simulation (PATMOS 2016), September, 2016, Bremen, Germany
> 
> 
> Diffs
> -
> 
>   ext/drampower/README.md 5ea85692a53e 
>   ext/drampower/SConscript 5ea85692a53e 
>   ext/drampower/src/CAHelpers.cc PRE-CREATION 
>   ext/drampower/src/CmdHandlers.cc PRE-CREATION 
>   ext/drampower/src/CommandAnalysis.h 5ea85692a53e 
>   ext/drampower/src/CommandAnalysis.cc 5ea85692a53e 
>   ext/drampower/src/MemBankWiseParams.h PRE-CREATION 
>   ext/drampower/src/MemBankWiseParams.cc PRE-CREATION 
>   ext/drampower/src/MemCommand.h 5ea85692a53e 
>   ext/drampower/src/MemPowerSpec.h 5ea85692a53e 
>   ext/drampower/src/MemPowerSpec.cc 5ea85692a53e 
>   ext/drampower/src/MemTimingSpec.h 5ea85692a53e 
>   ext/drampower/src/MemTimingSpec.cc 5ea85692a53e 
>   ext/drampower/src/MemoryPowerModel.h 5ea85692a53e 
>   ext/drampower/src/MemoryPowerModel.cc 5ea85692a53e 
>   ext/drampower/src/TraceParser.h 5ea85692a53e 
>   ext/drampower/src/TraceParser.cc 5ea85692a53e 
>   ext/drampower/src/libdrampower/LibDRAMPower.h 5ea85692a53e 
>   ext/drampower/src/libdrampower/LibDRAMPower.cc 5ea85692a53e 
>   ext/drampower/test/libdrampowertest/Makefile 5ea85692a53e 
>   ext/drampower/test/libdrampowertest/commands.trace 5ea85692a53e 
>   ext/drampower/test/libdrampowertest/lib_test.cc 5ea85692a53e 
> 
> Diff: http://reviews.gem5.org/r/3838/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthias Jung
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3841: gpu-compute: mark functions with override if replacing virtual

2017-02-26 Thread Andreas Hansson 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3841/#review9482
---

Ship it!


Ship It!

- Andreas Hansson


On Feb. 25, 2017, 7:33 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3841/
> ---
> 
> (Updated Feb. 25, 2017, 7:33 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11880:7ad57dc06157
> ---
> gpu-compute: mark functions with override if replacing virtual
> 
> The clang compiler is more stringent than the recent versions of
> GCC when dealing with overrides. This changeset adds the specifier
> to the methods which need it to silence the compiler.
> 
> 
> Diffs
> -
> 
>   src/arch/hsail/insts/gpu_static_inst.hh 
> 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/gpu-compute/gpu_static_inst.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
> 
> Diff: http://reviews.gem5.org/r/3841/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3840: gpu-compute: remove unnecessary member from class

2017-02-26 Thread Andreas Hansson 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3840/#review9481
---

Ship it!


Ship It!

- Andreas Hansson


On Feb. 25, 2017, 7:31 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3840/
> ---
> 
> (Updated Feb. 25, 2017, 7:31 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11879:12817f27b991
> ---
> gpu-compute: remove unnecessary member from class
> 
> The clang compiler complains that the wavefront member in
> the GpuISA class is unused. This changeset removes the member,
> because it does not appear serve a purpose.
> 
> 
> Diffs
> -
> 
>   src/arch/hsail/gpu_isa.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/gpu-compute/wavefront.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
> 
> Diff: http://reviews.gem5.org/r/3840/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev