https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126153
--- Comment #30 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-16 branch has been updated by Richard Biener <[email protected]>: https://gcc.gnu.org/g:20613cacb4a2d57b69e270de974732c2a8f1856c commit r16-9662-g20613cacb4a2d57b69e270de974732c2a8f1856c Author: Richard Biener <[email protected]> Date: Wed Sep 2 10:28:49 2026 +0200 tree-optimization: do not lose reverse storage order when translating a ref When vn_reference_lookup_3 translates a reference through an aggregate copy it may fail to find a common base and instead reduce the lookup to the base of the copy's right-hand side plus a constant offset, folding all of the original operands away. A reversed storage order is a property of the component and not of its position, so it cannot be recovered from that offset: the translated reference ends up in natural order and the later "assignment from a constant" case interprets the stored bytes with the wrong bit numbering, silently producing a wrong value. Punt in that case, i.e. when no original operand survives and either access is in reverse storage order. When an operand does survive it stays outermost and carries the flag, so the storage order of the translated reference is unchanged; a reverse flag on an inner operand only describes an inner container and does not affect the byte order of the scalar access. reverse_storage_order_for_component_p now takes its argument by const reference so that the auto_vec holding the right-hand side operands can be passed to it. Assisted-by: Claude Opus 5 <[email protected]> PR tree-optimization/126153 * tree-ssa-sccvn.cc (reverse_storage_order_for_component_p): Take the operands by const reference. (vn_reference_lookup_3): Punt when translating a reference through an aggregate copy consumes all of its operands and either access has reverse storage order. * gcc.dg/torture/sso-fre-1.c: New test. (cherry picked from commit 5d3f80d7d9baf9207bb037a85ad78f3bcee4e41b)
