RFR 8014431 : cleanup warnings indicated by the -Wunused-value compiler option on linux

[Calvin Cheung]

On 5/23/2013 5:45 AM, David Holmes wrote:
> Hi Calvin,
>
> Mostly looks okay to me. A few comments
Thanks for your review.
>
> src/share/vm/memory/universe.cpp
>
> Seems like a real bug!
>
> -- 
>
> src/share/vm/opto/memnode.cpp:
>
> I think it is cleaner to add the (void) to the macro definition as in 
> other cases:
> #define verify_memory_slice(m,i,n) (void)(0) // PRODUCT version is no-op
>
I've fixed it.
> ---
>
> src/share/vm/runtime/perfData.hpp
>
> This can't be right:
>
> 773 return create_string_variable(ns, name, (int)0, s, CHECK_NULL);
>
> why do we have to cast 0 to int ????
I've removed it.
>
> ---
>
> src/share/vm/services/diagnosticArgument.cpp
>
> Another real bug!
>
> ---
>
> src/share/vm/utilities/taskqueue.hpp
>
> I do not understand this code:
>
> ! // g++ complains if the volatile result of the assignment is unused.
> ! const_cast<E&>(_elems[localBot] = t);
>
> why do we even need the const cast? How is the assignment not used ???
I've tried without the const cast and got the following error:
/scratch/cccheung/hs25/src/share/vm/utilities/taskqueue.hpp:348: error: 
object of type ‘volatile StarTask&’ will not be accessed in statement

There was an original comment about the const cast as follows:
343 // g++ complains if the volatile result of the assignment is unused.
344 const_cast<E&>(_elems[localBot] = t);

thanks,
Calvin
>
> I understand your fix of adding (void) but I'm baffled by the original 
> code.
>
> ---
>
> Thanks,
> David
> -----
>
> On 22/05/2013 5:32 AM, Calvin Cheung wrote:
>> This change is for fixing the errors resulting from enabling the
>> -Wunused-value compiler option on linux.
>>
>> The patch was initiated by Jeremy (jeremymanson at google.com).
>> More changes are needed for it to pass the build.
>>
>> Tests performed:
>> jprt
>> jtreg on linux_x64
>> vm.quick on linux_x64
>>
>> Webrev: http://cr.openjdk.java.net/~ccheung/8014431/webrev/
>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8014431
>>
>> thanks,
>> Calvin