https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62262
--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #3)
> (In reply to amker from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > (insn 27 26 40 5 (set (reg:SI 73 [ D.2590 ])
> > > (and:SI (ashift:SI (reg/v:SI 74 [ value ])
> > > (const_int 32 [0x20]))
> > > (const_int 8388607 [0x7fffff]))) t7.c:13 611
> > > {*andim_ashiftsi_bfiz}
> > > (expr_list:REG_DEAD (reg/v:SI 74 [ value ])
> > > (nil)))
> > >
> > > Confirmed.
> > >
> > > "exact_log2 ((INTVAL (operands[3]) >> INTVAL (operands[2])) + 1) >= 0
> > > && (INTVAL (operands[3]) & ((1 << INTVAL (operands[2])) - 1)) == 0"
> > >
> > >
> > > In fact we invoke undefined behavior inside the compiler too due to the
> > > shift there.
> >
> > Since it's undefined code, how should we handle it in GCC? Should we give
> > warning messages as accurate as possible? But that sounds impractical
> > either, since "value << 1" and "value <<= zeros" could be undefined too.
>
> Look at how other targets handle cases like this they reject patterns like
> this. I can fix this but not until next week.
Thanks very much for explaining.
