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
