This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: ICE in trunk due to MEM with address in vector mode
- From: Paulo Matos <pmatos at broadcom dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 24 Jan 2014 11:54:20 +0000
- Subject: RE: ICE in trunk due to MEM with address in vector mode
- Authentication-results: sourceware.org; auth=none
- References: <19EB96622A777C4AB91610E763265F463EED53 at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <87zjmlr72j dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
> -----Original Message-----
> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
> Sent: 24 January 2014 10:46
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: ICE in trunk due to MEM with address in vector mode
>
> Paulo Matos <pmatos@broadcom.com> writes:
> > Hello,
> >
> > I have found a strange case of an ICE due to a MEM with an address
> > with vector mode.
>
> AFAIK that isn't supported. Addresses are assumed to be MODE_INT or
> MODE_PARTIAL_INT. Hopefully someone will correct me if this has changed
> without me noticing it.
>
> Is this for some kind of gather load? I think an address like that
> would have to be mode-dependent anyway, since the number of units
> in the MEM mode and the address mode would need to match.
>
Thanks for your comment.
We have an instruction that loads two 32 bit values into a lower and upper parts of a 64bit register using a base register and a 64 bit register used as a double index.
So,
r1 <- [r0, r2]
means:
low(r1) = [r0 + low(r2)]
high(r1) = [r0 + high(r2)]
In this case we use vector addresses. If it is indeed not allowed then I need another solution. Used to work well in 4.8 and before. In trunk it breaks, but works with the patch I included before.
Can't find anything in the documentation regarding this case so it would be good to make it clear one way or the other.
Paulo Matos
> Thanks,
> Richard