https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118706
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
7862 gcc_checking_assert (! (gimple_assign_load_p (point)
7863 && gimple_assign_load_p (new_stmt))
7864 || (tree_could_trap_p (gimple_assign_rhs1
(point))
7865 == tree_could_trap_p (gimple_assign_rhs1
7866 (new_stmt))));
(gdb) p debug_gimple_stmt (point)
# VUSE <.MEM_4(D)>
_1 = a[-1][-1][6];
$2 = void
(gdb) p debug_gimple_stmt (new_stmt)
# VUSE <.MEM_4(D)>
_5 = BIT_FIELD_REF <a, 32, 0>;
$3 = void
so 'point' is tree_could_trap_p (out-of-bound first index) but 'new_stmt'
isn't (ref is inside of 'a'). IMO this is OK and the assert is too strict.
So we want >= instead of == (if there's such a thing for bool), or
!tree_could_trap_p (gimple_assign_rhs1 (new_stmt)) || tree_could_trap_p
(gimple_assign_rhs1 (point)).
But - IIRC 'point' is just one of possibly N loads, and only one of those
might trap, making new_stmt trap, right? As if we combine
a[-1][-1][6] == 0 && a[0][0][1] == 0 to BIT_FIELD_REF <a, 64, 0> == 0.
So the assert is even misplaced (make_bit_field_load does not see all
originally
involved refs)?
