Tom de Vries writes:
> On 21/09/12 03:40, Sandra Loosemore wrote:
>> Re:
>>
>>> I think tree-ssa-loop-ivopts is simply
>>> asking for the wrong thing, and needs to be changed. As I say,
>>> Sandra had some fixes in this area.
>>
>> This patch:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2012-06/ms
Hi,
> >> I think tree-ssa-loop-ivopts is simply
> >> asking for the wrong thing, and needs to be changed. As I say,
> >> Sandra had some fixes in this area.
> >
> > This patch:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html
> >
> > Sadly, that patch has fallen off the bottom o
On 21/09/12 03:40, Sandra Loosemore wrote:
> Re:
>
>> I think tree-ssa-loop-ivopts is simply
>> asking for the wrong thing, and needs to be changed. As I say,
>> Sandra had some fixes in this area.
>
> This patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html
>
> Sadly, that patc
Re:
I think tree-ssa-loop-ivopts is simply
asking for the wrong thing, and needs to be changed. As I say,
Sandra had some fixes in this area.
This patch:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html
Sadly, that patch has fallen off the bottom of my priority list (some
legal wran
Steve Ellcey writes:
> On Wed, 2012-09-19 at 18:42 +0100, Richard Sandiford wrote:
>> But the documentation says:
>>
>> This hook is never called with an invalid address.
>>
>> Since VOIDmode MEMs aren't valid, I think that should mean it's invalid
>> to call this hook (and rtlanal.c:address_c
On Wed, 2012-09-19 at 18:42 +0100, Richard Sandiford wrote:
> But the documentation says:
>
> This hook is never called with an invalid address.
>
> Since VOIDmode MEMs aren't valid, I think that should mean it's invalid
> to call this hook (and rtlanal.c:address_cost) with VOIDmode. I never
On Wed, 2012-09-19 at 18:42 +0100, Richard Sandiford wrote:
> This hook is never called with an invalid address.
>
> Since VOIDmode MEMs aren't valid, I think that should mean it's invalid
> to call this hook (and rtlanal.c:address_cost) with VOIDmode. I never
> got time to look at that though
"Steve Ellcey " writes:
> While building newlib with -O2 -mips16 I ran into a problem with GCC
> aborting due to the compiler trying to execute '0 % 0' in
> mips16_unextended_reference_p. The problem was that the code checked
> for BLKmode and skipped the modulo operation in that case because
> G
While building newlib with -O2 -mips16 I ran into a problem with GCC
aborting due to the compiler trying to execute '0 % 0' in
mips16_unextended_reference_p. The problem was that the code checked
for BLKmode and skipped the modulo operation in that case because
GET_MODE_SIZE (BLKmode) is zero but
