SIGFPE with FPE_FLTRES (original) (raw)

Volker Simonis volker.simonis at gmail.com
Thu Mar 26 09:47:11 UTC 2009

As far as I can see, "old FP" instructions are still emitted for example for the logarithm (see log10D_reg and logD_reg in x86_64.ad, which use fldlg2, fldln2 and fyl2x). These instructions can interact badly with code generated by the native C/C++ compiler.

I had such a problem a while ago under Windows/AMD64 with the new MSVC 2005 compiler (and msvcr80d.dll). The logarithm instructions mentioned above did set the "divide by zero" flag in the FP status word if called with a zero argument. Later on, this led to an error in a reminder operation, because that reminder operation was mapped to the native "fmod()" function by "SharedRuntime::drem()" and "fmod()" in turn used "old FP" instructions in its implementation which failed because of the pending "divide by zero" flag in the FP status word.

You could check if the code generated for "cpuTimer::seconds()" contains "old FP" instructions. If yes, they may interact with some other FP instructions, emitted by the JIT (or the template interpreter, as mentioned by Tom).

Regards, Volker

On 3/26/09, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:

That's even more odd to me. x8664 shouldn't be using the old FP instructions and the SSE based one don't produce an inexact traps as far as I can tell. Maybe they are still being emitted somewhere, possibly for the transcendentals? Actually I can see that the template interpreter still uses them so maybe something is happening there with a left over precision exception?

tom

On Mar 25, 2009, at 4:10 PM, David Holmes - Sun Microsystems wrote: > The code was innocuous as far as I can see. One place does some basic calculations with some values used for GC statistics. The other was a crash here: > > double cpuTimer::seconds() const { > double count = (double) counter; > double freq = (double) os::elapsedfrequency(); > return count/freq; > } > > and os::elapsedfrquency is a constant (100010001000) on Solaris. > > Both crashes occurs on 64-bit on Solaris AMD64. > > Thanks, > David > > Tom Rodriguez said the following on 03/26/09 08:53: > > > FPEFLTRES appears to concern inexact results being produced but these kinds of exception should always be masked for us. In what kind of code was this reported? > > tom > > On Mar 24, 2009, at 5:58 PM, David Holmes - Sun Microsystems wrote: > > > > > Can someone tell me when you can encounter a SIGFPE with sicode FPEFLTRES? I'm suspecting this may be a case where a "bad" operation doesn't in itself fail but the next (innocent) FP operation gets hit with the FPE. > > > > > > Thanks, > > > David Holmes > > > > > >

More information about the core-libs-dev mailing list