For JDK-8261397 we check if we are running in emulation mode (i.e. Rosetta) on David Holme's request when he raised the original question of how safe is the workaround.
Mikael Vidsteadt raised the issue again, so need a definitive answer on what are the risk of the workaround of mapping "FPE_FLT..." (explicitly here the "FPE_FLTINV") to "FPE_INTDIV"
Are the "FPE_FLT.." used at all?
My initial investigation, documented in https://github.com/openjdk/jdk/pull/2615 revealed no, but need to investigate further.
Apple has fixed their bug, so conceivably we can only activate the workaround for those macOS version that have the bug.
Mikael Vidsteadt raised the issue again, so need a definitive answer on what are the risk of the workaround of mapping "FPE_FLT..." (explicitly here the "FPE_FLTINV") to "FPE_INTDIV"
Are the "FPE_FLT.." used at all?
My initial investigation, documented in https://github.com/openjdk/jdk/pull/2615 revealed no, but need to investigate further.
Apple has fixed their bug, so conceivably we can only activate the workaround for those macOS version that have the bug.
- relates to
-
JDK-8263603 Remove leftovers of "FPE_FLT..." type signals from regular signal handling code
- Closed
-
JDK-8261397 try catch Method failing to work when dividing an integer by 0
- Resolved
-
JDK-8017106 -XX:+UseLargePages is not rejected on MacOSX - causing crashes at startup
- Closed