Re: (Hardware?) problem with denormal values on mipsel
On Wed, 27 May 2015, Ole Streicher wrote:
> > If you suspect a bug in emulation, then please try narrowing it down to
> > the machine instruction that produces the wrong result, you might be able
> > to track it down in your Fortran program by single-stepping the program in
> > GDB.
> Sorry, as I wrote in my initial mail: I can't. I initially had the problem
> on eder.debian.org, and reported it as a gfortran bug. Now I got a CI20, and
> since the problem does not appear there, I suspect that it may be a
> processor (or related) problem. However, eder is not available in the
> moment, so I can't do anything.
I didn't have a chance to see your initial mail, I'm not subscribed to
any of the mailing-lists cc-ed and I was only pulled into the discussion
mid-way through, by James. If you or anyone else cannot provide a small
test case, then I have no way to help. Moreover if the bug manifests
itself on certain hardware only, then even more details may be needed.
> > Then post the instruction including the encoding (`disassemble /r'
> > issued in GDB will include it in output), the inputs, preferably as hex
> > patterns, and the output produced (or action taken if e.g. a signal is
> > raised instead) that you think is incorrect.
> I probably don't understand you here; but wasn't this already done by James
I don't know, all I saw was IIUC fixed with 2d83fea786d7.
> I feel myself a bit incompetent when it comes to MIPS assembly. I
> can just report my high-level tests:
> - denormalized numbers don't work in Fortran on eder
> - normalized numbers work in Fortran on eder
> - normalized and denormalized numbers work in the equivalent C program on eder
> - Fortran and C works with all numbers on a CI20.
What do you mean by: "denormalized numbers don't work" -- do they crash
the program? Produce an incorrect result? Anything else?
I'm no expert on Fortran, but the difference between Fortran and C is
very suspicious. Do you or anyone else know whether the Fortran runtime
sets the IEEE 754 hardware environment any differently to what C does?
NB denormalized numbers are special in the MIPS environment in that most
processors do not handle such inputs in hardware, and neither they handle
tiny results. An Unimplemented Operation exception is triggered instead
and the in-kernel FPU emulator fixes it up, by completing the operation
requested in software. Some MIPS hardware does handle these data and does
not trigger any exception.
Furthermore there's a flush-to-zero mode available, that can be freely
enabled and disabled by user software, where denormalized operands and
tiny results are silently replaced with 0 of the same sign. An Inexact
IEEE 754 exception is raised though in both cases, and for tiny result an
Underflow IEEE 754 exception as well. Some older processors do not handle
the flush-to-zero mode for denormalized inputs though.