Tom Rodriguez Thomas.Rodriguez at Sun.COM
Wed Mar 25 23:28:51 UTC 2009

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?


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

More information about the core-libs-dev mailing list