Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-28 Thread Maciej W. Rozycki 
On Thu, 28 May 2015, James Cowgill wrote:

 Your test case is wrong. If compiled without optimization, GCC call
 'sqrt' from glibc instead of using the sqrt.s MIPS instruction. With
 optimization GCC will remove the call altogether. This is different to
 fortran because in fortran SQRT is a builtin intrinsic.
 
 Try this instead (compile with -O2 -lm):
 
 #include math.h
 float x = 1.1342362e-39;
 int main(void) {
   x = sqrt(x);
   return 0;
 }

 Use:

#include inttypes.h
#include stdio.h

int main(void)
{
union {
float f;
uint32_t i;
} x = { .f = 1.1342362e-39 }, y;

printf(x: %08 PRIx32 , %e\n, x.i, (double) x.f);
fflush(stdout);
asm volatile(
   sqrt.s  %0, %1
: =f (y.f) : f (x.f));
printf(y: %08 PRIx32 , %e\n, y.i, (double) y.f);
fflush(stdout);
return 0;
}

or suchlike to make sure the required instruction is produced (at any 
optimisation level), and to report the input and output bit patterns.  
Substitute the initialisation of `x' as required (you can assign to 
`x.f' or `x.i' as required).  No need to link against -lm.

 I have just tried this program with an R4400 (MIPS III) processor that 
does trap on denormals, and Linux 4.1.0-rc4, so emulation itself is fine:

x: 000c59ca, 1.134236e-39
y: 1f1f0ab7, 3.367842e-20

For comparison you can run the kernel with the `nofpu' parameter so that 
FPU hardware is permanently disabled and all FP instructions are emulated.

  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.1505281357080.21...@eddie.linux-mips.org

Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-28 Thread James Cowgill 
On Wed, 2015-05-27 at 20:46 +0200, Ole Streicher wrote:
 Hi all,
 
 Am 27.05.2015 um 15:45 schrieb James Cowgill:
  There's probably still a hardware bug in here somewhere, but before 3.16
  the kernel was fixing it with the math emulator.
 
 Without understanding the discussion in detail, I'd like to bring a few
 points here back: the issue is not about SIGILL on *any* call of sqrt; it is
 just when it is called with a denormal number. Using f.e. 1.134e-32 f.e.
 worked for me.

Yes the Loongson machines do not implement the sqrt.s instruction for
denormals, but it works for normalized numbers.

 Also, the minimal C analogon
 
 #include math.h
 int main(void) {
   float r = 1.1342362e-39;
   r = sqrt(r);
   exit(0);
 }

Your test case is wrong. If compiled without optimization, GCC call
'sqrt' from glibc instead of using the sqrt.s MIPS instruction. With
optimization GCC will remove the call altogether. This is different to
fortran because in fortran SQRT is a builtin intrinsic.

Try this instead (compile with -O2 -lm):

#include math.h
float x = 1.1342362e-39;
int main(void) {
  x = sqrt(x);
  return 0;
}

Thanks,
James


signature.asc
Description: This is a digitally signed message part

Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-27 Thread Maciej W. Rozycki 
On Wed, 27 May 2015, James Cowgill wrote:

 Thanks! The kernel was the important part which was different to my
 setup.
 
 There's probably still a hardware bug in here somewhere, but before 3.16
 the kernel was fixing it with the math emulator.
 
 From what I can see:
 Commit 08a07904e182 in 3.16 ('MIPS: math-emu: Remove most ifdefery.')
 incorrectly disabled emulation of the sqrt.s instruction on processors
 only supporting the mips2/mips3 ISA.
 
 Commit 7352c8b13dd9 in 3.18 ('MIPS: Loongson: Set Loongson-3's ISA level
 to MIPS64R1') worked around this in the Loongson 3s because their ISA
 level was bumped to mips64r1.
 
 Commit 2d83fea786d7 in 4.1-rc1 ('MIPS: Correct FP ISA requirements')
 fixed the underlying sqrt.s emulation bug.
 
 It would be good if the 4.1-rc1 patch or at least the 'case fsqrt_op'
 part (which is the fix for this bug) can be applied to a jessie stable
 kernel and then installed on the buildds. This should fix the original
 problem of eso-midas failing to build on mipsel.

 What's the actual problem here, how can I help?

  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.1505271810500.21...@eddie.linux-mips.org

Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-27 Thread Maciej W. Rozycki 
On Wed, 27 May 2015, James Cowgill wrote:

   Commit 2d83fea786d7 in 4.1-rc1 ('MIPS: Correct FP ISA requirements')
   fixed the underlying sqrt.s emulation bug.
   
   It would be good if the 4.1-rc1 patch or at least the 'case fsqrt_op'
   part (which is the fix for this bug) can be applied to a jessie stable
   kernel and then installed on the buildds. This should fix the original
   problem of eso-midas failing to build on mipsel.
  
   What's the actual problem here, how can I help?
 
 I just thought I would let you know since it was your patch which was
 going to be applied somewhere.
 
 The bug is that Loongson machines relied on the kernel emulating sqrt.s
 for them (in certain cases) but between 3.16 and 4.1 it didn't and was
 causing things to SIGILL.

 Ah, OK then.  I'm glad you found my change useful.

  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.1505271829590.21...@eddie.linux-mips.org

Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-27 Thread James Cowgill 
On Wed, 2015-05-27 at 18:13 +0100, Maciej W. Rozycki wrote:
 On Wed, 27 May 2015, James Cowgill wrote:
 
  Thanks! The kernel was the important part which was different to my
  setup.
  
  There's probably still a hardware bug in here somewhere, but before 3.16
  the kernel was fixing it with the math emulator.
  
  From what I can see:
  Commit 08a07904e182 in 3.16 ('MIPS: math-emu: Remove most ifdefery.')
  incorrectly disabled emulation of the sqrt.s instruction on processors
  only supporting the mips2/mips3 ISA.
  
  Commit 7352c8b13dd9 in 3.18 ('MIPS: Loongson: Set Loongson-3's ISA level
  to MIPS64R1') worked around this in the Loongson 3s because their ISA
  level was bumped to mips64r1.
  
  Commit 2d83fea786d7 in 4.1-rc1 ('MIPS: Correct FP ISA requirements')
  fixed the underlying sqrt.s emulation bug.
  
  It would be good if the 4.1-rc1 patch or at least the 'case fsqrt_op'
  part (which is the fix for this bug) can be applied to a jessie stable
  kernel and then installed on the buildds. This should fix the original
  problem of eso-midas failing to build on mipsel.
 
  What's the actual problem here, how can I help?

I just thought I would let you know since it was your patch which was
going to be applied somewhere.

The bug is that Loongson machines relied on the kernel emulating sqrt.s
for them (in certain cases) but between 3.16 and 4.1 it didn't and was
causing things to SIGILL.

Thanks,
James



signature.asc
Description: This is a digitally signed message part

Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-27 Thread Maciej W. Rozycki 
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