> On April 6, 2012, 12:33 p.m., Gabe Black wrote:
> > src/base/hashmap.hh, line 63
> > <http://reviews.gem5.org/r/1119/diff/2/?file=25609#file25609line63>
> >
> >     #defines are bad. They change the code behind the programmers back and 
> > can accidentally apply places they didn't intend. Can you use typedefs with 
> > templates? Or create new templates which wrap the old ones.
> 
> Andreas Hansson wrote:
>     I'll give it a bash. I merely tried to keep it as similar as possible to 
> what was already there, but your proposal makes sense...and defines are 
> definitely not my favourites either.

I don't think there is a good non-invasive solution here that does not require 
a lot of code changes (besides the existing defines). With gcc 4.7, there will 
be support for template aliases and then we could do something like:

template<class Key, class T, class Hash = hash<Key> >
using hash_map = std::unordered_map<Key, T, Hash>

For now, I'd suggest we stick with the defines. Acceptable?


- Andreas


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


On April 6, 2012, 9:01 a.m., Andreas Hansson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1119/
> -----------------------------------------------------------
> 
> (Updated April 6, 2012, 9:01 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Description
> -------
> 
> clang/gcc: Fix compilation issues with clang 3.0 and gcc 4.6
> 
> This patch addresses a number of minor issues that cause problems when
> compiling with clang >= 3.0 and gcc >= 4.6. Most importantly, it
> avoids using the deprecated ext/hash_map and instead uses
> unordered_map (and similarly so for the hash_set). To make use of the
> new STL containers, g++ and clang has to be invoked with "-std=c++0x",
> and this is now added for all gcc versions >= 4.6, and always for
> clang since even 2.9 supports this. The addition of c++0x in turn
> causes a few problems, as the compiler is more stringent and adds a
> number of new warnings. Below, the most important issues are
> enumerated:
> 
> 1) the use of namespaces is more strict, e.g. for isnan, and all
>    headers opening the entire namespace std are now fixed.
> 
> 2) another other issue caused by the more stringent compiler is the
>    narrowing of the embedded python, which used to be a char array,
>    and is now unsigned char since there were values larger than 128.
> 
> 3) a particularly odd issue that arose with the new c++0x behaviour is
>    found in range.hh, where the operator< causes gcc to complain about
>    the template type parsing (the "<" is interpreted as the beginning
>    of a template argument), and the problem seems to be related to the
>    begin/end members introduced for the range-type iteration, which is
>    a new feature in c++11.
> 
> As a minor update, this patch also fixes the build flags for the clang
> debug target that used to be shared with gcc and incorrectly use
> "-ggdb".
> 
> 
> Diffs
> -----
> 
>   SConstruct f51b4b4f0d5e 
>   ext/libelf/SConscript f51b4b4f0d5e 
>   src/SConscript f51b4b4f0d5e 
>   src/arch/alpha/mt.hh f51b4b4f0d5e 
>   src/arch/arm/isa/includes.isa f51b4b4f0d5e 
>   src/arch/power/isa/includes.isa f51b4b4f0d5e 
>   src/arch/sparc/isa/decoder.isa f51b4b4f0d5e 
>   src/arch/sparc/mt.hh f51b4b4f0d5e 
>   src/arch/sparc/tlb_map.hh f51b4b4f0d5e 
>   src/arch/x86/isa/microops/fpop.isa f51b4b4f0d5e 
>   src/arch/x86/isa/microops/mediaop.isa f51b4b4f0d5e 
>   src/base/hashmap.hh f51b4b4f0d5e 
>   src/base/inifile.cc f51b4b4f0d5e 
>   src/base/range.hh f51b4b4f0d5e 
>   src/base/stats/text.cc f51b4b4f0d5e 
>   src/mem/ruby/common/Address.hh f51b4b4f0d5e 
>   src/mem/ruby/network/fault_model/FaultModel.hh f51b4b4f0d5e 
>   src/mem/ruby/network/fault_model/FaultModel.cc f51b4b4f0d5e 
>   src/mem/ruby/network/garnet/BaseGarnetNetwork.cc f51b4b4f0d5e 
>   src/mem/ruby/network/orion/OrionConfig.hh f51b4b4f0d5e 
>   src/mem/ruby/network/orion/OrionRouter.cc f51b4b4f0d5e 
>   src/mem/ruby/network/orion/TechParameter.hh f51b4b4f0d5e 
>   src/sim/init.hh f51b4b4f0d5e 
>   src/sim/init.cc f51b4b4f0d5e 
> 
> Diff: http://reviews.gem5.org/r/1119/diff/
> 
> 
> Testing
> -------
> 
> util/regress all passing (disregarding t1000 and eio) with gcc 4.6.2, 
> and compiling with clang 2.9 and 3.0 on Ubuntu 12.04 and MacOSX 10.7.3
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to