In fact stl does use the comparison. That is how I ran into the bug.
#0 0x0000003877630265 in raise () from /lib64/libc.so.6
#1 0x0000003877631d10 in abort () from /lib64/libc.so.6
#2 0x00000038776296e6 in __assert_fail () from /lib64/libc.so.6
#3 0x00000000012a710f in operator> (lhs=..., rhs=...)
at build/gpu_RfO/mem/ruby/slicc_interface/Message.hh:124
#4 0x00000000012a88eb in std::greater<std::shared_ptr<Message> >::operator() (
this=0x7fffffffb9e0, __x=..., __y=...)
at
/tool/pandora64/.package/gcc-4.8.0/include/c++/4.8.0/bits/stl_function.h:226
#5 0x00000000012a7e08 in
std::__adjust_heap<__gnu_cxx::__normal_iterator<std::shared_ptr<Message>*,
std::vector<std::shared_ptr<Message>, std::allocator<std::shared_ptr<Message> >
> >, long, std::shared_ptr<Message>, std::greater<std::shared_ptr<Message> > >
(__first=..., __holeIndex=0, __len=3, __value=...,
__comp=...)
at /tool/pandora64/.package/gcc-4.8.0/include/c++/4.8.0/bits/stl_heap.h:309
#6 0x00000000012a7808 in
std::__pop_heap<__gnu_cxx::__normal_iterator<std::shared_ptr<Message>*,
std::vector<std::shared_ptr<Message>, std::allocator<std::shared_ptr<Message> >
> >, std::greater<std::shared_ptr<Message> > > (__first=...,
__last=..., __result=..., __comp=...)
at /tool/pandora64/.package/gcc-4.8.0/include/c++/4.8.0/bits/stl_heap.h:338
#7 0x00000000012a73ba in
std::pop_heap<__gnu_cxx::__normal_iterator<std::shared_ptr<Message>*,
std::vector<std::shared_ptr<Message>, std::allocator<std::shared_ptr<Message> >
> >, std::greater<std::shared_ptr<Message> > > (__first=...,
__last=..., __comp=...)
at /tool/pandora64/.package/gcc-4.8.0/include/c++/4.8.0/bits/stl_heap.h:367
#8 0x00000000013d6182 in WireBuffer::dequeue (this=0x629fda0)
at build/.../mem/ruby/structures/WireBuffer.cc:97
Brad
-----Original Message-----
From: Nilay Vaish [mailto:[email protected]]
Sent: Thursday, July 30, 2015 10:03 AM
To: Beckmann, Brad
Cc: gem5 Developer List
Subject: RE: [gem5-dev] changeset in gem5: ruby: remove message buffer node
On Thu, 30 Jul 2015, Beckmann, Brad wrote:
> Hi Nilay,
>
> As part of our check-ins tomorrow, I would like to check in a single
> line bug fix to this patch. Specifically we plant to remove the
> assert in the overload function of the MsgPtr operator>. It is
> perfectly valid to compare the same MsgPtr to itself. Currently the
> assert prevents such a comparison.
>
> I don't expect this to be much of an issue, but I wanted you to be aware.
>
> Thanks,
>
> Brad
>
>
> Specific patch:
>
>
> diff --git a/src/mem/ruby/slicc_interface/Message.hh
> b/src/mem/ruby/slicc_interface/Message.hh
> --- a/src/mem/ruby/slicc_interface/Message.hh
> +++ b/src/mem/ruby/slicc_interface/Message.hh
> @@ -121,7 +121,6 @@
> const Message *r = rhs.get();
>
> if (l->getLastEnqueueTime() == r->getLastEnqueueTime()) {
> - assert(l->getMsgCounter() != r->getMsgCounter());
> return l->getMsgCounter() > r->getMsgCounter();
> }
> return l->getLastEnqueueTime() > r->getLastEnqueueTime();
I am ok with the change. But I am surprised you end up comparing a message to
itself. As I understand, this operator is only used for pushing to and popping
from message buffers. And I would be surprised if stl compares an object to
itself for heap/priority queue operations.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
