https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Wilco from comment #25) > (In reply to rguent...@suse.de from comment #17) > > On Tue, 8 Jan 2019, wilco at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739 > > > > > > --- Comment #16 from Wilco <wilco at gcc dot gnu.org> --- > > > I think we need to simplify the many BIG_ENDIAN macros so it is feasible > > > to get > > > big-endian to work reliably on all targets. There seem to be far too many > > > options which affect too many unrelated things. Big-endian is > > > fundamentally > > > about memory byte ordering, so allowing to different byte/bit orderings in > > > registers just makes things overly complex without any benefit. > > > > It's unfortunately not the compiler writers choice but the CPU designers. > > It's more a bad ABI choice. The initial Arm ABI had 4-byte aligned > little-endian long long and big-endian doubles! ARM2 only supported > little-endian so it didn't matter at the time. However it doesn't allow > unaligned accesses, tightly packed bitfields and runtime endian swapping as > required by the embedded space, or hardware floating point. No surprise it > was replaced by the Arm EABI. Whatever ;) Did anybody test the patch? Testing on x86_64 will be quite pointless...
