Re: CVS commit: src/tests/lib/libc/locale

2017-11-29 Thread Robert Elz 
Date:Wed, 29 Nov 2017 16:51:56 +
From:Taylor R Campbell 
Message-ID:  <20171129165637.6fa4960...@jupiter.mumble.net>

  | This is starting to smell like a compiler bug in fp correctness...but
  | I'm out of time to diagnose it further.

In case anyone missed it, the i386 ATF test on b5 failed the exact same way
(same values) as my Xen DomU i386 test.   But that was as expected I think.

Since this has now devolved to a discussion of how i386 FP works, and
how the compiler generates code to use it, I'm out of this discussion from
here on (I will send a message on port-i386 and tech-userlevel to see if
someone with i386 FP knowledge can work out who/what is at fault here.)

Unless someone finds a fix, or at least finds the source of the problem,
and files a PR,  I will return this test to "succeeding" status (by "hiding"
the problem, as Joerg put it).  This test is not the place to diagnose either
compiler issues, or i386 floating point issues.   If we need a test for those,
please add one - elsewhere.

kre

Re: CVS commit: src/tests/lib/libc/locale

2017-11-29 Thread Taylor R Campbell 
> Date: Wed, 29 Nov 2017 09:14:26 +0100
> From: Martin Husemann 
> 
> (gdb) info float
>   R7: Valid   0xc00cc0e6b7318fc50481 -12345.678979  
> =>R6: Valid   0xc00cc0e6b7318fc50800 -12345.678979  
>   R5: Empty   0xc00cc0e6b7318fc50800
> [...]
> Control Word:0x037f   IM DM ZM OM UM PM
>PC: Extended Precision (64-bits)
>RC: Round to nearest

Here R7 contains 0xc00cc0e6b7318fc50481, the value that strtod
returned, and R6 contains 0xc00cc0e6b7318fc50800, the value that was
stored in the program.  We switched in 6.99.26 from default 53-bit
precision to default 64-bit precision.

I tried running my program on netbsd-6.  It passed just fine.  I made
the following two changes:

1. replace double by long double
2. set the fp control word to 0x307f

With either one individually and -O0, it still passes.  With both of
them together and -O0, it fails and gives 0xc00cc0e6b7318fc50481 as
the answer from strtod.  With just (2) and -O2, it also fails and
gives 0xc00cc0e6b7318fc50481 as the answer from strtod.

This is starting to smell like a compiler bug in fp correctness...but
I'm out of time to diagnose it further.

Re: CVS commit: src/sys

2017-11-29 Thread Ryo ONODERA 
Hi,

From: Robert Elz , Date: Sat, 25 Nov 2017 21:16:56 +0700

> Date:Sat, 25 Nov 2017 18:11:22 +0900 (JST)
> From:Ryo ONODERA 
> Message-ID:  <20171125.181122.805047996391646417@tetera.org>
> 
>   | After the following commit, my IPv6 network does not work at all.
>   | What information is required to investigate my problem?
> 
> I believe this might be fixed now - at least IPv6 seems to be
> back working again.
> 
> I still don't believe that the way it works is the way it should,
> but that's a topic for another day.

Thank you very much.
My environment works fine now.

Thanks again.

> kre
> 

--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: CVS commit: src/tests/lib/libc/locale

2017-11-29 Thread Martin Husemann 
For the gcc 5.5 version:

30  if (!(d == t->double_value)) {
(gdb) x/16i $pc
=> 0x804887c :  fldl   0x4(%ebx)
   0x804887f :  fucomp %st(2)
   0x8048881 :  fnstsw %ax
   0x8048883 :  sahf   
   0x8048884 :  jp 0x8048891 
   0x8048886 :  jne0x8048891 

and after the sahf:

(gdb) info float
  R7: Valid   0xc00cc0e6b7318fc50481 -12345.678979  
=>R6: Valid   0xc00cc0e6b7318fc50800 -12345.678979  
  R5: Empty   0xc00cc0e6b7318fc50800
  R4: Empty   0x
  R3: Empty   0x
  R2: Empty   0x
  R1: Empty   0x
  R0: Empty   0x

Status Word: 0x3120  PE C0 
   TOP: 6
Control Word:0x037f   IM DM ZM OM UM PM
   PC: Extended Precision (64-bits)
   RC: Round to nearest
Tag Word:0x0fff
Instruction Pointer: 0x17:0x0804887f
Operand Pointer: 0x1f:0x08049cd0
Opcode:  0xddea

and the "jne" is taken.

Martin

Re: CVS commit: src/tests/lib/libc/locale

2017-11-29 Thread Martin Husemann 
On Wed, Nov 29, 2017 at 09:03:50AM +0100, Martin Husemann wrote:
> On Wed, Nov 29, 2017 at 06:12:02AM +, Taylor R Campbell wrote:
> > (My guess is that there's something screwy with i387 long doubles, but
> > I don't have a good guess about where that screwiness might be
> > happening without single-stepping through it.)
> 
> My blame is on qemu.

Heh, misread the test code. Duh!

Martin