https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66856
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> --- Ok. So this is caused by operand swapping and a shared stmt (I knew we'd eventually hit such case ... :/) t.c:15:11: note: node t.c:15:11: note: stmt 0 _30 = _29 & 1; t.c:15:11: note: stmt 1 a_15 = g_14(D) & _21; This has bogus ordering - the g_14(D) should be 2nd place to match up with the 1 t.c:15:11: note: node t.c:15:11: note: stmt 0 _29 = _13 >> 5; t.c:15:11: note: stmt 1 _21 = _20 >> 3; t.c:15:11: note: node t.c:15:11: note: stmt 0 _13 = *f_39; t.c:15:11: note: stmt 1 _20 = MEM[(int *)f_39 + 4B]; t.c:15:11: note: node t.c:15:11: note: stmt 0 _27 = a_26 >> 5; t.c:15:11: note: stmt 1 _12 = a_15 >> 5; t.c:15:11: note: node t.c:15:11: note: stmt 0 a_26 = g_14(D) & _25; t.c:15:11: note: stmt 1 a_15 = g_14(D) & _21; Because we swapped the stmt when seeing it used here (dumping missing for the case in vect_get_and_check_slp_defs).
