[Bug tree-optimization/112303] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_flow_info failed since r14-3459-g0c78240fd7d519

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303

--- Comment #16 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:b7b4ef2ff20c5023a41ed663dd8f4724b4ff0f9c

commit r13-8525-gb7b4ef2ff20c5023a41ed663dd8f4724b4ff0f9c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Mar 28 15:00:44 2024 +0100

    profile-count: Avoid overflows into uninitialized [PR112303]

    The testcase in the patch ICEs with
    --- gcc/tree-scalar-evolution.cc
    +++ gcc/tree-scalar-evolution.cc
    @@ -3881,7 +3881,7 @@ final_value_replacement_loop (class loop *loop)

           /* Propagate constants immediately, but leave an unused
initialization
             around to avoid invalidating the SCEV cache.  */
    -      if (CONSTANT_CLASS_P (def) && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI
(rslt))
    +      if (0 && CONSTANT_CLASS_P (def) && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI
(rslt))
            replace_uses_by (rslt, def);

           /* Create the replacement statements.  */
    (the addition of the above made the ICE latent), because profile_count
    addition doesn't check for overflows and if unlucky, we can even overflow
    into the uninitialized value.
    Getting really huge profile counts is very easy even when not using
    recursive inlining in loops, e.g.
    __attribute__((noipa)) void
    bar (void)
    {
      __builtin_exit (0);
    }

    __attribute__((noipa)) void
    foo (void)
    {
      for (int i = 0; i < 1000; ++i)
      for (int j = 0; j < 1000; ++j)
      for (int k = 0; k < 1000; ++k)
      for (int l = 0; l < 1000; ++l)
      for (int m = 0; m < 1000; ++m)
      for (int n = 0; n < 1000; ++n)
      for (int o = 0; o < 1000; ++o)
      for (int p = 0; p < 1000; ++p)
      for (int q = 0; q < 1000; ++q)
      for (int r = 0; r < 1000; ++r)
      for (int s = 0; s < 1000; ++s)
      for (int t = 0; t < 1000; ++t)
      for (int u = 0; u < 1000; ++u)
      for (int v = 0; v < 1000; ++v)
      for (int w = 0; w < 1000; ++w)
      for (int x = 0; x < 1000; ++x)
      for (int y = 0; y < 1000; ++y)
      for (int z = 0; z < 1000; ++z)
      for (int a = 0; a < 1000; ++a)
      for (int b = 0; b < 1000; ++b)
        bar ();
    }

    int
    main ()
    {
      foo ();
    }
    reaches the maximum count already on the 11th loop.

    Some other methods of profile_count like apply_scale already
    do use MIN (val, max_count) before assignment to m_val, this patch
    just extends that to operator{+,+=} methods.
    Furthermore, one overload of apply_probability wasn't using
    safe_scale_64bit and so could very easily overflow as well
    - prob is required to be [0, 10000] and if m_val is near the max_count,
    it can overflow even with multiplications by 8.

    2024-03-28  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/112303
            * profile-count.h (profile_count::operator+): Perform
            addition in uint64_t variable and set m_val to MIN of that
            val and max_count.
            (profile_count::operator+=): Likewise.
            (profile_count::operator-=): Formatting fix.
            (profile_count::apply_probability): Use safe_scale_64bit
            even in the int overload.

            * gcc.c-torture/compile/pr112303.c: New test.

    (cherry picked from commit d5a3b4afcdf4d517334a2717dbb65ae0d2c26507)