[Bug c/102498] New: wrong output of printf with long double constant and non-default rounding mode

[Bug c/102498] New: wrong output of printf with long double constant and non-default rounding mode

[zimmerma+gcc at loria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

            Bug ID: 102498
           Summary: wrong output of printf with long double constant and
                    non-default rounding mode
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zimmerma+gcc at loria dot fr
  Target Milestone: ---

with the following program:

#include <stdio.h>
#include <math.h>
#include <fenv.h>
const long double a = 0xc.90fdaa22168c235p-1l;
const long double b = 0xc.90fdaa22168c235p-2l;
int main()
{
  fesetround (FE_TONEAREST);
  printf ("FE_TONEAREST:  a=%La b=%La\n", a, b);
  fesetround (FE_TOWARDZERO);
  printf ("FE_TOWARDZERO: a=%La b=%La\n", a, b);
  fesetround (FE_UPWARD);
  printf ("FE_UPWARD:     a=%La b=%La\n", a, b);
  fesetround (FE_DOWNWARD);
  printf ("FE_DOWNWARD:   a=%La b=%La\n", a, b);
}

I get:

$ gcc -frounding-math -O0 -fno-builtin e.c -lm
$ ./a.out 
FE_TONEAREST:  a=0xc.90fdaa22168c235p-1 b=0xc.90fdaa22168c235p-2
FE_TOWARDZERO: a=0xc.90fdaa22168c235p-1 b=0xc.90fdaa22168c234p-2
FE_UPWARD:     a=0xc.90fdaa22168c235p-1 b=0xc.90fdaa22168c235p-2
FE_DOWNWARD:   a=0xc.90fdaa22168c235p-1 b=0xc.90fdaa22168c234p-2

The value 'a' is printed the same whatever the rounding mode, but 'b' (which
approximates pi to nearest) is wrongly printed for FE_TOWARDZERO and
FE_DOWNWARD.

According to Alexander Monakov, the same problem should happen with og_2 10,
log_2 e, log_10 2, and log_e 2, see
https://sourceware.org/pipermail/libc-alpha/2021-September/131411.html

[Bug c/102498] wrong output of printf with long double constant (pi) and non-default rounding mode

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #1 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
A testcase without printf:

#include <fenv.h>

#define X 0xc.90fdaa22168c235p-2l
#define Y 0xc.90fdaa22168c234p-2l

int main (void)
{
  volatile long double x, y;

  fesetround (FE_TOWARDZERO);
  x = X;
  y = Y;
  return x - y == ((X) - (Y)) ? 0 : 1;
}

GCC returns 1 instead of 0.

[Bug target/102498] wrong output of printf with long double constant (pi) and non-default rounding mode

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
          Component|c                           |target
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-09-27
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

[Bug target/102498] wrong output of printf with long double constant (pi) and non-default rounding mode

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51512&action=edit
gcc12-pr102498.patch

Untested fix.  4 of the 5 constants misbehave with -frounding-math in
FE_TOWARDZERO and FE_DOWNWARD modes, one misbehaves in FE_UPWARD mode.

[Bug target/102498] wrong output of printf with long double constant (pi) and non-default rounding mode

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #3 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 51512 [details]
> gcc12-pr102498.patch

I could test that this fixes the issue on my testcase at Comment 1.

[Bug target/102498] [9/10/11/12 Regression] Long double constant and non-default rounding mode on x86

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |3.2
            Summary|Long double constant and    |[9/10/11/12 Regression]
                   |non-default rounding mode   |Long double constant and
                   |on x86                      |non-default rounding mode
                   |                            |on x86
   Target Milestone|---                         |9.5
      Known to fail|                            |3.3

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
A regression since GCC 3.2 (r0-47863-g881b2a9652748ad).

[Bug target/102498] [9/10/11/12 Regression] Long double constant and non-default rounding mode on x86

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #5 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Andrew Pinski from comment #4)
> A regression since GCC 3.2 (r0-47863-g881b2a9652748ad).

Always reproducible with GCC 5. But with GCC 4.7 to 4.9, it seems that one
needs -O1 to get fldpi generated. I can't reproduce the bug with GCC 4.1.2 to
4.6.4 on godbolt (even with -O3).

[Bug target/102498] [9/10/11/12 Regression] Long double constant and non-default rounding mode on x86

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > A regression since GCC 3.2 (r0-47863-g881b2a9652748ad).
> 
> Always reproducible with GCC 5. But with GCC 4.7 to 4.9, it seems that one
> needs -O1 to get fldpi generated. I can't reproduce the bug with GCC 4.1.2
> to 4.6.4 on godbolt (even with -O3).

Here is a testcase which shows it can be reproduced all the back to GCC 4.1.2
even:

#include <fenv.h>

#define X 0xc.90fdaa22168c235p-2l
#define Y 0xc.90fdaa22168c234p-2l
__attribute__((noinline))
void g(long double x){}
__attribute((noinline))
int f(long double z)
{
  volatile long double x, y;

  fesetround (FE_TOWARDZERO);
  x = X + z;
  g(x);
  y = Y + z;
  return x - y == ((X) - (Y)) ? 0 : 1;
}


int main (void)
{
    f(0);
}

[Bug target/102498] [9/10/11/12 Regression] Long double constant and non-default rounding mode on x86

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #7 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Andrew Pinski from comment #6)
> Here is a testcase which shows it can be reproduced all the back to GCC
> 4.1.2 even:
[...]
>     f(0);
> }

OK, with "return" before "f(0);".

