> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 24 January 2014 16:34
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: ICE in trunk due to MEM with address in vector mode
>
> Paulo Matos writes:
> >> If we
Paulo Matos writes:
>> If we do support vector addresses than I think the right fix is to
>> check VECTOR_MODE_P there.
>
> Well, isn't it the case that a mem with vector mode is always mode
> dependent, in which case adding VECTOR_MODE_P to mode-dependent target
> hook would be enough making the
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 24 January 2014 12:21
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: ICE in trunk due to MEM with address in vector mode
>
> Just in case: the point I was tryi
Paulo Matos writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:rdsandif...@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
&g
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@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 writes:
> > Hello,
Paulo Matos 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 fo
Hello,
I have found a strange case of an ICE due to a MEM with an address with vector
mode.
The ICE looks like:
baaclc_block.c: In function 'fn2':
baaclc_block.c:22:1: internal compiler error: in trunc_int_for_mode, at
explow.c:56
}
^
0x64d050 trunc_int_for_mode(long, machine_mode)
/h
