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