Strange expl results

Strange expl results

[Alex Markin]

Hello.

I don't know if it is a gcc or binutils problem. I have different results
for `expl' function depending on the argument was variable or literal:

long double c, r1, r2;
r1 = expl(-1);

c = -1;
r2 = expl(c);

In this example r1 and r2 differ in the lower bits. The entire example is
here: https://godbolt.org/z/xqn4bd. The llvm does not have such a problem.

Kind regards,
Aleksey Markin

Re: Strange expl results

[Stefan Ring]

On Thu, Nov 26, 2020 at 9:21 PM Alex Markin via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> Hello.
>
> I don't know if it is a gcc or binutils problem. I have different results
> for `expl' function depending on the argument was variable or literal:
>
> long double c, r1, r2;
> r1 = expl(-1);
>
> c = -1;
> r2 = expl(c);
>
> In this example r1 and r2 differ in the lower bits. The entire example is
> here: https://godbolt.org/z/xqn4bd. The llvm does not have such a problem.

The reason is that the Intel-specific 80 bit long double format is
used. So the first 80 bits of r1 and r2 contain the value, and the
rest remains uninitialized. You could memset both to 0 first, then the
comparison would check out. I'm sure there is a good reason for sizeof
producing 16, not 10.

Re: Strange expl results

[Stefan Ring]

On Thu, Nov 26, 2020 at 11:27 PM Alex Markin <alexanius@gmail.com> wrote:
>
> memset will not help here.

True, but only because it is optimized away! :D

Re: Strange expl results

[Alex Markin]

The value bits differ, memset will not help here. You can watch the values
in the gdb:

(gdb) n
43          printBits(sizeof(r1), &r1);
(gdb) info locals
c = -1
r1 = 0.36787944117144232158305751367866065
r2 = 0.36787944117144232161016256799079827

пт, 27 нояб. 2020 г. в 00:54, Stefan Ring <stefanrin@gmail.com>:

