RFR: 8216154: C4819 warnings at HotSpot sources on Windows
Kim Barrett
kim.barrett at oracle.com
Mon Jan 7 20:50:54 UTC 2019
> On Jan 7, 2019, at 8:20 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>
> Hi,
>
> On Mon, 2019-01-07 at 21:36 +0900, Yasumasa Suenaga wrote:
>> Hi Kim,
>>
>> On 2019/01/07 7:18, Kim Barrett wrote:
>>>> On Jan 6, 2019, at 12:54 PM, Kim Barrett <kim.barrett at oracle.com>
>>>> wrote:
>>>>
>>>>> On Jan 6, 2019, at 7:53 AM, Yasumasa Suenaga <
>>>>> yasuenag at gmail.com> wrote:
>>>>>
>>>>> Hi Kim,
>>>>>
>>>>> Thank you for your comment.
>>>>> I uploaded new webrev to use pragma warning push/pop:
>>>>>
>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8216154/webrev.01/
>>>>>
>>>>>
>>>>> Please review again.
>>>>
>>>> Looks good.
>
> I tried to verify these problems on these two files as suggested with
> "iconv -f US-ASCII -t UTF8 <file>" which errored out on
> codeHeapState.cpp as expected but there has been no error with
> methodMatcher.cpp. Am I doing something wrong?
>
> I am fine with that change if it is really needed for successful
> compliation :) I just can't find the non-US-ASCII character used in the
> line indicated by the error message.
The problem is in RANGEBASE, which is referenced directly and appended
with other strings into RANGE0 and RANGESLASH, all of which are only
referenced in parse_method_pattern.
RANGEBASE is strings of '\xXX' encoded characters. At the source
level this is all fine. Even after preprocessing it should all be
fine, as the string/char encoding reduction doesn't happen until
translation phase 5, e.g. after preprocessing.
But during that encoding reduction the compiler is noticing that some
of the encodings (or sequence thereof?) don't map to valid characters
in the currently selected code page for the OS (Japanese in Yasumasa's
case). So it complains. It's kind of an annoying complaint, for
several reasons, but oh well.
It is because the warning is triggered by that encoding reduction
during compilation, rather than by literal characters in the source
code, that nothing problematic shows up with iconv/grep/&etc.
More information about the hotspot-compiler-dev
mailing list