https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #25 from Wilco <wilco at gcc dot gnu.org> --- (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.
