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 tree-optimization/65215] [5 Regression] Bswap load miscompilation


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

--- Comment #5 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> (In reply to Jakub Jelinek from comment #1)
> > Created attachment 34879 [details]
> > gcc5-pr65215.patch
> > 
> > Untested fix.  There are still issues left, e.g. I can't understand the
> > "bswap &&" part in
> >       if (bswap
> >           && align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type))
> >           && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
> >         return false;
> > Don't you use the new MEM_REF even for the !bswap (aka nop) case?  So, I
> > don't see how it would be safe to generate that.
> > And the testsuite coverage of this is definitely suboptimal, from endianity
> > POV, bitfields etc.
> 
> I suggested that change (remove bswap &&) multiple times, but it got lost
> appearantly.  (I even remember applying that change myself!?)


I remember the contrary as this was the reason PR61320 was investigated in the
first place. This idea is that if it's unaligned the expander will take care of
this and that they would be at least as efficient as what the user code was
doing to avoid doing an unaligned load.

I'm happy to revisit that position though.

Best regards,

Thomas


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