That's even more odd to me. x86_64 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::elapsed_frequency();
return count/freq;
}
and os::elapsed_frquency is a constant (1000*1000*1000) on Solaris.
Both crashes occurs on 64-bit on Solaris AMD64.
Thanks,
David
Tom Rodriguez said the following on 03/26/09 08:53:
FPE_FLTRES 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 si_code
FPE_FLTRES? 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
