Richard Henderson writes:
> On 04/17/2018 01:08 PM, Peter Maydell wrote:
>> On 18 April 2018 at 00:01, Peter Maydell wrote:
>>> I don't have the original IEEE754 spec to hand though;
>>> that may have left this unspecified.
>>
>> Having located a copy of 754-1985 I think that also is
>> clear e
On 19 April 2018 at 20:12, Richard Henderson
wrote:
> On 04/19/2018 09:06 AM, Richard Henderson wrote:
>> For ppc64, I believe there's a compiler bug:
>
> Bah. Apparently one must now use -fsignalling-nans.
> With that option we do generate the conversion insn.
"This option is experimental", the
On 04/19/2018 09:06 AM, Richard Henderson wrote:
> For ppc64, I believe there's a compiler bug:
Bah. Apparently one must now use -fsignalling-nans.
With that option we do generate the conversion insn.
r~
On 04/17/2018 01:08 PM, Peter Maydell wrote:
> On 18 April 2018 at 00:01, Peter Maydell wrote:
>> I don't have the original IEEE754 spec to hand though;
>> that may have left this unspecified.
>
> Having located a copy of 754-1985 I think that also is
> clear enough that float-float conversion is
On 18 April 2018 at 00:01, Peter Maydell wrote:
> I don't have the original IEEE754 spec to hand though;
> that may have left this unspecified.
Having located a copy of 754-1985 I think that also is
clear enough that float-float conversion is an operation
that must quieten SNaN and raise Invalid.
On 17 April 2018 at 23:49, Richard Henderson
wrote:
> On 04/17/2018 12:38 PM, Emilio G. Cota wrote:
>> On Tue, Apr 17, 2018 at 22:45:51 +0100, Peter Maydell wrote:
>>> On 17 April 2018 at 22:27, Emilio G. Cota wrote:
(...)
+cff 0xffb0, expected: 0x7ff8, returned:
0
On 04/17/2018 12:38 PM, Emilio G. Cota wrote:
> On Tue, Apr 17, 2018 at 22:45:51 +0100, Peter Maydell wrote:
>> On 17 April 2018 at 22:27, Emilio G. Cota wrote:
>>> BTW I just checked with -t host on an IBM Power8, and we get
>>> the same 1049 flag errors we get with -t soft plus two additional on
On Tue, Apr 17, 2018 at 22:45:51 +0100, Peter Maydell wrote:
> On 17 April 2018 at 22:27, Emilio G. Cota wrote:
> > BTW I just checked with -t host on an IBM Power8, and we get
> > the same 1049 flag errors we get with -t soft plus two additional ones:
> >
> > +A 0xffb0, expected: 0x7fa0,
On 17 April 2018 at 22:27, Emilio G. Cota wrote:
> BTW I just checked with -t host on an IBM Power8, and we get
> the same 1049 flag errors we get with -t soft plus two additional ones:
>
> +A 0xffb0, expected: 0x7fa0, returned: 0x7fa0, \
> expected exceptions: i, returned: none
> +e
On Tue, Apr 17, 2018 at 21:54:03 +0100, Peter Maydell wrote:
> On 17 April 2018 at 20:04, Emilio G. Cota wrote:
> > Note that in fp-test I am not checking for flags that are raised
> > when none are expected, because doing so gives quite a few errors.
> > Just noticed that enabling this check yiel
On 17 April 2018 at 20:04, Emilio G. Cota wrote:
> Note that in fp-test I am not checking for flags that are raised
> when none are expected, because doing so gives quite a few errors.
> Just noticed that enabling this check yields 1049 of these errors for
> v2.11, and before this patch that numbe
On Mon, Apr 16, 2018 at 14:54:42 +0100, Alex Bennée wrote:
> The re-factoring of div_floats changed the order of checking meaning
> an operation like -inf/0 erroneously raises the divbyzero flag.
> IEEE-754 (2008) specifies this should only occur for operations on
> finite operands.
>
> We fix thi
On 16 April 2018 at 14:54, Alex Bennée wrote:
> The re-factoring of div_floats changed the order of checking meaning
> an operation like -inf/0 erroneously raises the divbyzero flag.
> IEEE-754 (2008) specifies this should only occur for operations on
> finite operands.
>
> We fix this by moving t
On 16 April 2018 at 20:39, Richard Henderson
wrote:
> On 04/16/2018 03:54 AM, Alex Bennée wrote:
>> +/* Inf / x or 0 / x */
>> +if (a.cls == float_class_inf || a.cls == float_class_zero) {
>> +a.sign = sign;
>> +return a;
>> +}
>
> 0/0 should raise an exception.
It doe
On 04/16/2018 03:54 AM, Alex Bennée wrote:
> +/* Inf / x or 0 / x */
> +if (a.cls == float_class_inf || a.cls == float_class_zero) {
> +a.sign = sign;
> +return a;
> +}
0/0 should raise an exception.
I find inf/0 non-intuitive, but there ya go.
r~
On 16 April 2018 at 15:42, Alex Bennée wrote:
>
> Bastian Koppelmann writes:
>
>> On 04/16/2018 03:54 PM, Alex Bennée wrote:
>>> The re-factoring of div_floats changed the order of checking meaning
>>> an operation like -inf/0 erroneously raises the divbyzero flag.
>>> IEEE-754 (2008) specifies t
Bastian Koppelmann writes:
> On 04/16/2018 03:54 PM, Alex Bennée wrote:
>> The re-factoring of div_floats changed the order of checking meaning
>> an operation like -inf/0 erroneously raises the divbyzero flag.
>> IEEE-754 (2008) specifies this should only occur for operations on
>> finite opera
On 04/16/2018 03:54 PM, Alex Bennée wrote:
> The re-factoring of div_floats changed the order of checking meaning
> an operation like -inf/0 erroneously raises the divbyzero flag.
> IEEE-754 (2008) specifies this should only occur for operations on
> finite operands.
>
> We fix this by moving the
18 matches
Mail list logo
