This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix newlib build failure for mips16
- From: Jeff Law <law at redhat dot com>
- To: gcc-patches <gcc-patches at gcc dot gnu dot org>, rdsandiford at googlemail dot com
- Date: Fri, 14 Apr 2017 11:01:39 -0600
- Subject: Re: [PATCH] Fix newlib build failure for mips16
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.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 6D81880F9F
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6D81880F9F
- References: <8ae83192-929a-a677-639e-100e036672a0@redhat.com> <87efwvw7vw.fsf@googlemail.com> <46ac2419-b3cb-6895-6ae6-5d9d0cff3aa8@redhat.com> <87y3v3ufc9.fsf@googlemail.com>
On 04/14/2017 10:24 AM, Richard Sandiford wrote:
I think it only does that if the "containing object" that you're
validating is a MEM. If the object you're validating is an insn
(which it always is for regcprop) then normal constrain_operands
does happen.
Hmm, you've of course right!
Adding code to do that to individual MIPS patterns feels like a hack to me.
The pass should be doing it itself.
Agreed. It's a hack. But it was the best I could see to do at this stage.
Been looking at it a bit more, and I think the problem is that we're
somehow ending up with a second stack pointer rtx, distinct from
stack_pointer_rtx. And then I remembered that this had been discussed
before, see the tail end of:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02362.html
I'd be happier with the mips_stack_address_p change described there,
although it still seems like a hack.
Let me dig a little further. Two stack pointers just sounds
fundamentally wrong.
jeff