This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/65215] [5 Regression] Bswap load miscompilation
- From: "thopre01 at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 26 Feb 2015 11:07:43 +0000
- Subject: [Bug tree-optimization/65215] [5 Regression] Bswap load miscompilation
- Auto-submitted: auto-generated
- References: <bug-65215-4 at http dot gcc dot gnu dot org/bugzilla/>
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