Bug 110371 - [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007
Summary: [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr510...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 14.0
: P3 normal
Target Milestone: 14.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-checking, ice-on-valid-code, testsuite-fail
: 110412 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-06-22 20:27 UTC by Thiago Jung Bauermann
Modified: 2023-06-26 18:42 UTC (History)
3 users (show)

See Also:
Host:
Target: aarch64-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Output of running gfortran with -freport-bug (1.19 KB, text/plain)
2023-06-22 20:27 UTC, Thiago Jung Bauermann
Details
Dump file. (31.75 KB, text/plain)
2023-06-22 20:28 UTC, Thiago Jung Bauermann
Details
pixman-matrix.c.i (22.47 KB, text/plain)
2023-06-23 06:03 UTC, Sam James
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thiago Jung Bauermann 2023-06-22 20:27:16 UTC
Created attachment 55387 [details]
Output of running gfortran with -freport-bug

In today's trunk (tested commit 33ebb0dff9bb "configure: Implement --enable-host-bind-now") I get these new failures on aarch64-linux-gnu:

Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ...
FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times \\tfcvtzs\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times \\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times \\tfcvtzu\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times \\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times \\tscvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times \\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times \\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times \\tucvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times \\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times \\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
		=== gfortran tests ===

Running gfortran:gfortran.dg/dg.exp ...
FAIL: gfortran.dg/pr68251.f90 -O  (internal compiler error: verify_gimple failed)
FAIL: gfortran.dg/pr68251.f90 -O  (test for excess errors)

Running gfortran:gfortran.dg/vect/vect.exp ...
FAIL: gfortran.dg/vect/pr51058-2.f90 -O  (internal compiler error: verify_gimple failed)
FAIL: gfortran.dg/vect/pr51058-2.f90 -O  (test for excess errors)

Looking into this failure:

FAIL: gfortran.dg/vect/pr51058-2.f90 -O  (internal compiler error: verify_gimple failed)

The problem is:

spawn -ignore SIGHUP /home/thiago.bauermann/.cache/builds/gcc-wt-native/gcc/testsuite/gfortran/../../gfortran -B/home/thiago.bauermann/.cache/builds/gcc-wt-native/gcc/testsuite/gfortran/../../ -B/home/thiago.bauermann/.cache/builds/gcc-wt-native/aarch64-unknown-linux-gnu/./libgfortran/ /home/thiago.bauermann/src/gcc-wt/gcc/testsuite/gfortran.dg/vect/pr51058-2.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O -O2 -ftree-vectorize -fvect-cost-model=unlimited -fdump-tree-vect-details -S -o pr51058-2.s
/home/thiago.bauermann/src/gcc-wt/gcc/testsuite/gfortran.dg/vect/pr51058-2.f90:3:18: Error: invalid types in nop conversion
real(kind=8)
integer(kind=4)
vect__53.48_312 = (vector(2) real(kind=8)) vect__54.46_306;
/home/thiago.bauermann/src/gcc-wt/gcc/testsuite/gfortran.dg/vect/pr51058-2.f90:3:18: Error: invalid types in nop conversion
real(kind=8)
integer(kind=4)
vect__53.48_314 = (vector(2) real(kind=8)) vect__54.46_308;
during GIMPLE pass: vect
dump file: pr51058-2.f90.173t.vect
/home/thiago.bauermann/src/gcc-wt/gcc/testsuite/gfortran.dg/vect/pr51058-2.f90:3:18: internal compiler error: verify_gimple failed
0xf5844b verify_gimple_in_cfg(function*, bool, bool)
	/home/thiago.bauermann/src/gcc-wt/gcc/tree-cfg.cc:5646
0xde3e03 execute_function_todo
	/home/thiago.bauermann/src/gcc-wt/gcc/passes.cc:2098
0xde442f execute_todo
	/home/thiago.bauermann/src/gcc-wt/gcc/passes.cc:2152
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
compiler exited with status 1
FAIL: gfortran.dg/vect/pr51058-2.f90   -O  (internal compiler error: verify_gimple failed)

I'm attaching the output of running with -freport-bug, and also the generated dump file.

Our CI bisected the problem to commit 6f19cf752616 "Use intermiediate integer type for float_expr/fix_trunc_expr when direct optab is not existed."
And indeed, if I revert that commit from trunk, all the mentioned tests pass.
Comment 1 Thiago Jung Bauermann 2023-06-22 20:28:39 UTC
Created attachment 55388 [details]
Dump file.

This is the dump file generated by the -freport-bug run from the previous attachment.
Comment 2 Sam James 2023-06-23 06:03:39 UTC
Created attachment 55390 [details]
pixman-matrix.c.i

I think I've hit the same thing building pixman.

```
# gcc /var/tmp/portage/x11-libs/pixman-0.42.2/work/pixman-0.42.2-.arm64/./pixman/libpixman-1.so.0.42.2.p/pixman-matrix.c.i -c -O3
../pixman-0.42.2/pixman/pixman-matrix.c: In function ‘pixman_f_transform_from_pixman_transform’:
../pixman-0.42.2/pixman/pixman-matrix.c:739:1: error: invalid types in nop conversion
double
int
vect__17.229_49 = (vector(2) double) vect__16.227_44;
../pixman-0.42.2/pixman/pixman-matrix.c:739:1: error: invalid types in nop conversion
double
int
vect__17.229_51 = (vector(2) double) vect__16.228_46;
during GIMPLE pass: vect
../pixman-0.42.2/pixman/pixman-matrix.c:739:1: internal compiler error: verify_gimple failed
0xaaaabd2c01f7 verify_gimple_in_cfg(function*, bool, bool)
        /usr/src/debug/sys-devel/gcc-14.0.0.9999/gcc-14.0.0.9999/gcc/tree-cfg.cc:5646
0xaaaabd0ec22f execute_function_todo
        /usr/src/debug/sys-devel/gcc-14.0.0.9999/gcc-14.0.0.9999/gcc/passes.cc:2098
0xaaaabd0ec91f execute_todo
        /usr/src/debug/sys-devel/gcc-14.0.0.9999/gcc-14.0.0.9999/gcc/passes.cc:2152
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

I can reduce it if needed, but I assume there's no point given the testsuite already fails on it.
Comment 3 Richard Biener 2023-06-23 06:17:55 UTC
Looks like NOP_EXPR is used instead of FLOAT_EXPR?
Comment 4 Hongtao.liu 2023-06-25 01:12:33 UTC
I'll take a look.
Comment 5 Hongtao.liu 2023-06-25 02:54:39 UTC
Reproduced with

typedef struct dest
{
  double m[3][3];
} dest;

typedef struct src
{
  int m[3][3];
} src;

void
foo (dest *a, src* s)
{
  for (int i = 0; i != 3; i++)
    for (int j = 0; j != 3; j++)
      a->m[i][j] = s->m[i][j];
}


for aarch64-linux-gnu.

The problem is when there's more than 1 vop in vec_oprnds0, vec_dest will be overwrited to final vectype_out, but here it's expecting cvt_type. I'm testing below:

Staged changes
1 file changed, 10 insertions(+), 4 deletions(-)
gcc/tree-vect-stmts.cc | 14 ++++++++++----

modified   gcc/tree-vect-stmts.cc
@@ -5044,7 +5044,7 @@ vectorizable_conversion (vec_info *vinfo,
                          gimple **vec_stmt, slp_tree slp_node,
                          stmt_vector_for_cost *cost_vec)
 {
-  tree vec_dest;
+  tree vec_dest, cvt_op;
   tree scalar_dest;
   tree op0, op1 = NULL_TREE;
   loop_vec_info loop_vinfo = dyn_cast <loop_vec_info> (vinfo);
@@ -5568,6 +5568,13 @@ vectorizable_conversion (vec_info *vinfo,
     case NONE:
       vect_get_vec_defs (vinfo, stmt_info, slp_node, ncopies,
                          op0, &vec_oprnds0);
+      /* vec_dest is intermediate type operand when multi_step_cvt.  */
+      if (multi_step_cvt)
+        {
+          cvt_op = vec_dest;
+          vec_dest = vec_dsts[0];
+        }
+
       FOR_EACH_VEC_ELT (vec_oprnds0, i, vop0)
         {
           /* Arguments are ready, create the new vector stmt.  */
@@ -5575,12 +5582,11 @@ vectorizable_conversion (vec_info *vinfo,
           if (multi_step_cvt)
             {
               gcc_assert (multi_step_cvt == 1);
-              new_stmt = vect_gimple_build (vec_dest, codecvt1, vop0);
-              new_temp = make_ssa_name (vec_dest, new_stmt);
+              new_stmt = vect_gimple_build (cvt_op, codecvt1, vop0);
+              new_temp = make_ssa_name (cvt_op, new_stmt);
               gimple_assign_set_lhs (new_stmt, new_temp);
               vect_finish_stmt_generation (vinfo, stmt_info, new_stmt, gsi);
               vop0 = new_temp;
-              vec_dest = vec_dsts[0];
             }
           new_stmt = vect_gimple_build (vec_dest, code1, vop0);
           new_temp = make_ssa_name (vec_dest, new_stmt);

[back]
Comment 6 Hongtao.liu 2023-06-25 03:09:11 UTC
(In reply to Thiago Jung Bauermann from comment #0)
> Created attachment 55387 [details]
> Output of running gfortran with -freport-bug
> 
> In today's trunk (tested commit 33ebb0dff9bb "configure: Implement
> --enable-host-bind-now") I get these new failures on aarch64-linux-gnu:
> 
> Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ...
> FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times
> \\tfcvtzs\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
> FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times
> \\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times
> \\tfcvtzu\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
> FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times
> \\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> \\tscvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> \\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> \\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> \\tucvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> \\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> \\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> 		=== gfortran tests ===
> 

For this scan-assembler failures, It looks like gcc now generates better code, is it ok to adjust testcase to match new assembly?

current:
        ld1d    z31.d, p7/z, [x1, x3, lsl 3]
        fadd    z31.d, p7/m, z31.d, z30.d
        fcvtzs  z31.d, p6/m, z31.d
        st1w    z31.d, p7, [x0, x3, lsl 2]
        add     x3, x3, x4
        whilelo p7.d, w3, w2
        b.any   .L3

vs 
original
        punpklo p2.h, p0.b
        punpkhi p1.h, p0.b
        ld1d    z0.d, p2/z, [x1, x3, lsl 3]
        ld1d    z1.d, p1/z, [x5, x3, lsl 3]
        fadd    z0.d, p2/m, z0.d, z2.d
        fadd    z1.d, p1/m, z1.d, z2.d
        fcvtzs  z0.s, p3/m, z0.d
        fcvtzs  z1.s, p3/m, z1.d
        uzp1    z0.s, z0.s, z1.s
        st1w    z0.s, p0, [x0, x3, lsl 2]
        add     x3, x3, x4
        whilelo p0.s, w3, w2
        b.any   .L3


https://godbolt.org/z/b4cW7WKev
Comment 7 Hongtao.liu 2023-06-25 03:34:46 UTC
(In reply to Hongtao.liu from comment #6)
> (In reply to Thiago Jung Bauermann from comment #0)
> > Created attachment 55387 [details]
> > Output of running gfortran with -freport-bug
> > 
> > In today's trunk (tested commit 33ebb0dff9bb "configure: Implement
> > --enable-host-bind-now") I get these new failures on aarch64-linux-gnu:
> > 
> > Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ...
> > FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times
> > \\tfcvtzs\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
> > FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times
> > \\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times
> > \\tfcvtzu\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
> > FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times
> > \\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> > \\tscvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> > \\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> > \\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> > \\tucvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> > \\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> > \\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > 		=== gfortran tests ===
> > 
> 
> For this scan-assembler failures, It looks like gcc now generates better
> code, is it ok to adjust testcase to match new assembly?
> 
> current:
>         ld1d    z31.d, p7/z, [x1, x3, lsl 3]
>         fadd    z31.d, p7/m, z31.d, z30.d
>         fcvtzs  z31.d, p6/m, z31.d
>         st1w    z31.d, p7, [x0, x3, lsl 2]
>         add     x3, x3, x4
>         whilelo p7.d, w3, w2
>         b.any   .L3
> 
> vs 
> original
>         punpklo p2.h, p0.b
>         punpkhi p1.h, p0.b
>         ld1d    z0.d, p2/z, [x1, x3, lsl 3]
>         ld1d    z1.d, p1/z, [x5, x3, lsl 3]
>         fadd    z0.d, p2/m, z0.d, z2.d
>         fadd    z1.d, p1/m, z1.d, z2.d
>         fcvtzs  z0.s, p3/m, z0.d
>         fcvtzs  z1.s, p3/m, z1.d
>         uzp1    z0.s, z0.s, z1.s
>         st1w    z0.s, p0, [x0, x3, lsl 2]
>         add     x3, x3, x4
>         whilelo p0.s, w3, w2
>         b.any   .L3
> 
> 
> https://godbolt.org/z/b4cW7WKev

Or only adjust testcase for FLOAT_EXPR, not for FIX_TRUNC_EXPR to avoid float- integer overflow.
Comment 8 GCC Commits 2023-06-26 07:30:31 UTC
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:77a50c772771f681085922b493922516c3c03e9a

commit r14-2085-g77a50c772771f681085922b493922516c3c03e9a
Author: liuhongt <hongtao.liu@intel.com>
Date:   Sun Jun 25 11:35:09 2023 +0800

    Don't use intermiediate type for FIX_TRUNC_EXPR when ftrapping-math.
    
    > > Hmm, good question.  GENERIC has a direct truncation to unsigned char
    > > for example, the C standard generally says if the integral part cannot
    > > be represented then the behavior is undefined.  So I think we should be
    > > safe here (0x1.0p32 doesn't fit an int).
    >
    > We should be following Annex F (unspecified value plus "invalid" exception
    > for out-of-range floating-to-integer conversions rather than undefined
    > behavior).  But we don't achieve that very well at present (see bug 93806
    > comments 27-29 for examples of how such conversions produce wobbly
    > values).
    
    That would mean guarding this with !flag_trapping_math would be the appropriate
    thing to do.
    
    gcc/ChangeLog:
    
            PR tree-optimization/110371
            PR tree-optimization/110018
            * tree-vect-stmts.cc (vectorizable_conversion): Don't use
            intermiediate type for FIX_TRUNC_EXPR when ftrapping-math.
    
    gcc/testsuite/ChangeLog:
    
            * gcc.target/i386/pr110018-1.c: Add -fno-trapping-math to dg-options.
            * gcc.target/i386/pr110018-2.c: Ditto.
Comment 9 GCC Commits 2023-06-26 07:49:28 UTC
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:1bfe7e5352d1f4ac525317454aca45aa80a517ba

commit r14-2086-g1bfe7e5352d1f4ac525317454aca45aa80a517ba
Author: liuhongt <hongtao.liu@intel.com>
Date:   Sun Jun 25 11:12:29 2023 +0800

    Use cvt_op to save intermediate type operand instead of "subtle" vec_dest.
    
    When there're multiple operands in vec_oprnds0, vec_dest will be
    overwrited to vectype_out, but in multi_step_cvt case, cvt_type is
    expected. It caused an ICE when verify_gimple_in_cfg.
    
    gcc/ChangeLog:
    
            PR tree-optimization/110371
            PR tree-optimization/110018
            * tree-vect-stmts.cc (vectorizable_conversion): Use cvt_op to
            save intermediate type operand instead of "subtle" vec_dest
            for case NONE.
    
    gcc/testsuite/ChangeLog:
    
            * gcc.target/aarch64/pr110371.c: New test.
Comment 10 Thiago Jung Bauermann 2023-06-26 10:21:34 UTC
Your commit fixed the gfortran failures I reported, thank you!

The aarch64-sve.exp failures are still there, but it's a separate issue.
Comment 11 Thomas Schwinge 2023-06-26 18:42:26 UTC
*** Bug 110412 has been marked as a duplicate of this bug. ***