Something else must be going on. There are a lot of cases where this
sort of thing happens, so something must be different about the
compilation environment for these files. Perhaps we should try to
compile on zizzer with VERBOSE=True to see what happens. We can also
give Nilay an account on zizzer so he can experiment. Unfortunately,
I don't have time to do that right at the moment.
Nate
> I am able to reproduce the warning. But I have to compile the files on my
> own (as in, write the compilation command on the command line) in order to
> reproduce the warning.
>
> This is the proposed patch.
>
> --
> Nilay
>
>
> diff --git a/src/mem/ruby/system/PerfectCacheMemory.hh
> b/src/mem/ruby/system/PerfectCacheMemory.hh
> --- a/src/mem/ruby/system/PerfectCacheMemory.hh
> +++ b/src/mem/ruby/system/PerfectCacheMemory.hh
> @@ -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
>
>
>
> On Thu, 23 Dec 2010, Nilay Vaish wrote:
>
>> I do not have GCC 4.2.4, but with GCC 4.2.2 I do not see those warnings.
>>
>> On Thu, 23 Dec 2010, Steve Reinhardt wrote:
>>
>>> It could be an issue with gcc 4.2.4 not properly handling the "no return"
>>> attribute in some cases... that being a bug that's fixed in 4.4 would
>>> explain why it works for you. That's just speculation on my part though.
>>> Does anyone else have any experience with this? Does the error go away
>>> on
>>> 4.2.4 if you put the dead 'return' statement back in the particular place
>>> that it's complaining about?
>>>
>>> Steve
>>>
>>> On Thu, Dec 23, 2010 at 8:12 AM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
>>>
>>>> Steve, you had commented that panic() and fatal() are marked as "no
>>>> return". Then, why should these warnings appear? And why would the
>>>> compiler
>>>> be fine with ERROR_MSG?
>>>>
>>>> --
>>>> Nilay
>>>>
>>>>
> _______________________________________________
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>
>
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
