[Bug c/100653] usage of scalar_storage_order produces incorrect result

[george.thopas at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653

--- Comment #9 from George Thopas <george.thopas at gmail dot com> ---
Created attachment 51025
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51025&action=edit
avoid eliminating fields with different endianess as equal

Short story :
Ran a bisect to find why this always works in the gcc-6 branch and has
different behaviour outside. Found out what happens (see below) and attached a
2-line patch for what I assume is missing.  Works for me but is it the 'right
thing'(tm) todo ?  

Thanks.

Long story:
I started digging into this in the hope to get a better understanding
In the last 3 years I've never seen this on the gcc-6 branch. 
Even though there's a tons of code and mixed endianess structures and 
unions validation. If I missed it, I at least needed to know at least why. 

The bisect ended up giving commit e7a3e0c653be4bd32f116dae06438896b7dc915b.
Reverting it for test purposes in gcc-7/gcc-8 just confirmed it is the 
right trigger.

There's obviously nothing wrong with that commit but at least it gave me 
a clue what to look for. To my understanding of the code :
The RPO change affects evaluation order when merging and eliminating blocks.
In the case of the example, the compiler ends up checking if both fields 
of the union are the same and can be merged/eliminated. Their both in the same
location. The code currently considers different signedness and bails out, but
not different  endianness and eliminates one depending one evaluation order. 
Whatever one that is.