RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6

[David Holmes]

On 2/07/2016 10:53 PM, Yasumasa Suenaga wrote:
> Hi Kim,
>
>> So the proposed casts seem to me to be just papering over a deeper
>> problem. I suggest separating this into a different CR for later
>> cleanup, since it's not an immediate problem once the build problem is
>> fixed.
>
> I removed change for type.hpp in new webrev:
>
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8160353/webrev.01/

These changes seem fine to me.

Thanks,
David

>
> If JDK-8156980 is resolved, this error will be gone.
> IMHO, it should be fixed.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2016/07/02 4:16, Kim Barrett wrote:
>>> On Jun 27, 2016, at 11:36 PM, Yasumasa Suenaga <yasuenag at gmail.com>
>>> wrote:
>>>
>>> Hi Kim,
>>>
>>>> I would prefer that compiler configuration issue got fixed and these
>>>> kinds of issues be deferred to a future modernization project.
>>>
>>> IMHO, src/os/linux/vm/os_linux.cpp should be fixed at least because
>>> elf_class
>>> and endianess is defined as unsigned char.
>>
>> ------------------------------------------------------------------------------
>>
>> src/os/linux/vm/os_linux.cpp
>> Looks good.
>>
>> ------------------------------------------------------------------------------
>>
>> src/share/vm/classfile/altHashing.cpp
>> Much as I dislike casts, this change is culturally compatible with the
>> surrounding code.  Cleaning that up is a task for another time.
>>
>> Looks good.
>>
>> ------------------------------------------------------------------------------
>>
>> src/share/vm/opto/type.cpp
>>
>> There seems to be inconsistency about whether these register
>> categories are signed or unsigned. The Node class defines "uint
>> ideal_reg()" and NotAMachineReg is a special value that must be > max.
>> machine register. The Type class has "int ideal_reg()" which deals in
>> the same values.
>>
>> So the proposed casts seem to me to be just papering over a deeper
>> problem. I suggest separating this into a different CR for later
>> cleanup, since it's not an immediate problem once the build problem is
>> fixed.
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>>>
>>> In other point, I confirmed that we can avoid -std=gnu++98 as below:
>>
>> Replied in another thread.
>>