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 8888438582B1; Wed, 14 Sep 2022 12:20:31 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8888438582B1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1663158031;
	bh=0eMD2bE/Jze8rkNkFXQx7afxXgAjALG6dEe8AjO1C/c=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=X2dSdTAKHHa94uXQudlKfByP0m7yCtLAAUGHkdxHtbilU190XwBSTAUOT+T4m12SC
	 mEwA9hXOOuw8qA9B803kP7aCg8Efye2CCRZw0eeBI881IJwX5mzidB8QU7eGLQa66h
	 k5wOYXXs9ObQhtWvC6TFJax+GWcYi4wlvvx8fctw=
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/96072] ICE: Segmentation fault (in add_reg_note)
Date: Wed, 14 Sep 2022 12:20:28 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: ice-on-invalid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: linkw at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc bug_status
Message-ID: <bug-96072-4-6ELwCnD7jV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-96072-4@http.gcc.gnu.org/bugzilla/>
References: <bug-96072-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=3D96072

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |linkw at gcc dot gnu.org
             Status|WAITING                     |NEW

--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> ---
Confirmed.

  if (DEFAULT_ABI =3D=3D ABI_V4 || flag_shrink_wrap)
    {
      /* If the frame pointer was used then we can't delay emitting
         a REG_CFA_DEF_CFA note.  This must happen on the insn that
         restores the frame pointer, r31.  We may have already emitted
         a REG_CFA_DEF_CFA note, but that's OK;  A duplicate is
         discarded by dwarf2cfi.cc/dwarf2out.cc, and in any case would
         be harmless if emitted.  */
      if (frame_pointer_needed)
        {
          insn =3D get_last_insn ();
          add_reg_note (insn, REG_CFA_DEF_CFA,
                        plus_constant (Pmode, frame_reg_rtx, frame_off));
          RTX_FRAME_RELATED_P (insn) =3D 1;
        }

ICE since the insn here is (rtx) 0x0.

I think the code here has the assumption that the frame pointer restoring
happened ahead, it's:

  /* If we have a frame pointer, we can restore the old stack pointer
     from it.  */
  else if (frame_pointer_needed_indeed)
    {
      frame_reg_rtx =3D sp_reg_rtx;
      ....=