[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug

[rguenth at gcc dot gnu.org]

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 rguenther@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...