Am 27.05.2015 um 21:06 schrieb Maciej W. Rozycki: > On Wed, 27 May 2015, Ole Streicher wrote: > >> It is something specific what gfortran produces (and not gcc), and it is not >> just a missing emulation (since normalized numbers work); it may be an >> incomplete emulation. > > 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. > 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 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. Best regards Ole -- 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/55661893.30...@debian.org
