Submit repo reported build failure on macOS. Can you share details?
Job: mach5-one-ysuenaga-JDK-8250930-1-20200804-0139-13140081 Thanks, Yasumasa On 2020/08/04 10:38, Yasumasa Suenaga wrote:
Hi Chris, Thanks for your comment! I updated webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8250930/webrev.01/ This change produces infinite loop as below, it works fine. 1150: 8b 05 ae 2e 00 00 mov 0x2eae(%rip),%eax # 4004 <_ZZ100Java_nsk_jdwp_ThreadReference_ForceEarlyReturn_forceEarlyReturn002_forceEarlyReturn002a_nativeMethodE13dummy_counter> 1156: 85 c0 test %eax,%eax 1158: 74 f6 je 1150 <Java_nsk_jdwp_ThreadReference_ForceEarlyReturn_forceEarlyReturn002_forceEarlyReturn002a_nativeMethod+0x50> Thanks, Yasumasa On 2020/08/04 9:51, Chris Plummer wrote:Hi Yasumasa, Although I don't doubt that it works, calling fgetc() seems like an odd way to resolve this issue. I had some internal discussions on how to safely cause an infinite loop. Something like the following should work: static volatile int dummy_counter = 0; while (dummy_counter == 0) {} volatile is important because it prevents gcc from assuming dummy_counter will always be 0. thanks, Chris On 8/2/20 10:55 PM, Yasumasa Suenaga wrote:Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8250930 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8250930/webrev.00/ Following tests which were compiled by GCC 10.2 failed. - vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn004/forceEarlyReturn004.java - vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java They have native module, and they are commented as below: ``` // execute infinite loop to be sure that thread in native method while (always_true) { // Need some dummy code so the optimizer does not remove this loop. dummy_counter = dummy_counter < 1000 ? 0 : dummy_counter + 1; } // The optimizer can be surprisingly clever. // Use dummy_counter so it can never be optimized out. // This statement will always return 0. return dummy_counter >= 0 ? 0 : 1; ``` C compiler maybe eliminate this loop. We should not consider compiler optimization at this point with other solution. Thanks, Yasumasa
