Nilay,

I know that this is a way old e-mail, but did you ever figure this out?

  Nate

On Fri, Dec 24, 2010 at 8:57 AM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
> I tried M5_DUMMY_RETURN and it it not working. I checked its definition. It
> would evaluate to nothing, in which case I do not see why it should help in
> avoiding the warning. I tried putting a return statement before panic();
>
> return panic("not implemented");
>
> This works with GCC 4.2.2.
>
> I checked whether GCC has some recorded bug reports for this. I found the
> following two -
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42674
>
> I tried the provided codes. For the first one, 4.2.2 raises a warning but
> 4.4.0 does not. For the second one, 4.4.0 raises a warning but 4.2.2 does
> not.
>
> --
> Nilay
>
> On Thu, 23 Dec 2010, Ali Saidi wrote:
>
>> A better solution would be to put M5_DUMMY_RETURN there. I know there'd
>> were some issues with some versions of gcc not respecting the attribute no
>> return. This might be the case.
>>
>> Ali
>>
>> Sent from my ARM powered device
>>
>> On Dec 23, 2010, at 1:10 PM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
>>
>>> 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
>>
> _______________________________________________
> 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

Reply via email to