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
