[Bug tree-optimization/110971] New: ICE on valid code at -O3 on x86_64-linux-gnu: in operator/, at sreal.cc:261

[Bug tree-optimization/110971] New: ICE on valid code at -O3 on x86_64-linux-gnu: in operator/, at sreal.cc:261

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 110971
           Summary: ICE on valid code at -O3 on x86_64-linux-gnu: in
                    operator/, at sreal.cc:261
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

Compiler Explorer: https://godbolt.org/z/een8566xd

[532] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230810 (experimental) (GCC)
[533] %
[533] % gcctk -O3 small.c
during GIMPLE pass: lsplit
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in operator/, at sreal.cc:261
    2 | int main() {
      |     ^~~~
0x7e52f5 sreal::operator/(sreal const&) const
        ../../gcc-trunk/gcc/sreal.cc:261
0x7e52f5 sreal::operator/(sreal const&) const
        ../../gcc-trunk/gcc/sreal.cc:259
0x118e47b split_loop
        ../../gcc-trunk/gcc/tree-ssa-loop-split.cc:719
0x118ed4b tree_ssa_split_loops
        ../../gcc-trunk/gcc/tree-ssa-loop-split.cc:1769
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[534] %
[534] % cat small.c
int a, b, c, d;
int main() {
  for (a = 0; a < 2; a++) {
    if (b > 2)
      c = 0;
    if (b > a)
      d = 0;
  }
  return 0;
}

[Bug tree-optimization/110971] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in operator/, at sreal.cc:261

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE on valid code at -O3 on |[14 Regression] ICE on
                   |x86_64-linux-gnu: in        |valid code at -O3 on
                   |operator/, at sreal.cc:261  |x86_64-linux-gnu: in
                   |                            |operator/, at sreal.cc:261
   Target Milestone|---                         |14.0

[Bug tree-optimization/110971] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in operator/, at sreal.cc:261

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The problem here is that the split conditional is predicted with probability 0:

  if (b.0_1 > a.4_14)
    goto <bb 5>; [0.00%]
  else
    goto <bb 6>; [100.00%]

this is caused by jump threading;

  <bb 2> [local count: 118111600 freq: 1.000000]:
  a = 0;
  goto <bb 8>; [100.00%]

  <bb 3> [local count: 955630224 freq: 8.090909]:
  b.0_1 = b;
  if (b.0_1 > 2)
    goto <bb 4>; [50.00%]
  else
    goto <bb 5>; [50.00%]

  <bb 4> [local count: 477815112 freq: 4.045455]:
  c = 0;

  <bb 5> [local count: 955630224 freq: 8.090909]:
  if (b.0_1 > a.4_3)
    goto <bb 6>; [50.00%]
  else
    goto <bb 7>; [50.00%]

  <bb 6> [local count: 477815112 freq: 4.045455]:
  d = 0;

  <bb 7> [local count: 955630224 freq: 8.090909]:
  _2 = a.4_3 + 1;
  a = _2;

  <bb 8> [local count: 1073741824 freq: 9.090909]:
  a.4_3 = a;
  if (a.4_3 <= 1)
    goto <bb 3>; [89.00%]
  else
    goto <bb 9>; [11.00%]

So since b>2 implies a>2 we correctly thread but because both conditionals are
statically predicted with same probability we end up with probability 0.

  <bb 2> [local count: 118111600 freq: 1.000000]:
  a = 0;
  goto <bb 8>; [100.00%]

  <bb 3> [local count: 955630224 freq: 8.090909]:
  b.0_1 = b;
  if (b.0_1 > 2)
    goto <bb 4>; [50.00%]
  else
    goto <bb 5>; [50.00%]

  <bb 4> [local count: 477815112 freq: 4.045455]:
  c = 0;
  goto <bb 6>; [100.00%]

  <bb 5> [local count: 477815112 freq: 4.045455]:
  if (b.0_1 > a.4_3)
    goto <bb 6>; [0.00%]
  else
    goto <bb 7>; [100.00%]

  <bb 6> [local count: 477815112 freq: 4.045455]:
  d = 0;

  <bb 7> [local count: 955630224 freq: 8.090909]:
  _2 = a.4_3 + 1;
  a = _2;

  <bb 8> [local count: 1073741824 freq: 9.090909]:
  a.4_3 = a;
  if (a.4_3 <= 1)
    goto <bb 3>; [89.00%]
  else
    goto <bb 9>; [11.00%]


Threading commonly causes such probabilities 0 which may be harmful.
Loop splitting then preconditions the loop:

  <bb 2> [local count: 118111600 freq: 1.000000]:
  b.0_1 = b;
  if (b.0_1 > 0)
    goto <bb 19>; [0.00%]
  else
    goto <bb 20>; [100.00%]

That is bit of nonsence.  Since we expect loop to iterate and since we try to
keep it across preconditioning, we divide by 0.

[Bug tree-optimization/110971] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in operator/, at sreal.cc:261

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Fixed by g:39204ae9ddbfca710880d7f5fda48234a1e85e4e