[Bug tree-optimization/81292] [8 regression] ICE in zero_length_string, at tree-ssa-strlen.c:822
rsandifo at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Jul 3 18:17:00 GMT 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81292
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org
--- Comment #5 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> The problem is that we hit:
> if (si != NULL)
> {
> if (!si->full_string_p && !si->stmt)
> {
> /* Until now we only had a lower bound on the string length.
> Install LHS as the actual length. */
> si = unshare_strinfo (si);
> si->nonzero_chars = lhs;
> si->full_string_p = true;
> }
> return;
> }
> in handle_builtin_strlen, which changes just that single strinfo record, but
> doesn't do anything for the related ones. And as strlen doesn't have a vdef
> (it is a pure function), nothing is invalidated, so we end up with a mixture
> of related strinfos where some strinfos are full_string_p and others are
> not,
Bah, sorry, I hadn't considered the lack of a vdef here.
> and e.g. zero_length_string has asserts that this does not happen.
> So, either handle_builtin_strlen needs to adjust also the related strinfos
> if any (note, maybe even if verify_related_strinfos fails we might need to
> do that or invalidate them manually), or we need to invalidate them, or not
> to record this change if we can't adjust or invalidate them all.
Ack. Will fix.
More information about the Gcc-bugs
mailing list