> On Thu, Nov 26, 2020 at 9:21 PM Alex Markin via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> >
> > Hello.
> >
> > I don't know if it is a gcc or binutils problem. I have different results
> > for `expl' function depending on the argument was variable or literal:
> >
> > long double c, r1, r2;
> > r1 = expl(-1);
> >
> > c = -1;
> > r2 = expl(c);
> >
> > In this example r1 and r2 differ in the lower bits. The entire example is
> > here: https://godbolt.org/z/xqn4bd. The llvm does not have such a
> problem.
>
> The reason is that the Intel-specific 80 bit long double format is
> used. So the first 80 bits of r1 and r2 contain the value, and the
> rest remains uninitialized. You could memset both to 0 first, then the
> comparison would check out. I'm sure there is a good reason for sizeof
> producing 16, not 10.
>

Re: Strange expl results

[Stefan Ring]

On Thu, Nov 26, 2020 at 11:46 PM Stefan Ring <stefanrin@gmail.com> wrote:
>
> On Thu, Nov 26, 2020 at 11:27 PM Alex Markin <alexanius@gmail.com> wrote:
> >
> > memset will not help here.
>
> True, but only because it is optimized away! :D

With -O2, the compiler pre-computes both of them at compile time, and
they are both the same (but the upper 6 bytes stay uninitialized, even
with memset).

With -O0, the compiler pre-computes the first one and calls the
library function for the second result, which produces a different
result that differs in the last bit.

Which is slightly surprising, but nothing that I lose sleep over...

Re: Strange expl results

[Florian Weimer]

* Alex Markin via Gcc-help:

> The problem starts when you have a cross-platform project where on
> the second platform we have a non-gcc compiler and 80-bit float
> calculations on non-intel hardware.

What platform is this?  m68k?

Very few platforms have 80 bit long double.

Re: Strange expl results

[Alex Markin]

The problem starts when you have a cross-platform project where on the
second
platform we have a non-gcc compiler and 80-bit float calculations on
non-intel hardware.
That is my case where on the second platform expl calculates in the right
way
and after a sequence of evaluations we get a big error accumulation and the
program
behaviour becomes different.

To my pity I can not find an example on any widespread platform to show the
different
behaviour of expl, so that seems to stay here for a long time.

пт, 27 нояб. 2020 г. в 10:54, Stefan Ring <stefanrin@gmail.com>:

> On Thu, Nov 26, 2020 at 11:46 PM Stefan Ring <stefanrin@gmail.com> wrote:
> >
> > On Thu, Nov 26, 2020 at 11:27 PM Alex Markin <alexanius@gmail.com>
> wrote:
> > >
> > > memset will not help here.
> >
> > True, but only because it is optimized away! :D
>
> With -O2, the compiler pre-computes both of them at compile time, and
> they are both the same (but the upper 6 bytes stay uninitialized, even
> with memset).
>
> With -O0, the compiler pre-computes the first one and calls the
> library function for the second result, which produces a different
> result that differs in the last bit.
>
> Which is slightly surprising, but nothing that I lose sleep over...
>

Re: Strange expl results

[Alex Markin]

> What platform is this?

The e2k system https://en.wikipedia.org/wiki/Elbrus_2000

вс, 29 нояб. 2020 г. в 18:07, Florian Weimer <fw@deneb.enyo.de>:

> * Alex Markin via Gcc-help:
>
> > The problem starts when you have a cross-platform project where on
> > the second platform we have a non-gcc compiler and 80-bit float
> > calculations on non-intel hardware.
>
> What platform is this?  m68k?
>
> Very few platforms have 80 bit long double.
>

Re: Strange expl results

[Vincent Lefevre]

On 2020-11-29 19:14:37 +0300, Alex Markin via Gcc-help wrote:
> The problem starts when you have a cross-platform project where on
> the second platform we have a non-gcc compiler and 80-bit float
> calculations on non-intel hardware. That is my case where on the
> second platform expl calculates in the right way and after a
> sequence of evaluations we get a big error accumulation and the
> program behaviour becomes different.

This is not specific to the 80-bit extended precision. Any FP format
may be affected. When the argument is known at compile time, GCC can
optimize and it normally uses GNU MPFR to compute the result with
correct rounding (which is the best possible result and the only
good way to specify the result completely). This means that if the
library does not provide correct rounding, you will get differences
with results computed at compile time (and differences with other
libraries, possibly across different versions of the same library).
You can see a summary of differences between libraries for the
double type (double precision, or binary64) and various functions:

  https://www.vinc17.net/research/testlibm/

These are tests on values that are difficult to round due to the
"Table maker's dilemma". As you can see, for a long time, glibc
was implementing correct rounding for exp and log in particular
(my tests started with glibc 2.2.5, on spe170 in the table), thus
with no differences compared to the compile-time result with GCC
(using MPFR); but this is no longer the case (e.g. with glibc 2.28,
on joooj in the table). This changed in 2018:

commit de800d83059dbedb7d151580f0a3bdc9eaf37340
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date:   2018-01-30 15:48:22 +0100

    Remove slow paths from exp

commit b7c83ca30ef8e85b6642151d95600a36535f8d97
Author: Wilco Dijkstra <wdijkstr@arm.com>
Date:   2018-02-07 13:24:43 +0100

    Remove slow paths from log

(BTW, reducing the precision of the slow path may have been a better
compromise, with no differences on the results, at least on exp and
log, as I say in the slides mentioned below.)

On https://www.vinc17.net/research/slides/sieste2010.pdf slides 11 to 17
you can see various differences obtained with GCC involving a same
expression.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Strange expl results

[Alex Markin]

Thank you and everyone for the explanation!
I'll fix this on my side with extra rounding of the result inside my
project.

пн, 30 нояб. 2020 г. в 12:48, Vincent Lefevre <vincent+gcc@vinc17.org>:

> On 2020-11-29 19:14:37 +0300, Alex Markin via Gcc-help wrote:
> > The problem starts when you have a cross-platform project where on
> > the second platform we have a non-gcc compiler and 80-bit float
> > calculations on non-intel hardware. That is my case where on the
> > second platform expl calculates in the right way and after a
> > sequence of evaluations we get a big error accumulation and the
> > program behaviour becomes different.
>
> This is not specific to the 80-bit extended precision. Any FP format
> may be affected. When the argument is known at compile time, GCC can
> optimize and it normally uses GNU MPFR to compute the result with
> correct rounding (which is the best possible result and the only
> good way to specify the result completely). This means that if the
> library does not provide correct rounding, you will get differences
> with results computed at compile time (and differences with other
> libraries, possibly across different versions of the same library).
> You can see a summary of differences between libraries for the
> double type (double precision, or binary64) and various functions:
>
>   https://www.vinc17.net/research/testlibm/
>
> These are tests on values that are difficult to round due to the
> "Table maker's dilemma". As you can see, for a long time, glibc
> was implementing correct rounding for exp and log in particular
> (my tests started with glibc 2.2.5, on spe170 in the table), thus
> with no differences compared to the compile-time result with GCC
> (using MPFR); but this is no longer the case (e.g. with glibc 2.28,
> on joooj in the table). This changed in 2018:
>
> commit de800d83059dbedb7d151580f0a3bdc9eaf37340
> Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Date:   2018-01-30 15:48:22 +0100
>
>     Remove slow paths from exp
>
> commit b7c83ca30ef8e85b6642151d95600a36535f8d97
> Author: Wilco Dijkstra <wdijkstr@arm.com>
> Date:   2018-02-07 13:24:43 +0100
>
>     Remove slow paths from log
>
> (BTW, reducing the precision of the slow path may have been a better
> compromise, with no differences on the results, at least on exp and
> log, as I say in the slides mentioned below.)
>
> On https://www.vinc17.net/research/slides/sieste2010.pdf slides 11 to 17
> you can see various differences obtained with GCC involving a same
> expression.
>
> --
> Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>