On Sat, May 20, 2023 at 8:28 PM Andrew Pinski <pinskia@gmail.com> wrote:
>
> On Sat, May 20, 2023 at 8:25 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
> >
> >
> >
> > On 5/20/23 21:05, Andrew Pinski wrote:
> > > On Sat, May 20, 2023 at 6:26 PM Jeff Law via Gcc-patches
> > > <gcc-patches@gcc.gnu.org> wrote:
> > >>
> > >>
> > >>
> > >> On 5/20/23 19:09, Andrew Pinski via Gcc-patches wrote:
> > >>> The problem is I used expand_expr with the target but
> > >>> we don't want to use the target here as it is the wrong
> > >>> mode for the original expression. The testcase would ICE
> > >>> deap down while trying to do a move to use the target.
> > >>> Anyways just calling expand_expr with NULL_EXPR fixes
> > >>> the issue.
> > >>>
> > >>> Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
> > >>>
> > >>>        PR middle-end/109919
> > >>>
> > >>> gcc/ChangeLog:
> > >>>
> > >>>        * expr.cc (expand_single_bit_test): Don't use the
> > >>>        target for expand_expr.
> > >>>
> > >>> gcc/testsuite/ChangeLog:
> > >>>
> > >>>        * gcc.c-torture/compile/pr109919-1.c: New test.
> > >> Thanks.  I'll respin the targets that failed.  If you don't hear from
> > >> me, assume everything is happy again after this fix.
> > >
> > > Oh, I am going to test on aarch64-linux-gnu too just in case.
> > > Expand is definitely something which I am not used to working on so I
> > > figured I had made a mistake somewhere. I suspect I still made a
> > > similar mistake later on too.
> > I'm seeing some execution failures.  Building H8 bits now to debug as
> > it's the target I'm most familiar with.   More info as it's available.
>
> Is H8 big-endian? I could have messed that up.

If so, try the attached patch. I thought extract_bit_field's bitnum
field was like a shift and not like how BIT_FIELD_REF is defined.

Thanks,
Andrew

>
> Thanks,
> Andrew Pinski
>
> >
> > jeff