[Bug testsuite/109145] New: new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[Bug testsuite/109145] New: new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[seurer at gcc dot gnu.org]

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

            Bug ID: 109145
           Summary: new test case gcc.dg/tree-ssa/forwprop-39.c from
                    r13-6624-geb337d28c32b1b fails
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:eb337d28c32b1b460cc85b3c00f8418ca535c77b, r13-6624-geb337d28c32b1b

I am seeing this failing only on our older power 7 machines.

make  -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/forwprop-39.c"
FAIL: gcc.dg/tree-ssa/forwprop-39.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/forwprop-39.c scan-tree-dump-not forwprop1 "COMPLEX_EXPR"
FAIL: gcc.dg/tree-ssa/forwprop-39.c scan-tree-dump-not optimized
"REALPART_EXPR"
# of unexpected failures        3

commit eb337d28c32b1b460cc85b3c00f8418ca535c77b
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Mar 7 11:04:55 2023 +0100

    tree-optimization/109046 - re-combine complex loads

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |testsuite-fail
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-03-15

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Humm, argument passing oddity?  Or probably "old" glibc complex.h header not
using __builtin_complex for CMPLXF (...)?  It seems to pass for me with a
cross and using native x86-64 complex.h headers ...

My complex.h has

#if defined __USE_ISOC11 && __GNUC_PREREQ (4, 7)
/* Macros to expand into expression of specified complex type.  */
# define CMPLX(x, y) __builtin_complex ((double) (x), (double) (y))
# define CMPLXF(x, y) __builtin_complex ((float) (x), (float) (y))
# define CMPLXL(x, y) __builtin_complex ((long double) (x), (long double) (y))
#endif 

can you have a look or at least attach preprocessed source?  Can you
check if changing the testcase to use __builtin_complex (..) fixes it?

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
I am updating some tools on the system and will try again.

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hp at gcc dot gnu.org

--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Same for cris-elf (latest at r13-6712-gbd2d206b7b7d) and apparently pru-elf
(r13-6705-gaf4f6816660293) according to
https://gcc.gnu.org/pipermail/gcc-testresults/2023-March/779696.html

There's an "excess error" due to a missing definition or declaration of CMPLXF.
 The newlib complex.h doesn't have CMPLXF.

I intend to add a "! target newlib" (sp?) but maybe you guys are working on
another solution.

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
Created attachment 54684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54684&action=edit
Preprocessed file

Attached file from this command

/home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c
-fdiagnostics-plain-output -std=c11 -O2 -fdump-tree-forwprop1
-fdump-tree-optimized -E -o forwprop-39.i

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[seurer at gcc dot gnu.org]

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

--- Comment #5 from seurer at gcc dot gnu.org ---
The excess error is:

/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c: In
function 'foo':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c:11:13:
warning: implicit declaration of function 'CMPLXF'
[-Wimplicit-function-declaration]

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Those macros have been only introduced in glibc in 2012:
https://sourceware.org/bugzilla/show_bug.cgi?id=13530
Bill, do you have glibc older than 2.16?

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I think we can either use:
2023-03-16  Jakub Jelinek  <jakub@redhat.com>

        PR testsuite/109145
        * gcc.dg/tree-ssa/forwprop-39.c (CMPLXF): Define if not defined.

--- gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c.jj      2023-03-13
10:18:59.545433477 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c 2023-03-16 18:48:04.408908088
+0100
@@ -3,6 +3,10 @@

 #include <complex.h>

