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

[Jeff Law]

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,

Jeff