https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653
--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > 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. That's by design, the entire implementation assumes that every scalar in memory is accessed using the same storage order throughout the entire program. If you want to overcome this limitation, you need to reimplement it from scratch.
