Date:Sat, 2 Dec 2017 00:09:29 +0100
From:Joerg Sonnenberger
Message-ID: <20171201230929.ga13...@britannica.bec.de>
| This is *not* true. With C11 the standard is very explicit that return
| must discard excessive precision. Even before, it was implied that there
On Fri, Dec 01, 2017 at 01:08:35AM +, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Fri Dec 1 01:08:35 UTC 2017
>
> Modified Files:
> src/tests/lib/libc/locale: t_sprintf.c
>
> Log Message:
> Since the C standard allows for intermediate floating results to c
Date:Thu, 30 Nov 2017 23:09:07 +0100
From:Manuel Bouyer
Message-ID: <20171130220907.ga2...@antioche.eu.org>
| Shouldn't it be made Xfail on i386 in this case ?
I don't think so, especially not now the problem is understood - it is
trivial to make it work on i386, t
On Thu, Nov 30, 2017 at 06:16:10AM +0700, Robert Elz wrote:
> 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
>
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
> 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
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
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 s
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.
I added the missing pr
Date:Wed, 29 Nov 2017 06:12:02 +
From:Taylor R Campbell
Message-ID: <20171129061642.e8dcb60...@jupiter.mumble.net>
| That's pretty interesting!
That is what I thought, it was certainly not what I expected.
| Can you reproduce it in a small isolated program l
> Date: Wed, 29 Nov 2017 11:41:58 +0700
> From: Robert Elz
>
> OK, got my i386 test setup (a Xen DomU) built & running, the updated
> test failed (as it always failed on i386 before I added the epsilon
> test, which is #if 0'd out now) the results are ...
>
> strto: [0.002429s] Failed:
> /r
Date:Wed, 29 Nov 2017 02:49:02 +
From:Taylor R Campbell
Message-ID: <20171129025342.734f860...@jupiter.mumble.net>
| If it turns out that this
| test is legitimately wrong on VAX, we can conditionalize it for VAX.
It wasn't whether it is going to be wrong the
Date:Tue, 28 Nov 2017 15:09:56 +
From:Taylor R Campbell
Message-ID: <20171128151435.9bbae60...@jupiter.mumble.net>
| Can you please put it back to an exact equality test and report the
| mismatched values in the output, with %a rather than (or in addition
|
> Date: Wed, 29 Nov 2017 05:37:56 +0700
> From: Robert Elz
>
> I think that conclusion had been reached already (not by me...) but that's
> "Under IEEE 754-2008" right? What about architectures that don't use IEEE
> floats? This test should not be assuming that - we still support vax right?
>
Date:Tue, 28 Nov 2017 15:34:19 +0100
From:Joerg Sonnenberger
Message-ID: <20171128143418.ga8...@britannica.bec.de>
| Hidding things until then doesn't actually fix something.
No, it doesn't, but when I made the change I wasn't hiding anything,
just doing what I tho
> Date: Tue, 28 Nov 2017 05:32:45 +0700
> From: Robert Elz
>
> Way back when I first learned floating point programming (something I
> have done astonishingly little of in the intervening decades) I was
> told it was *always* wrong to compare floats for exact equality - but
> of course, that was
On Tue, Nov 28, 2017 at 05:32:45AM +0700, Robert Elz wrote:
> Date:Mon, 27 Nov 2017 18:44:38 +0100
> From:Joerg Sonnenberger
> Message-ID: <20171127174438.ga20...@britannica.bec.de>
>
> | Parsing a string constant is a well-defined
> | operation with precise resul
Date:Mon, 27 Nov 2017 18:44:38 +0100
From:Joerg Sonnenberger
Message-ID: <20171127174438.ga20...@britannica.bec.de>
| Parsing a string constant is a well-defined
| operation with precise result. A cross-compiler that doesn't do that
| correctly is simply broken.
On Fri, Nov 24, 2017 at 09:30:43PM +, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Fri Nov 24 21:30:43 UTC 2017
>
> Modified Files:
> src/tests/lib/libc/locale: t_sprintf.c
>
> Log Message:
> When comparing doubles (any floating point values) which have been
19 matches
Mail list logo
