I don't want to be overly controlling, but I don't think this is the correct fix and I don't think you should have committed this changeset. As a stop gap, I guess this is OK, but this really is not the right fix.
Nate On Thu, Dec 23, 2010 at 11:41 AM, Nilay Vaish <[email protected]> wrote: > changeset fbf4b1b18202 in /z/repo/m5 > details: http://repo.m5sim.org/m5?cmd=changeset;node=fbf4b1b18202 > description: > PerfectCacheMemory: Add return statements to two functions. > Two functions in src/mem/ruby/system/PerfectCacheMemory.hh, > tryCacheAccess() > and cacheProbe(), end with calls to panic(). Both of these functions > have > return type other than void. Any file that includes this header file > fails > to compile because of the missing return statement. This patch adds > dummy > values so as to avoid the compiler warnings. > > diffstat: > > src/mem/ruby/system/PerfectCacheMemory.hh | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diffs (19 lines): > > diff -r f249937228b5 -r fbf4b1b18202 src/mem/ruby/system/PerfectCacheMemory.hh > --- a/src/mem/ruby/system/PerfectCacheMemory.hh Wed Dec 22 23:15:24 2010 -0600 > +++ b/src/mem/ruby/system/PerfectCacheMemory.hh Thu Dec 23 13:36:18 2010 -0600 > @@ -124,6 +124,7 @@ > bool& block_stc, ENTRY*& entry) > { > panic("not implemented"); > + return true; > } > > // tests to see if an address is present in the cache > @@ -167,6 +168,7 @@ > PerfectCacheMemory<ENTRY>::cacheProbe(const Address& newAddress) const > { > panic("cacheProbe called in perfect cache"); > + return newAddress; > } > > // looks an address up in the cache > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
