On Mar 26, 11:01am, thomas.rodrig...@sun.com (Tom Rodriguez) wrote:
-- Subject: Re: SIGFPE with FPE_FLTRES
| > I would just remove the trancendental c implementation. It is not
| > consistent
| > with the java one anyway on amd64:
|
| You've got that backwards. The C imp
I would just remove the trancendental c implementation. It is not
consistent
with the java one anyway on amd64:
You've got that backwards. The C implementation is actually the
correct result as far as the spec goes and it's what is used by
StrictMath.log. Math.log is allowed to produce l
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
On Mar 25, 4:28pm, thomas.rodrig...@sun.com (Tom Rodriguez) wrote:
-- Subject: Re: SIGFPE with FPE_FLTRES
| 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
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
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
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;
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
