https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739

--- Comment #33 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #32)

> > 
> > Index: gcc/expr.c
> > ===================================================================
> > --- gcc/expr.c  (revision 267553)
> > +++ gcc/expr.c  (working copy)
> > @@ -10562,6 +10562,15 @@ expand_expr_real_1 (tree exp, rtx target
> >            infinitely recurse.  */
> >         gcc_assert (tem != exp);
> >  
> > +       /* When extracting from non-mode bitsize entities adjust the
> > +          bit position for BYTES_BIG_ENDIAN.  */
> > +       if (INTEGRAL_TYPE_P (TREE_TYPE (tem))
> > +           && (TYPE_PRECISION (TREE_TYPE (tem))
> > +               < GET_MODE_BITSIZE (as_a <scalar_int_mode> (TYPE_MODE 
> > (TREE_TYPE (tem)))))
> > +           && BYTES_BIG_ENDIAN)
> > +         bitpos += (GET_MODE_BITSIZE (as_a <scalar_int_mode> (TYPE_MODE 
> > (TREE_TYPE (tem))))
> > +                    - TYPE_PRECISION (TREE_TYPE (tem)));
> > +
> >         /* If TEM's type is a union of variable size, pass TARGET to the 
> > inner
> >            computation, since it will need a temporary and TARGET is known
> >            to have to do.  This occurs in unchecked conversion in Ada.  */
> 
> Btw, this needs to be amended for WORDS_BIG_ENDIAN of course.  I guess
> we might even run into the case that such BIT_FIELD_REF references
> a non-contiguous set of bits... (that's also true for BITS_BIG_ENDIAN !=
> BYTES_BIG_ENDIAN I guess).

Was that meant to be instead or in addition to the tree-ssa-sccvn.c patch? With
both I get:

        lsr     w20, w1, 2
        ...
        and     w1, w20, 65535

With only the expr.c patch it starts to look as expected:

        lsr     w20, w1, 2
        ...
        lsr     w1, w20, 14

And with the latter case the new torture test now passes on big-endian!

Reply via email to