[Bug middle-end/106190] [10/11/12/13 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
From what I can see, because of the -fsanitize-address-use-after-scope being on
by default, we end up with .ASAN_MARK (POISON, &d, 4); inside of a finally
block for try/finally, while previously we just had clobbers there.
This results in code like:
...
  finally_tmp.1 = 0;
  goto <D.3191>;
  <D.3191>:
  .ASAN_MARK (POISON, &d, 4);
  switch (finally_tmp.1) <default: <D.3194>, case 1: <D.3193>>
  <D.3194>:
  goto <D.3189>;
...
  <D.3192>:
  finally_tmp.1 = 1;
  goto <D.3191>;
  <D.3193>:
  resx 1
Where D.3192 is an EH landing pad.
This is because lower_try_finally decided not to copy the .ASAN_MARK (POISON,
&d, 4);
call when we aren't optimizing (it could happen also when optimizing if the
finally
block was large).
Next (perhaps something we could look at), in sanopt we see
  .UBSAN_BOUNDS (0B, 1, 1);
which is there on the
d[1][a] = 0;
statement first because it is an unconditional out of bound access given
d[1][...] declaration.  We actually emit
  if (1 >= 1)
    goto <bb 12>; [0.05%]
  else
    goto <bb 11>; [99.95%]
;;    succ:       11 [100.0% (guessed)]  (FALSE_VALUE)
;;                12 [0.0% (guessed)]  (TRUE_VALUE)

;;   basic block 12, loop depth 1, maybe hot
;;    prev block 3, next block 11, flags: (NEW)
;;    pred:       3 [0.0% (guessed)]  (TRUE_VALUE)
  __builtin___ubsan_handle_out_of_bounds_abort (&*.Lubsan_data0, 1);
;;    succ:       11 [always]  (FALLTHRU)

;;   basic block 11, loop depth 1, maybe hot
without folding the condition and having fallthrough edge even after the
noreturn call.

And later on during optimized pass we try to cleanup the cfg, see that the
d[1][a] = 0
statement is unreachable due to __builtin___ubsan_handle_out_of_bounds_abort
aborting unconditionally before that, so the EH block is unreachable and remove
that EH region.  But the code that uses __builtin_eh_pointer (1) looks to be
reachable (it is not, but nothing finds out that finally_tmp.1 is always 0. 
And we ICE trying to expand the
__builtin_eh_pointer (1) call.