diff options
author | Steve Reinhardt <stever@gmail.com> | 2008-06-13 01:29:20 -0400 |
---|---|---|
committer | Steve Reinhardt <stever@gmail.com> | 2008-06-13 01:29:20 -0400 |
commit | 024ec4c5c310b1225a52532d41d5cc9f2633ae6c (patch) | |
tree | e2792fceab44c2fe9518fd40d2d5ad27d74de945 /src | |
parent | 2b4874449ce45504a1759c593a1f9b00983fca01 (diff) | |
download | gem5-024ec4c5c310b1225a52532d41d5cc9f2633ae6c.tar.xz |
Get rid of bogus cache assertion.
I was asserting that the only reason you would defer targets is if
a write came in while you had an outstanding read miss, but there's
another case where you could get a read access after you've snooped
an invalidation and buffered it because it applies to a prior
outstanding miss.
Diffstat (limited to 'src')
-rw-r--r-- | src/mem/cache/cache_impl.hh | 1 |
1 files changed, 0 insertions, 1 deletions
diff --git a/src/mem/cache/cache_impl.hh b/src/mem/cache/cache_impl.hh index 7bab3012b..3b56c0a2e 100644 --- a/src/mem/cache/cache_impl.hh +++ b/src/mem/cache/cache_impl.hh @@ -823,7 +823,6 @@ Cache<TagStore>::handleResponse(PacketPtr pkt) } if (mshr->promoteDeferredTargets()) { - assert(mshr->needsExclusive() && !blk->isWritable()); // avoid later read getting stale data while write miss is // outstanding.. see comment in timingAccess() blk->status &= ~BlkReadable; |