[PATCH] Fix subreg in debug_insn handling issue exposed on mn103

[Jakub Jelinek]

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.

	Jakub