On Mon, Jul 11, 2011 at 5:12 AM, Richard Guenther wrote:
> On Fri, 8 Jul 2011, Richard Guenther wrote:
>
>> On Fri, 8 Jul 2011, Michael Matz wrote:
>>
>> > Hi,
>> >
>> > On Fri, 8 Jul 2011, Richard Guenther wrote:
>> >
>> > > It should be indeed safe with the current handling of conversions, but
>
Richard Guenther wrote:
> 2011-07-13 Richard Guenther
>
> * tree-vrp.c (simplify_conversion_using_ranges): Make sure
> the final type is integral.
This fixes the spu-elf build failure.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ul
On Wed, Jul 13, 2011 at 1:28 AM, Richard Guenther wrote:
> On Tue, 12 Jul 2011, Ulrich Weigand wrote:
>
>> Richard Guenther wrote:
>>
>> > 2011-07-11 Richard Guenther
>> >
>> > * tree-vrp.c (simplify_conversion_using_ranges): Manually
>> > translate the source value-range through the co
On Tue, 12 Jul 2011, Ulrich Weigand wrote:
> Richard Guenther wrote:
>
> > 2011-07-11 Richard Guenther
> >
> > * tree-vrp.c (simplify_conversion_using_ranges): Manually
> > translate the source value-range through the conversion chain.
>
> This causes a build failure in cachemgr.c on
Richard Guenther wrote:
> 2011-07-11 Richard Guenther
>
> * tree-vrp.c (simplify_conversion_using_ranges): Manually
> translate the source value-range through the conversion chain.
This causes a build failure in cachemgr.c on spu-elf. A slightly
modified simplified test case also
Hi,
On Mon, 11 Jul 2011, Richard Guenther wrote:
> The following actually works.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> Can you double-check it?
Seems sensible. Given this:
short s;
int i;
for (s = 0; s <= 127; s++)
i += (signed char)(unsigned char)s;
return
On Fri, 8 Jul 2011, Richard Guenther wrote:
> On Fri, 8 Jul 2011, Michael Matz wrote:
>
> > Hi,
> >
> > On Fri, 8 Jul 2011, Richard Guenther wrote:
> >
> > > It should be indeed safe with the current handling of conversions, but
> > > better be safe. So, like the following?
> >
> > No. The
On Fri, 8 Jul 2011, Michael Matz wrote:
> Hi,
>
> On Fri, 8 Jul 2011, Richard Guenther wrote:
>
> > It should be indeed safe with the current handling of conversions, but
> > better be safe. So, like the following?
>
> No. The point is that you can't compare the bounds that VRP computes with
Hi,
On Fri, 8 Jul 2011, Richard Guenther wrote:
> It should be indeed safe with the current handling of conversions, but
> better be safe. So, like the following?
No. The point is that you can't compare the bounds that VRP computes with
each other when the outcome affects correctness. Think
On Thu, 7 Jul 2011, Michael Matz wrote:
> Hi,
>
> On Thu, 7 Jul 2011, Richard Guenther wrote:
>
> > + tree rhs1 = gimple_assign_rhs1 (stmt);
> > + gimple def_stmt = SSA_NAME_DEF_STMT (rhs1);
> > + value_range_t *final, *inner;
> > +
> > + /* Obtain final and inner value-ranges for a con
Hi,
On Thu, 7 Jul 2011, Richard Guenther wrote:
> + tree rhs1 = gimple_assign_rhs1 (stmt);
> + gimple def_stmt = SSA_NAME_DEF_STMT (rhs1);
> + value_range_t *final, *inner;
> +
> + /* Obtain final and inner value-ranges for a conversion
> + sequence (final-type)(intermediate-type)in
11 matches
Mail list logo