+#ifndef CMPLXF
+#define CMPLXF(x, y) __builtin_complex (x, y)
+#endif
+
 extern void push1(void *p, float _Complex x);
 void foo (void *q, float _Complex *x)
 {
or
2023-03-16  Jakub Jelinek  <jakub@redhat.com>

        PR testsuite/109145
        * gcc.dg/tree-ssa/forwprop-39.c: Don't include complex.h.
        (foo): Use __builtin_complex rather than CMPLXF.

--- gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c.jj      2023-03-13
10:18:59.545433477 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c 2023-03-16 18:49:40.563504504
+0100
@@ -1,14 +1,12 @@
 /* { dg-do compile } */
 /* { dg-options "-std=c11 -O2 -fdump-tree-forwprop1 -fdump-tree-optimized" }
*/

-#include <complex.h>
-
 extern void push1(void *p, float _Complex x);
 void foo (void *q, float _Complex *x)
 {
   float r = __real *x;
   float i = __imag *x;
-  push1 (q, CMPLXF (r, i));
+  push1 (q, __builtin_complex (r, i));
 }

 /* { dg-final { scan-tree-dump-not "COMPLEX_EXPR" "forwprop1" } } */

I think my preference would be the latter...

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[seurer at gcc dot gnu.org]

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

--- Comment #8 from seurer at gcc dot gnu.org ---
Alas, yes.  This system is quite old and not being updated any more.  It
hopefully will be retired soon.

This probably isn't a big deal and as far as I am concerned can be ignored.

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to seurer from comment #8)
> Alas, yes.  This system is quite old and not being updated any more.  It
> hopefully will be retired soon.
> 
> This probably isn't a big deal and as far as I am concerned can be ignored.

The patch is still most likely needed for newlib targets as newlib's complex.h
does not define CMPLXF .

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> So, I think we can either use:
> 2023-03-16  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR testsuite/109145
> 	* gcc.dg/tree-ssa/forwprop-39.c (CMPLXF): Define if not defined.
> 
> --- gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c.jj	2023-03-13
> 10:18:59.545433477 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c	2023-03-16
> 18:48:04.408908088 +0100
> @@ -3,6 +3,10 @@
>  
>  #include <complex.h>
>  
> +#ifndef CMPLXF
> +#define CMPLXF(x, y) __builtin_complex (x, y)
> +#endif
> +
>  extern void push1(void *p, float _Complex x);
>  void foo (void *q, float _Complex *x)
>  {
> or
> 2023-03-16  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR testsuite/109145
> 	* gcc.dg/tree-ssa/forwprop-39.c: Don't include complex.h.
> 	(foo): Use __builtin_complex rather than CMPLXF.
> 
> --- gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c.jj	2023-03-13
> 10:18:59.545433477 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c	2023-03-16
> 18:49:40.563504504 +0100
> @@ -1,14 +1,12 @@
>  /* { dg-do compile } */
>  /* { dg-options "-std=c11 -O2 -fdump-tree-forwprop1 -fdump-tree-optimized"
> } */
>  
> -#include <complex.h>
> -
>  extern void push1(void *p, float _Complex x);
>  void foo (void *q, float _Complex *x)
>  {
>    float r = __real *x;
>    float i = __imag *x;
> -  push1 (q, CMPLXF (r, i));
> +  push1 (q, __builtin_complex (r, i));
>  }
>  
>  /* { dg-final { scan-tree-dump-not "COMPLEX_EXPR" "forwprop1" } } */
> 
> I think my preference would be the latter...

Yes, can you push that please?  Then also the -std=c11 is no longer necessary.

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 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:2bb71424636fba7944b36b1689e9df22a53f1a3f

commit r13-6732-g2bb71424636fba7944b36b1689e9df22a53f1a3f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 17 09:58:08 2023 +0100

    testsuite: Fix up forwprop-39.c testcase [PR109145]

    As written in the PR, newlib headers aren't C11 compliant in that they
    don't define CMPLXF macro, and glibc before 2.16 doesn't define that
    either.  I think it is easier to use __builtin_complex directly, over
    another patch which keeps including complex.h but defines CMPLXF if it
    isn't defined, we want to test how forwprop behaves rather than what
    complex.h defines or doesn't define.

    2023-03-17  Jakub Jelinek  <jakub@redhat.com>

            PR testsuite/109145
            * gcc.dg/tree-ssa/forwprop-39.c: Remove -std=c11 from dg-options.
            Don't include complex.h.
            (foo): Use __builtin_complex rather than CMPLXF.