https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052
--- Comment #16 from amker at gcc dot gnu.org --- (In reply to amker from comment #14) > Author: amker > Date: Wed Mar 2 14:10:56 2016 > New Revision: 233907 > > URL: https://gcc.gnu.org/viewcvs?rev=233907&root=gcc&view=rev > Log: > > PR tree-optimization/69052 > * loop-invariant.c (canonicalize_address): New function. > (inv_can_prop_to_addr_use): Check validity of address expression > which is canonicalized by above function. > > gcc/testsuite/ChangeLog > PR tree-optimization/69052 > * gcc.target/i386/pr69052.c: New test. > > > Added: > trunk/gcc/testsuite/gcc.target/i386/pr69052.c > Modified: > trunk/gcc/ChangeLog > trunk/gcc/loop-invariant.c > trunk/gcc/testsuite/ChangeLog Just realized that CONST_INT and CONST_WIDE_INT both have the same precedence. The patch I applied could be broken in cases which have both CONST_INT and CONST_WIDE_INT address parts and the CONST_WIDE_INT one happens to be sorted after CONST_INT, as below code: /* Simplify all constant int summary if possible. */ for (i = 0; i < addr_parts.length (); i++) if (CONST_INT_P (addr_parts[i])) break; for (j = i + 1; j < addr_parts.length (); j++) { gcc_assert (CONST_INT_P (addr_parts[j])); <-----assertion failure addr_parts[i] = simplify_gen_binary (PLUS, mode, addr_parts[i], addr_parts[j]); } Although I don't think we can really run into such complicated address expression, I will work out a patch to compare_address_parts to force CONST_INT after CONST_WIDE_INT during sorting.
