> On March 21, 2012, 10:30 p.m., Steve Reinhardt wrote:
> > I'm curious how this issue arises in practice... wouldn't the scope of the
> > templated range_map methods be disjoint from where this code would appear?
> > I guess if it's a real issue with g++ 4.6 we need to fix it, but I'd like
> > to understand better whether it's a true C++ error or just a g++
> > idiosyncrasy.
It turns out I should not have blamed gcc, and particularly not 4.6. Sorry gcc.
As clang rightfully points out, the power o3 CPU includes decoder.hh that
defines:
#define W bits(machInst, 16, 16)
The CPU also includes system.hh, which as part of the distributed memory patch
includes physical.hh, which includes range_map.hh.
In file included from build/POWER/mem/physical.hh:43:
build/POWER/base/range_map.hh:264:37: error: C++ requires a type specifier for
all declarations
insert(const Range<U> &r, const W d)
^
In file included from build/POWER/arch/power/o3_cpu_exec.cc:8:
build/POWER/arch/power/decoder.hh:78:16: note: instantiated from:
#define W bits(machInst, 16, 16)
^~~~~~~~
build/POWER/base/range_map.hh:264:37: error: declaration of 'machInst' shadows
template parameter
build/POWER/base/range_map.hh:262:29: note: template parameter is declared here
template <class U,class W>
^
- Andreas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1109/#review2358
-----------------------------------------------------------
On March 21, 2012, 4:40 p.m., Andreas Hansson wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1109/
> -----------------------------------------------------------
>
> (Updated March 21, 2012, 4:40 p.m.)
>
>
> Review request for Default.
>
>
> Description
> -------
>
> Power: Change bitfield name to avoid conflicts with range_map
>
> This patch changes the name of a bitfield from W to W_FIELD to avoid
> clashes with W being used as a class (typename) in the templatized
> range_map. The problem only manifested itself with gcc 4.6 after
> seemingly unrelated changes, but is likely to cause similar issues in
> the future and thus worth fixing. The relevant parts of the decoder
> are updated.
>
>
> Diffs
> -----
>
> src/arch/power/isa/bitfields.isa 4da2ea94319f
> src/arch/power/isa/decoder.isa 4da2ea94319f
>
> Diff: http://reviews.gem5.org/r/1109/diff/
>
>
> Testing
> -------
>
> util/regress all passing (disregarding t1000 and eio)
>
>
> Thanks,
>
> Andreas Hansson
>
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev