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 > Cowgill? 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. Maciej -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.lfd.2.11.1505272023010.21...@eddie.linux-mips.org
