Hi Andreas,
I'm pretty confident that this code works correctly independent of the iterator
order, however the order will impact the determinism of the simulation. Yes,
when I wrote that code, I was leveraging the ordering of the ext/hash_map
implementation. I can check in a simple patch that uses the stl::map instead,
but it is not easy for me to test with gcc 4.6+.
Can I just assume that will fix things, or would you like to test out the
changes? Below is the diff (again a very simple change).
Brad
diff --git a/src/mem/ruby/buffers/MessageBuffer.hh
b/src/mem/ruby/buffers/MessageBuffer.hh
--- a/src/mem/ruby/buffers/MessageBuffer.hh
+++ b/src/mem/ruby/buffers/MessageBuffer.hh
@@ -162,7 +162,7 @@
Consumer* m_consumer_ptr; // Consumer to signal a wakeup(), can be NULL
std::vector<MessageBufferNode> m_prio_heap;
- typedef m5::hash_map< Address, std::list<MsgPtr> > StallMsgMapType;
+ typedef std::map< Address, std::list<MsgPtr> > StallMsgMapType;
typedef std::vector<MsgPtr>::iterator MsgListIter;
StallMsgMapType m_stall_msg_map;
diff --git a/src/mem/slicc/symbols/StateMachine.py
b/src/mem/slicc/symbols/StateMachine.py
--- a/src/mem/slicc/symbols/StateMachine.py
+++ b/src/mem/slicc/symbols/StateMachine.py
@@ -324,7 +324,7 @@
bool m_is_blocking;
std::map<Address, MessageBuffer*> m_block_map;
typedef std::vector<MessageBuffer*> MsgVecType;
-typedef m5::hash_map< Address, MsgVecType* > WaitingBufType;
+typedef std::map< Address, MsgVecType* > WaitingBufType;
WaitingBufType m_waiting_buffers;
int m_max_in_port_rank;
int m_cur_in_port_rank;
> -----Original Message-----
> From: [email protected] [mailto:gem5-dev-
> [email protected]] On Behalf Of Andreas Hansson
> Sent: Saturday, April 07, 2012 4:18 AM
> To: gem5 Developer List
> Subject: [gem5-dev] Failing Ruby regressions with gcc >= 4.6
>
> Hi everyone,
>
> With the latest patches for compiling using -std=c++0x and gcc 4.6, there are
> sporadic failures for some Ruby regressions, e.g. last night:
>
>
> *****
> build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/
> memtest-ruby-MOESI_hammer FAILED!
>
> *****
> build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/lin
> ux/rubytest-ruby-MOESI_CMP_token FAILED!
>
> *****
> build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/lin
> ux/memtest-ruby-MOESI_CMP_token FAILED!
>
>
> I suspect that this is due to the different implementation of the hash map
> (used to be ext/hash_map, and is now unordered map) and the use of
> iterators to traverse this map in parts of Ruby. For example, in
> StateMachine.py:
>
> for (WaitingBufType::iterator buf_iter = m_waiting_buffers.begin();
> buf_iter != m_waiting_buffers.end();
> ++buf_iter) {
> for (MsgVecType::iterator vec_iter = buf_iter->second->begin();
> vec_iter != buf_iter->second->end();
> ++vec_iter) {
> if (*vec_iter != NULL) {
> (*vec_iter)->reanalyzeAllMessages();
> }
> }
> wokeUpMsgVecs.push_back(buf_iter->second);
> }
>
> I am not sure if this particular piece of code is the issue, but in general we
> have to ensure that any iteration over a hashtable does not have _any
> ordering dependency_ since nothing can be assumed about the order of the
> traversal. I can try and look through some of the files, but would greatly
> appreciate if someone more at home with Ruby could help and track down all
> the places where iteration takes place and confirm that the behaviour is
> deterministic independent of the order (or alternatively add an ordered
> container next to the hash table for keeping an ordered list/vector etc).
>
> Thanks,
>
> Andreas
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
