> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Friday, June 27, 2014 4:49 PM
>
> FIne with me now.
Commited.
Best regards,
Thomas
On Fri, Jun 27, 2014 at 4:29 AM, Thomas Preud'homme
wrote:
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>> Sent: Thursday, June 19, 2014 1:36 PM
>>
>> Richard, given this issue, I think we should wait a few more days before I
>>
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Thursday, June 19, 2014 1:36 PM
>
> Richard, given this issue, I think we should wait a few more days before I
> commit
> A backported (and fixed of course) version to 4.8 and 4.
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Thursday, June 19, 2014 1:54 AM
>
> Seems there are actually two spots with this, not just one.
>
> Completely untested fix:
>
> 2014-06-18 Jakub Jelinek
>
> * tree-ssa-math-opts.c (do_shift_rotate, find_bswap_or_nop_1):
> Cast
>
On Wed, Jun 18, 2014 at 05:23:13PM +0200, Marek Polacek wrote:
> On Wed, Jun 18, 2014 at 12:55:01PM +0800, Thomas Preud'homme wrote:
> > @@ -1646,20 +1648,23 @@ do_shift_rotate (enum tree_code code,
> >n->n <<= count;
> >break;
> > case RSHIFT_EXPR:
> > + /* Arithmetic shi
On Wed, Jun 18, 2014 at 12:55:01PM +0800, Thomas Preud'homme wrote:
> @@ -1646,20 +1648,23 @@ do_shift_rotate (enum tree_code code,
>n->n <<= count;
>break;
> case RSHIFT_EXPR:
> + /* Arithmetic shift of signed type: result is dependent on the value.
> */
> + if (!T
On Wed, Jun 18, 2014 at 6:55 AM, Thomas Preud'homme
wrote:
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Wednesday, June 11, 2014 4:32 PM
>> >
>> >
>> > Is this OK for trunk? Does this bug qualify for a backport patch to
>> > 4.8 and 4.9 branches?
>>
>> This is ok for trunk
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, June 11, 2014 4:32 PM
> >
> >
> > Is this OK for trunk? Does this bug qualify for a backport patch to
> > 4.8 and 4.9 branches?
>
> This is ok for trunk and also for backporting (after a short while to
> see if there is
On Tue, Jun 10, 2014 at 10:49 AM, Thomas Preud'homme
wrote:
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Wednesday, June 04, 2014 5:39 PM
>> To: Thomas Preud'homme
>>
>
>>
>> I'm failing to get why you possibly need two casts ... you should
>> only need one, from the bswap/
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> Is this OK for trunk? Does this bug qualify for a backport patch to
> 4.8 and 4.9 branches?
I forgot to mention that this was tested via bootstrap on
x86_64-linux-gnu target, the t
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, June 04, 2014 5:39 PM
> To: Thomas Preud'homme
>
>
> I'm failing to get why you possibly need two casts ... you should
> only need one, from the bswap/load result to the final type
> (zero-extended as you say - so the
On Wed, Jun 4, 2014 at 1:15 PM, Thomas Preud'homme
wrote:
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>>
>> Err, but if you zero-extend directly to the target type you have the
>> correct result, too.
>
> Yep but in some case we need sign extend (32 bit bitwise OR stored
> into 64
> From: Richard Biener [mailto:richard.guent...@gmail.com]
>
> Err, but if you zero-extend directly to the target type you have the
> correct result, too.
Yep but in some case we need sign extend (32 bit bitwise OR stored
into 64 bit result). As I said, the logic could be simplified by sign
exten
On Wed, Jun 4, 2014 at 12:42 PM, Thomas Preud'homme
wrote:
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>>
>> I'd rather change the comparisons
>>
>> - if (n->size < (int)sizeof (int64_t))
>> -n->n &= ((uint64_t)1 << (n->size * BITS_PER_UNIT)) - 1;
>> + if (bitsize / BITS_PER_
> From: Richard Biener [mailto:richard.guent...@gmail.com]
>
> I'd rather change the comparisons
>
> - if (n->size < (int)sizeof (int64_t))
> -n->n &= ((uint64_t)1 << (n->size * BITS_PER_UNIT)) - 1;
> + if (bitsize / BITS_PER_UNIT < (int)sizeof (int64_t))
> +n->n &= ((uint64_t)1 << bits
On Wed, Jun 4, 2014 at 7:59 AM, Thomas Preud'homme
wrote:
> When bswap replace a bitwise expression involving a memory source by a load
> possibly followed by a bswap, it is possible that the load has a size smaller
> than that of the target expression where the bitwise expression was affected.
When bswap replace a bitwise expression involving a memory source by a load
possibly followed by a bswap, it is possible that the load has a size smaller
than that of the target expression where the bitwise expression was affected.
So some sort of cast is needed. But there might also be a differ
17 matches
Mail list logo
