On Sep 8, 2008, at 8:19 PM, nathan binkert wrote:

> As usual the gnu guys are out to make our life easier.  I've more or
> less got things working with 4.3, but there are a couple of issues we
> need to sort out.  I'll also need people to compile M5 on as many
> systems as possible to make sure that my changes don't break things.
> (I'll commit the patches in a day or so)
>
> 1) G++ now complains about lack of parenthesis in expressions with
> combinations of operators that are commonly screwed up.  We can
> disable the warning with -Wno-parentheses and ignore the issue.  I
> generally feel that people should know their order of operations, but
> with so many people hacking, maybe it's worth it to fix them and
> enable the warning.  Examples
>
> a && b || c && d    ===>    (a && b) || (c && d)
> a << b - c             ===>    a << (b - c)
I even went so far as to print out order of operation lists and post  
them on everyones monitor. However, I suppose the parenthesis are  
acceptable. I think that is probably better than disabling the  
warning. I know one I've messed up before is ?: and that tends to lead  
to very bizarre errors.

> 2) hash_map is now deprecated and people are supposed to use
> unordered_map which will be in the next C++ standard.  Unfortunately,
> it's not too easy to provide an adapter between the two without using
> #define.  We can ignore the error for now with -Wno-deprecated, but
> we're going to have to bite the bullet at some point when hash_map is
> really moved.  To top things off, if you use unordered_map, you have
> to set --std=c++0x or --std=gnu++0x.  I'm inclined to disable the
> warning, and just do whatever magic is necessary when things finally
> break, but the downside of that is when they do break, it might be
> harder to keep older versions of compilers working if we don't have
> some sort of adapter.
We already have a #define for the hashmap namespace. I don't see a  
huge problem with another one. So hash_map is deprecated and you don't  
get unordered_map without --std==c++0x? How annoying.  The only way I  
can see to check in the code if it's a c++0x compile is  
__GXX_EXPERIMENTAL_CXX0X__ which doesn't seem particularly portable. I  
think I'm with you that disabling the warning is probably the best  
thing to do at this point and see where things shake out in a revision  
or two.

Ali

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

Reply via email to