From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 0380B3858D39; Mon, 27 Mar 2023 14:15:34 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0380B3858D39
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1679926535;
	bh=H1UzJH5AgLi970ULIs8VFDiUGt7tMOoOZkH+6FZJ7kM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=OPQwbRFynqSWpsLemMTx6B6CrW/bfPbM/BHaPnObKRu2MO5+EGQ4cREPoRbwvUJTe
	 HNFiHxkNb4IA1B2vAzWjeVlgRTIPBashpiTv/t02m8FN86jtGJ7yAxk0kMjrKb9cRs
	 MG5S/u9IbtcW+DgbrqDDCUYwVnhyeK0YI0LbEOpM=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [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
Date: Mon, 27 Mar 2023 14:15:33 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: EH, ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 10.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-106190-4-5xe8vuCCKw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106190-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106190-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

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 bein=
g 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 =3D 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 =3D 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 (POISO=
N,
&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] =3D 0;
statement first because it is an unconditional out of bound access given
d[1][...] declaration.  We actually emit
  if (1 >=3D 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] =3D 0
statement is unreachable due to __builtin___ubsan_handle_out_of_bounds_abort
aborting unconditionally before that, so the EH block is unreachable and re=
move
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.=
=20
And we ICE trying to expand the
__builtin_eh_pointer (1) call.=