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.
