On Tue, Jul 01, 2025 at 10:55:00AM +0200, Jakub Jelinek wrote:
> I've actually tried
> --- gcc/passes.def 2025-06-30 22:16:11.258688529 +0200
> +++ gcc/passes.def 2025-07-01 10:47:37.020634803 +0200
> @@ -444,9 +444,9 @@ along with GCC; see the file COPYING3.
> NEXT_PASS (pass_lower_switch_O0);
> NEXT_PASS (pass_asan_O0);
> NEXT_PASS (pass_tsan_O0);
> - NEXT_PASS (pass_sanopt);
> NEXT_PASS (pass_cleanup_eh);
> NEXT_PASS (pass_musttail);
> + NEXT_PASS (pass_sanopt);
> NEXT_PASS (pass_lower_resx);
> NEXT_PASS (pass_nrv);
> NEXT_PASS (pass_gimple_isel);
> together with the non-empty_eh_cleanup tree-tailcall.cc changes from the
> patch, but that resulted in the following ICE:
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/asan/pr106190.c: In function 'main':
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/asan/pr106190.c:6:1: internal
> compiler error: in expand_builtin_eh_common, at except.cc:2097
> 0x2dc62cf internal_error(char const*, ...)
> ../../gcc/diagnostic-global-context.cc:517
> 0xeaeced fancy_abort(char const*, int, char const*)
> ../../gcc/diagnostic.cc:1810
> 0x81940a expand_builtin_eh_common
> ../../gcc/except.cc:2097
> 0x11ad909 expand_builtin_eh_pointer(tree_node*)
> ../../gcc/except.cc:2108
> 0x11deac2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
> ../../gcc/expr.cc:12535
> 0x11ecddd store_expr(tree_node*, rtx_def*, int, bool, bool)
> ../../gcc/expr.cc:6762
> 0x11efb28 expand_assignment(tree_node*, tree_node*, bool)
> ../../gcc/expr.cc:6483
> 0x11efb28 expand_assignment(tree_node*, tree_node*, bool)
> ../../gcc/expr.cc:5971
> 0x1093629 expand_call_stmt
> ../../gcc/cfgexpand.cc:3202
> 0x1093629 expand_gimple_stmt_1
> ../../gcc/cfgexpand.cc:4276
> 0x1093629 expand_gimple_stmt
> ../../gcc/cfgexpand.cc:4423
> 0x1095617 expand_gimple_basic_block
> ../../gcc/cfgexpand.cc:6539
> 0x1097a07 execute
> ../../gcc/cfgexpand.cc:7286
>
> Given that empty_eh_cleanup handles already almost everything, just
> didn't know how to handle the resx to internal step which was quite
> trivial, I thought it will be easier not to reorder cleanup_eh pass,
> especially for 15.2 backport and when I have no idea what went wrong
> in the pr106190 testcase (the ICE is about not finding some region).
Just guessing, but the sanopt pass on that case removes quite a lot of basic
blocks etc. and perhaps expansion relies on the EH stuff being cleaned up
before expansion. When it is done before sanopt, it can't clean up some
stuff yet.
Tested also
--- gcc/passes.def.jj 2025-06-30 21:48:31.063723401 +0200
+++ gcc/passes.def 2025-07-01 11:22:50.484144188 +0200
@@ -444,9 +444,10 @@ along with GCC; see the file COPYING3.
NEXT_PASS (pass_lower_switch_O0);
NEXT_PASS (pass_asan_O0);
NEXT_PASS (pass_tsan_O0);
- NEXT_PASS (pass_sanopt);
NEXT_PASS (pass_cleanup_eh);
NEXT_PASS (pass_musttail);
+ NEXT_PASS (pass_sanopt);
+ NEXT_PASS (pass_cleanup_eh);
NEXT_PASS (pass_lower_resx);
NEXT_PASS (pass_nrv);
NEXT_PASS (pass_gimple_isel);
and that works, but the empty_eh_cleanup change seems better to me than
repeating the pass so close.
Jakub
