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

[Yasumasa Suenaga]

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/


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.
>