On Fri, Apr 15, 2016 at 01:41:25PM +0200, Jakub Jelinek wrote:
> On Fri, Apr 15, 2016 at 01:37:07PM +0200, Bernd Schmidt wrote:
> > On 04/15/2016 02:35 AM, Segher Boessenkool wrote:
> > >This now also shows up on GCC 5, see PR70672. It there happens in
> > >the jump1 pass already.
> > >
> > >Is th
On Fri, Apr 15, 2016 at 01:37:07PM +0200, Bernd Schmidt wrote:
> On 04/15/2016 02:35 AM, Segher Boessenkool wrote:
> >This now also shows up on GCC 5, see PR70672. It there happens in
> >the jump1 pass already.
> >
> >Is this okay to backport to 5 and 4.9?
>
> Ok.
Can you please also create a ru
On 04/15/2016 02:35 AM, Segher Boessenkool wrote:
This now also shows up on GCC 5, see PR70672. It there happens in
the jump1 pass already.
Is this okay to backport to 5 and 4.9?
Ok.
Bernd
Hi,
This now also shows up on GCC 5, see PR70672. It there happens in
the jump1 pass already.
Is this okay to backport to 5 and 4.9?
Segher
On Wed, Dec 09, 2015 at 08:17:51PM +, Segher Boessenkool wrote:
> The meaning of ZERO_EXTRACT depends on BITS_BIG_ENDIAN, not on
> BYTES_BIG_ENDIAN.
On Thu, Dec 10, 2015 at 01:26:06PM +0100, Eric Botcazou wrote:
> Thanks. It seems a little odd for the condition to test the POS (operand #2)
> and not also the LEN (operand #1) of the ZERO_EXTRACT before returning true,
> but I'm not sure what the test would be given the above example. Or mayb
> My case comes from the gcc.dg/pr65492-2.c, the "test1int2" case.
> combine has made an insn
> modifying insn i321: zero_extract(%3:DI,0x20,0)=%3:DI
> which is splatting the SImode parameter to both the high and low halves
> of the dest reg. Then, it tries to combine it with the USE of
On Wed, Dec 09, 2015 at 10:13:34PM +0100, Eric Botcazou wrote:
> > The meaning of ZERO_EXTRACT depends on BITS_BIG_ENDIAN, not on
> > BYTES_BIG_ENDIAN.
>
> That's correct.
> > --- a/gcc/rtlanal.c
> > +++ b/gcc/rtlanal.c
> > @@ -1534,7 +1534,7 @@ set_noop_p (const_rtx set)
> >
> >if (GET_CODE
> The meaning of ZERO_EXTRACT depends on BITS_BIG_ENDIAN, not on
> BYTES_BIG_ENDIAN.
That's correct.
> Testing in progress on powerpc64le-linux; if it passes, is this
> okay for trunk?
>
>
> Segher
>
>
> 2015-12-09 Segher Boessenkool
>
> PR rtl-optimization/68814
> * rtlanal.c
The meaning of ZERO_EXTRACT depends on BITS_BIG_ENDIAN, not on
BYTES_BIG_ENDIAN. This caused PR68814.
Testing in progress on powerpc64le-linux; if it passes, is this
okay for trunk?
Segher
2015-12-09 Segher Boessenkool
PR rtl-optimization/68814
* rtlanal.c (set_noop_p): Us
