This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix subreg in debug_insn handling issue exposed on mn103
- From: Jeff Law <law at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 13 Apr 2017 08:26:27 -0600
- Subject: Re: [PATCH] Fix subreg in debug_insn handling issue exposed on mn103
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5521C31F3E7
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5521C31F3E7
- References: <8786dfde-7773-cb11-0ba0-e7e8b8955049@redhat.com> <20170413140633.GI1809@tucnak>
On 04/13/2017 08:06 AM, Jakub Jelinek wrote:
On Thu, Apr 13, 2017 at 08:03:48AM -0600, Jeff Law wrote:
The mn103 port fails to build newlib/libgcc because it's got a
non-simplifyable (subreg (mem)) in a debug insn.
reload will call eliminate_regs_1 on the debug insn. It'll see the subreg
and call gen_rtx_SUBREG. That asserts that the subreg is valid. Which (of
course) fails.
The key here is that validity of a subreg expression varies depending on
whether or not it appears in a DEBUG_INSN or elsewhere.
The fix is to have reload use gen_rtx_raw_SUBREG for subregs appearing in
DEBUG_INSNs. Doing so allows the mn103 port to build libgcc and newlib
successfully. LRA may also be affected (by inspection), but I haven't tried
to fix it without a way to trigger the issue.
This has been further tested by building most of the *-elf, *-gnu and
*-rtems targets through to newlib, glibc and newlib respectively. The
exceptions that fail do so for completely unrelated reasons.
While it shouldn't trigger anything, I also did a bootstrap & regression
test cycle on x86_64-linux-gnu for sanity's sake.
This is a regression -- mn103 has certainly built libgcc/newlib in the past.
Installing on the trunk,
ENOPATCH. But what you describe looks reasonable.
Bah. Attached.
Jeff
commit e716863933c0cb1db0ba63d014ea989d8ff45c40
Author: law <law@138bc75d-0d04-0410-961f-82ee72b054a4>
Date: Thu Apr 13 14:02:33 2017 +0000
* reload1.c (eliminate_regs_1): Call gen_rtx_raw_SUBREG for SUBREGs
appearing in DEBUG_INSNs.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@246904 138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 740ca66..caec440 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2017-04-13 Jeff Law <law@redhat.com>
+
+ * reload1.c (eliminate_regs_1): Call gen_rtx_raw_SUBREG for SUBREGs
+ appearing in DEBUG_INSNs.
+
2017-04-13 Martin Liska <mliska@suse.cz>
PR gcov-profile/80413
diff --git a/gcc/reload1.c b/gcc/reload1.c
index c1ce7ca..4dc118e 100644
--- a/gcc/reload1.c
+++ b/gcc/reload1.c
@@ -2831,6 +2831,8 @@ eliminate_regs_1 (rtx x, machine_mode mem_mode, rtx insn,
|| x_size == new_size)
)
return adjust_address_nv (new_rtx, GET_MODE (x), SUBREG_BYTE (x));
+ else if (insn && GET_CODE (insn) == DEBUG_INSN)
+ return gen_rtx_raw_SUBREG (GET_MODE (x), new_rtx, SUBREG_BYTE (x));
else
return gen_rtx_SUBREG (GET_MODE (x), new_rtx, SUBREG_BYTE (x));
}