Launchpad has imported 9 comments from the remote bug at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://documentation.ubuntu.com/launchpad/user/reference/bugs/multi-project-bugs/about-multi-project-bugs/#bugs-in-external-trackers.

------------------------------------------------------------------------
On 2025-01-18T05:00:20+00:00 Jeevitha-7 wrote:

Gcc trunk generates xscmpgtdp for Unordered Operations. This issue was
from power9/power10 with O2

jeevitha@ltcd97-lp3:~$ cat bug.c
extern double __ieee754_acos (double);
double
__acospi (double x)
{
 
  double ret = __ieee754_acos (x) / 3.14;


  return __builtin_isgreater(ret, 1.0) ? 1.0 : ret;
}
jeevitha@ltcd97-lp3:~$ gcc bug.c  -O2 -mcpu=power9 -S -o bug.s
jeevitha@ltcd97-lp3:~$ cat bug.s
        .file   "bug.c"
        .machine power9
        .machine altivec
        .abiversion 2
        .section        ".text"
        .align 2
        .p2align 4,,15
        .globl __acospi
        .type   __acospi, @function
__acospi:
.LFB0:
        .cfi_startproc
.LCF0:
0:      addis 2,12,.TOC.-.LCF0@ha
        addi 2,2,.TOC.-.LCF0@l
        .localentry     __acospi,.-__acospi
        mflr 0
        std 0,16(1)
        stdu 1,-32(1)
        .cfi_def_cfa_offset 32
        .cfi_offset 65, 16
        bl __ieee754_acos
        nop
        addis 9,2,.LC2@toc@ha
        addi 1,1,32
        .cfi_def_cfa_offset 0
        lfd 0,.LC2@toc@l(9)
        addis 9,2,.LC0@toc@ha
        ld 0,16(1)
        lfd 12,.LC0@toc@l(9)
        fdiv 0,1,0
        mtlr 0
        .cfi_restore 65
        xscmpgtdp 1,0,12
        xxsel 1,0,12,1
        blr

Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2098505/comments/0

------------------------------------------------------------------------
On 2025-01-18T05:07:10+00:00 Jeevitha-7 wrote:

This issue arises from a glibc math function. Below is the discussion
from the glibc mailing list conversation between Florian and Adhemerval.

I saw this when building for POWER10 and it seems a compiler issue to me,
where gcc generates:

   0x00007ffff7eb0280 <+64>:    fdiv    f0,f1,f0
   0x00007ffff7eb0284 <+68>:    mtlr    r0
=> 0x00007ffff7eb0288 <+72>:    xscmpgtdp vs1,vs0,vs31
   0x00007ffff7eb028c <+76>:    xxsel   vs1,vs0,vs31,vs1

For

  FLOAT ret = M_SUF (__ieee754_acos) (x) / M_MLIT (M_PI);
  /* Ensure that rounding upward for both acos and the division cannot
     yield a return value from acospi greater than 1.  */
  return isgreater (ret, M_LIT (1.0)) ? M_LIT (1.0) : ret;

I don't think compiler is allowed to transform this expression to
xscmpgtdp for unordered operations.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2098505/comments/1

------------------------------------------------------------------------
On 2025-01-18T09:34:14+00:00 Fw-6 wrote:

This is about these glibc test suite failures, right?

FAIL: math/test-double-acospi
FAIL: math/test-float-acospi
FAIL: math/test-float32-acospi
FAIL: math/test-float32x-acospi
FAIL: math/test-float64-acospi

I see those with GCC 11.5. The detailed test output looks like this:

testing double (without inline functions)
Failure: acospi (qNaN): Exception "Invalid operation" set
Failure: acospi (-qNaN): Exception "Invalid operation" set
Failure: acospi_downward (qNaN): Exception "Invalid operation" set
Failure: acospi_downward (-qNaN): Exception "Invalid operation" set
Failure: acospi_towardzero (qNaN): Exception "Invalid operation" set
Failure: acospi_towardzero (-qNaN): Exception "Invalid operation" set
Failure: acospi_upward (qNaN): Exception "Invalid operation" set
Failure: acospi_upward (-qNaN): Exception "Invalid operation" set

Test suite completed:
  4 max error test cases,
  444 input tests,
  - with 1784 tests for exception flags,
  - with 436 tests for errno executed.
  8 errors occurred.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2098505/comments/2

------------------------------------------------------------------------
On 2025-01-18T12:52:12+00:00 Jeevitha-7 wrote:

(In reply to Florian Weimer from comment #2)
> This is about these glibc test suite failures, right?
> 
Yes

Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2098505/comments/3

------------------------------------------------------------------------
On 2025-01-27T22:50:08+00:00 Meissner-gcc wrote:

I have a patch for this, and I'm testing it right now.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2098505/comments/4

------------------------------------------------------------------------
On 2025-03-24T19:58:15+00:00 Meissner-gcc wrote:

I submitted the patch for this on February 12th, 2025:
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675616.html

Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2098505/comments/9

------------------------------------------------------------------------
On 2025-03-27T01:57:51+00:00 Meissner-gcc wrote:

I submitted V4 of the patch on March 26th:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679428.html

Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2098505/comments/10

------------------------------------------------------------------------
On 2025-04-10T21:28:42+00:00 Segher-8 wrote:

isgreater is not supposed to set floating point exception flags at all.
So whether the comparison resulted in unordered (i.e., one of the
arguments was a NaN) or not, isgreater should not set VXVC in particular
("invalid compare").

So xscmp<somefpcomparecomdition>dp are wrong to use here, as is xscmpodp.  
xscmpudp
is fine, as are the traditional fp comparisons.

No changes except not creating the wrong instructions are wanted, or needed, or
correct at all.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2098505/comments/11

------------------------------------------------------------------------
On 2025-04-11T10:50:20+00:00 Segher-8 wrote:

(The traditional FP comparisons we do use, i.e. fcmpu.  We never used fcmpo,
because it is problematic, it needs access to information that in not in the
RTL at the point of the comparison, that information exists only at the point
the comparison result is used, currently.  This needs working on, but so far
everything possible has been shot down.)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2098505/comments/12


** Changed in: gcc
       Status: Unknown => In Progress

** Changed in: gcc
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2098505

Title:
  glibc 2.41 ppc64el: math test failures

To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/2098505/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to