[Bug tree-optimization/107209] New: [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[Bug tree-optimization/107209] New: [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[asolokha at gmx dot com]

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

            Bug ID: 107209
           Summary: [13 Regression] ICE: verify_gimple failed (error:
                    statement marked for throw, but doesn't)
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-invalid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: aarch64-linux-gnu

gcc 13.0.0 20221009 snapshot (g:e95e91eccd022a4a3a86da2749809fbad9afd20e) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/aarch64/simd/vmulx_f64_2.c, w/ -O2
-fnon-call-exceptions -fno-tree-fre:

#include <arm_neon.h>

float64x1_t
foo (void)
{
  float64_t v1 = 3.14159265359;
  float64_t v2 = 1.383894;
  float64_t vec_1_data[] = {v1};
  float64_t vec_2_data[] = {v2};
  float64x1_t vec_1 = vld1_f64 (vec_1_data);
  float64x1_t vec_2 = vld1_f64 (vec_2_data);

  return vmulx_f64 (vec_1, vec_2);
}

% aarch64-linux-gnu-gcc-13 -O2 -fnon-call-exceptions -fno-tree-fre -c
i2myytft.c
i2myytft.c: In function 'foo':
i2myytft.c:14:1: error: statement marked for throw, but doesn't
   14 | }
      | ^
_24 = 4.34763122374727917218706352286972105503082275390625e+0;
during GIMPLE pass: evrp
i2myytft.c:14:1: internal compiler error: verify_gimple failed
0xf7ec8d verify_gimple_in_cfg(function*, bool)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/tree-cfg.cc:5648
0xe3af47 execute_function_todo
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/passes.cc:2091
0xe3b47e execute_todo
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/passes.cc:2145

[Bug tree-optimization/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
           Keywords|                            |needs-bisection

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks like EVRP elimination fails to clean EH?  Or target folding.  Would be
nice to have a testcase not requiring aarch64 intrinsics.

[Bug tree-optimization/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-10-11
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Looks like EVRP elimination fails to clean EH?  Or target folding.  Would be
> nice to have a testcase not requiring aarch64 intrinsics.

I tried but didn't crash.
```
#define vector __attribute__((vector_size(sizeof(double))))

vector double
foo1 (void)
{
  double v1 = 3.14159265359;
  double v2 = 1.383894;
  double vec_1_data[] = {v1};
  double vec_2_data[] = {v2};
  vector double vec_1 = {vec_1_data[0]};
  vector double vec_2 = {vec_2_data[0]};

  return vec_1*vec_2;
}
```

Before evrp on the working testcase:
```
  vec_1_data$0_3 = 3.14159265359000006156975359772332012653350830078125e+0;
  vec_2_data$0_4 = 1.3838939999999999574953335468308068811893463134765625e+0;
  _1 = vec_1_data$0_3;
  vec_1_9 = {_1};
  _2 = vec_2_data$0_4;
  vec_2_11 = {_2};
  [LP 1] _12 = vec_1_9 * vec_2_11;
```

But with the aarch64 intrinsics:
  vec_1_data$0_2 = 3.14159265359000006156975359772332012653350830078125e+0;
  vec_2_data$0_3 = 1.3838939999999999574953335468308068811893463134765625e+0;
  _10 = vec_1_data$0_2;
  _7 = {_10};
  _20 = vec_2_data$0_3;
  _21 = {_20};
  [LP 1] # .MEM_28 = VDEF <.MEM_4(D)>
  # USE = nonlocal escaped 
  # CLB = nonlocal escaped 
  _24 = __builtin_aarch64_fmulxdf (_10, _20);
```

aarch64_general_gimple_fold_builtin inside aarch64-builtins.cc which does the
folding and it looks correct.
`BUILTIN_GPF (BINOP, fmulx, 0, ALL)`

So it requires aarch64 intrinsics.
In GCC 12, the folding of fmulxdf or the multiply didn't happen during evrp
even.

[Bug tree-optimization/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug target/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |target

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
_24 = 4.34763122374727917218706352286972105503082275390625e+0;

aarch64_general_gimple_fold_builtin builds

_24 = 3.14159265359000006156975359772332012653350830078125e+0 *
1.3838939999999999574953335468308068811893463134765625e+0;

and then rvrp_folder::fold_stmt folds this further.

Now, aarch64_general_gimple_fold_builtin uses gsi_replace with (..., true)
and so that moves EH info to the new stmt, but then

      /* Now cleanup.  */
      if (did_replace)
        {
...
          /* If we cleaned up EH information from the statement,
             remove EH edges.  */
          if (maybe_clean_or_replace_eh_stmt (old_stmt, stmt))
            bitmap_set_bit (need_eh_cleanup, bb->index);

no longer triggers.  So this is a target bug, aarch64 folding should _not_
update EH info, folding shouldn't update any of the on-the-side info.

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 1d0f994f281..890062d359b 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -15157,7 +15157,7 @@ aarch64_gimple_fold_builtin (gimple_stmt_iterator *gsi)
   if (!new_stmt)
     return false;

-  gsi_replace (gsi, new_stmt, true);
+  gsi_replace (gsi, new_stmt, false);
   return true;
 }


fixes this.  aarch64 folks please test&push.

[Bug target/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Looking at other backends, rs6000 uses in *gimple_fold_builtin gsi_replace
(..., true);
all the time, ix86 gsi_replace (..., false); all the time, alpha with true,
aarch64 with true.  But perhaps what is more important if the builtins folded
are declared nothrow or not, if they are nothrow, then they shouldn't have any
EH edges at the start already and so it shouldn't matter what is used.

[Bug target/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> Looking at other backends, rs6000 uses in *gimple_fold_builtin gsi_replace
> (..., true);
> all the time, ix86 gsi_replace (..., false); all the time, alpha with true,
> aarch64 with true.  But perhaps what is more important if the builtins
> folded are declared nothrow or not, if they are nothrow, then they shouldn't
> have any EH edges at the start already and so it shouldn't matter what is
> used.

The vmulx_f64 intrinsic is not marked "nothrow" by the logic:
1284 static tree
1285 aarch64_get_attributes (unsigned int f, machine_mode mode)
1286 {
1287   tree attrs = NULL_TREE;
1288
1289   if (!aarch64_modifies_global_state_p (f, mode))
1290     {
1291       if (aarch64_reads_global_state_p (f, mode))
1292         attrs = aarch64_add_attribute ("pure", attrs);
1293       else
1294         attrs = aarch64_add_attribute ("const", attrs);
1295     }
1296
1297   if (!flag_non_call_exceptions || !aarch64_could_trap_p (f, mode))
1298     attrs = aarch64_add_attribute ("nothrow", attrs);
1299
1300   return aarch64_add_attribute ("leaf", attrs);
1301 }

aarch64_could_trap_p returns true for it as it can raise an FP exception.
Should that affect the nothrow attribute though? Shouldn't that be for C++
exceptions only?

[Bug target/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ktkachov from comment #5)
> aarch64_could_trap_p returns true for it as it can raise an FP exception.
> Should that affect the nothrow attribute though? Shouldn't that be for C++
> exceptions only?

nothrow isn't just C++ attribute, it is also for C, which uses EH e.g. for
pthread_cancel or the non-call exceptions if -fexceptions.  Here
-fnon-call-exceptions is on and the builtin can trap, so it is right that the
builtin isn't marked nothrow,
but then you need to either punt on folding that on GIMPLE if
flag_non_call_exceptions
and there is an EH edge for it, or ensure somehow the EH stuff is preserved
during the folding.

[Bug target/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:3893c9c0a16832f55d8d0827f50c48a56c52f6e7

commit r13-5137-g3893c9c0a16832f55d8d0827f50c48a56c52f6e7
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Jan 13 10:01:32 2023 +0000

    aarch64: Don't update EH info when folding [PR107209]

    The AArch64 folders tried to update EH info on the fly, bypassing
    the folder's attempts to remove dead EH edges later.  This triggered
    an ICE when folding a potentially-trapping call to a constant.

    gcc/
            PR target/107209
            * config/aarch64/aarch64.cc (aarch64_gimple_fold_builtin): Don't
            update EH info on the fly.

    gcc/testsuite/
            * gcc.target/aarch64/pr107209.c: New test.

    Co-Authored-By: Richard Biener <rguenther@suse.de>

[Bug target/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

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

--- Comment #8 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Fixed.