URGENT: RFR(trivial): 8237747: Build broken on macOS by JDK-8235741 - wrong format specifier

[David Holmes]

Thanks Fred - already pushed.

But I need to correct my description below. Turns out Xcode does pretend 
to be gcc for globalDefinitions purposes and so the real definition of 
JLONG_FORMAT for macOS is actually given by:

#if defined(_LP64) && defined(__APPLE__)
#define JLONG_FORMAT "%ld"

Hence the error.

The better fix, now I see this, would have been to use INT64_FORMAT 
instead. <sigh>

David

On 23/01/2020 9:23 am, Frederic Parain wrote:
> Looks good as a quick fix.
> 
> Fred
> 
> 
>> On Jan 22, 2020, at 18:18, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237747
>> webrev: http://cr.openjdk.java.net/~dholmes/8237747/webrev/
>>
>> There seems to be an issue with Xcode that JLONG_FORMAT aka INT64_FORMAT can't be used with int64_t variable:
>>
>> error: format specifies type 'long' but the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat]
>>
>> Simplest immediate fix is to cast to jlong:
>>
>> --- old/src/hotspot/share/jvmci/jvmciCompiler.cpp	2020-01-22 18:04:44.723683733 -0500
>> +++ new/src/hotspot/share/jvmci/jvmciCompiler.cpp	2020-01-22 18:04:43.607670979 -0500
>> @@ -95,7 +95,7 @@
>>
>>    if (PrintBootstrap) {
>>      tty->print_cr(" in " JLONG_FORMAT " ms (compiled %d methods)",
>> -                  nanos_to_millis(os::javaTimeNanos() - start), _methods_compiled);
>> +                  (jlong)nanos_to_millis(os::javaTimeNanos() - start), _methods_compiled);
>>
>> I will file a bug for the INT64_FORMAT issue.
>>
>> Thanks,
>> David
>> -----
>>
>