On 18 June 2014 00:02, Ramana Radhakrishnan <ramana....@googlemail.com> wrote: > > Interesting workaround but can we investigate further how to fix this > at the source rather than working around in the backend in this form. > It's still a kludge that we carry in the backend rather than fix the > problem at it's source. I'd rather try to fix the problem at the > source rather than working around this in the backend.
I still think this is a back-end bug. Unless I've missed something, it looks like the compiler has generated an insn which meets its constraints (we'd see an "insn does not satisfy its constraints" ICE if not) but the back-end generates an ICE much later, when trying to emit code for it. The problem with trying to fix the bug "at source" in reload is that this inconsistency will remain as a potential latent bug. I see two options to fix it - one is to teach the back-end to successfully generate code for this insn, and the other is to teach the back-end that such an insn is not valid. My proposed patch does the former. The latter can presumably be achieved by providing a different kind of memory constraint which disallows constant pool references for these insns although I haven't tried this yet. Charles
