> On April 12, 2016, 11:15 a.m., Andreas Hansson wrote: > > Thanks!
There were a few more issues when I tried to run on zizzer, which has clang 3.6. These fixes allow the regressions to pass, disregarding the skipped eio tests. - Tony ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3446/#review8191 ----------------------------------------------------------- On April 13, 2016, 7:58 a.m., Tony Gutierrez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3446/ > ----------------------------------------------------------- > > (Updated April 13, 2016, 7:58 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11443:c90af82c70e4 > --------------------------- > hsail,gpu-compute: fixes to appease clang++ > > fixes to appease clang++. tested on: > > Ubuntu clang version 3.5.0-4ubuntu2~trusty2 > (tags/RELEASE_350/final) (based on LLVM 3.5.0) > > Ubuntu clang version 3.6.0-2ubuntu1~trusty1 > (tags/RELEASE_360/final) (based on LLVM 3.6.0) > > the fixes address the following two issues: > > 1) the exec continuations in gpu_static_inst.hh were marked > as protected when they should be public. here we mark > them as public > > 2) the Abs instruction uses std::abs() in its execute method. > because Abs is templated, it can also operate on U32 and U64, > types, which cause Abs::execute() to pass uint32_t and uint64_t > types to std::abs() respectively. this triggers a warning > because std::abs() has no effect in this case. to rememdy this > we add template specialization for the execute() method of Abs > when its template paramter is U32 or U64. > > 3) Some potocols that utilize the code in cprintf.hh were missing > includes to BoolVec.hh, which defines operator<< for the BoolVec > type. This would cause issues when the generated code would try > to pass a BoolVec type to a method in cprintf.hh that used > operator<< on an instance of a BoolVec. > > 4) Surprise, clang doesn't like it when you clobber all the bits > in a newly allocated object. I.e., this code: > > tlb = new GpuTlbEntry[size]; > std::memset(tlb, 0, sizeof(GpuTlbEntry) * size); > > Let's use std::vector to track the TLB entries in the GpuTlb now... > > 5) There were a few variables used only in DPRINTFs, so we mark them > with M5_VAR_USED. > > > Diffs > ----- > > src/arch/hsail/gen.py b31738224fb0eb259efc25f6d6efab5a962f29d0 > src/arch/x86/process.cc b31738224fb0eb259efc25f6d6efab5a962f29d0 > src/gpu-compute/gpu_static_inst.hh b31738224fb0eb259efc25f6d6efab5a962f29d0 > src/gpu-compute/gpu_tlb.hh b31738224fb0eb259efc25f6d6efab5a962f29d0 > src/gpu-compute/gpu_tlb.cc b31738224fb0eb259efc25f6d6efab5a962f29d0 > src/gpu-compute/hsail_code.hh b31738224fb0eb259efc25f6d6efab5a962f29d0 > src/mem/slicc/symbols/StateMachine.py > b31738224fb0eb259efc25f6d6efab5a962f29d0 > > Diff: http://reviews.gem5.org/r/3446/diff/ > > > Testing > ------- > > > Thanks, > > Tony Gutierrez > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev