This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/62262] aarch64 gcc generates invalid assembler


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]