[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