[Bug target/102498] [9/10/11/12 Regression] Long double constant and non-default rounding mode on x86

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:3b7041e8345c2f1030e58620f28e22d64b2c196b

commit r12-3920-g3b7041e8345c2f1030e58620f28e22d64b2c196b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Sep 28 13:02:51 2021 +0200

    i386: Don't emit fldpi etc. if -frounding-math [PR102498]

    i387 has instructions to store some transcedental numbers into the top of
    stack.  The problem is that what exact bit in the last place one gets for
    those depends on the current rounding mode, the CPU knows the number with
    slightly higher precision.  The compiler assumes rounding to nearest when
    comparing them against constants in the IL, but at runtime the rounding
    can be different and so some of these depending on rounding mode and the
    constant could be 1 ulp higher or smaller than expected.
    We only support changing the rounding mode at runtime if the non-default
    -frounding-mode option is used, so the following patch just disables
    using those constants if that flag is on.

    2021-09-28  Jakub Jelinek  <jakub@redhat.com>

            PR target/102498
            * config/i386/i386.c (standard_80387_constant_p): Don't recognize
            special 80387 instruction XFmode constants if flag_rounding_math.

            * gcc.target/i386/pr102498.c: New test.

[Bug target/102498] [9/10/11/12 Regression] Long double constant and non-default rounding mode on x86

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:6de756d7a7a72ad67eaba33e6102c2e4874bf6e6

commit r11-9035-g6de756d7a7a72ad67eaba33e6102c2e4874bf6e6
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Sep 28 13:02:51 2021 +0200

    i386: Don't emit fldpi etc. if -frounding-math [PR102498]

    i387 has instructions to store some transcedental numbers into the top of
    stack.  The problem is that what exact bit in the last place one gets for
    those depends on the current rounding mode, the CPU knows the number with
    slightly higher precision.  The compiler assumes rounding to nearest when
    comparing them against constants in the IL, but at runtime the rounding
    can be different and so some of these depending on rounding mode and the
    constant could be 1 ulp higher or smaller than expected.
    We only support changing the rounding mode at runtime if the non-default
    -frounding-mode option is used, so the following patch just disables
    using those constants if that flag is on.

    2021-09-28  Jakub Jelinek  <jakub@redhat.com>

            PR target/102498
            * config/i386/i386.c (standard_80387_constant_p): Don't recognize
            special 80387 instruction XFmode constants if flag_rounding_math.

            * gcc.target/i386/pr102498.c: New test.

    (cherry picked from commit 3b7041e8345c2f1030e58620f28e22d64b2c196b)

[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11/12 Regression]     |[9/10 Regression] Long
                   |Long double constant and    |double constant and
                   |non-default rounding mode   |non-default rounding mode
                   |on x86                      |on x86

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.3+/12.1+ so far.

[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:0dcd7625b03a1bd5be927a4ade1ddf240587fc08

commit r10-10645-g0dcd7625b03a1bd5be927a4ade1ddf240587fc08
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Sep 28 13:02:51 2021 +0200

    i386: Don't emit fldpi etc. if -frounding-math [PR102498]

    i387 has instructions to store some transcedental numbers into the top of
    stack.  The problem is that what exact bit in the last place one gets for
    those depends on the current rounding mode, the CPU knows the number with
    slightly higher precision.  The compiler assumes rounding to nearest when
    comparing them against constants in the IL, but at runtime the rounding
    can be different and so some of these depending on rounding mode and the
    constant could be 1 ulp higher or smaller than expected.
    We only support changing the rounding mode at runtime if the non-default
    -frounding-mode option is used, so the following patch just disables
    using those constants if that flag is on.

    2021-09-28  Jakub Jelinek  <jakub@redhat.com>

            PR target/102498
            * config/i386/i386.c (standard_80387_constant_p): Don't recognize
            special 80387 instruction XFmode constants if flag_rounding_math.

            * gcc.target/i386/pr102498.c: New test.

    (cherry picked from commit 3b7041e8345c2f1030e58620f28e22d64b2c196b)

[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86

[zimmerma+gcc at loria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #12 from Paul Zimmermann <zimmerma+gcc at loria dot fr> ---
I confirm this is fixed with gcc version 11.3.0 (Debian 11.3.0-1).

[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #13 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
Strange. I still get this bug with gcc-11 (Debian 11.3.0-1) 11.3.0.

[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #14 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
Sorry, I wasn't using -frounding-math (which matters to have the optimization
disabled).

[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:8837138d292eb4221a5d5a985d25e487a127539d

commit r9-10102-g8837138d292eb4221a5d5a985d25e487a127539d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Sep 28 13:02:51 2021 +0200

    i386: Don't emit fldpi etc. if -frounding-math [PR102498]

    i387 has instructions to store some transcedental numbers into the top of
    stack.  The problem is that what exact bit in the last place one gets for
    those depends on the current rounding mode, the CPU knows the number with
    slightly higher precision.  The compiler assumes rounding to nearest when
    comparing them against constants in the IL, but at runtime the rounding
    can be different and so some of these depending on rounding mode and the
    constant could be 1 ulp higher or smaller than expected.
    We only support changing the rounding mode at runtime if the non-default
    -frounding-mode option is used, so the following patch just disables
    using those constants if that flag is on.

    2021-09-28  Jakub Jelinek  <jakub@redhat.com>

            PR target/102498
            * config/i386/i386.c (standard_80387_constant_p): Don't recognize
            special 80387 instruction XFmode constants if flag_rounding_math.

            * gcc.target/i386/pr102498.c: New test.

    (cherry picked from commit 3b7041e8345c2f1030e58620f28e22d64b2c196b)

[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.