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.rodrig...@sun.com> wrote:
> 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
> > > >
> > >
> >
>
>
