[Bug c/109934] New: Wrong code at -O3 on x86_64-linux-gnu

[Bug c/109934] New: Wrong code at -O3 on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 109934
           Summary: Wrong code at -O3 on x86_64-linux-gnu
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

For the following code, gcc trunk at -O3 emits wrong code.

Compiler explorer: https://godbolt.org/z/3E8xf69rP

$ cat a.c
int printf(const char *, ...);
short a;
long b = 3, c;
int d(int e) {
  switch (e)
  case 111:
  case 222:
  case 44:
    return 0;
  return e;
}
int main() {
  for (; a >= 0; --a)
    if (d(c + 23) - 23)
      b = 0;
  printf("%d\n", (int)b);
}
$
$ gcc-tk -O0 a.c && ./a.out
3
$ gcc-tk -O3 a.c && ./a.out
0
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-c09471fbc7588db2480f036aa56a2403d3c03ae5/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-c09471fbc7588db2480f036aa56a2403d3c03ae5
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230521 (experimental) (GCC)
$

[Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
            Summary|Wrong code at -O3 on        |[14 Regression] Wrong code
                   |x86_64-linux-gnu            |at -O3 on x86_64-linux-gnu
   Last reconfirmed|                            |2023-05-22
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org
   Target Milestone|---                         |14.0
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r14-862-g76e11280e79c5dd5089c17d5726cae9a5a21bc2e

[Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com
           Assignee|unassigned at gcc dot gnu.org      |aldyh at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Woah...this is a latent bug in irange::invert that seems to have been here for
a very long time.

In the loop unswitching code we do:

    false_range = true_range;
    if (!false_range.varying_p ()
        && !false_range.undefined_p ())
      false_range.invert ();

...and get the false_range all wrong:

(gdb) p debug(false_range)
[irange] unsigned int [44, 44][111, 111][222, 222] NONZERO 0xff
$40 = void
(gdb) n
(gdb) n
(gdb) n
(gdb) n
(gdb) p debug(false_range)
[irange] unsigned int [44, +INF]

In no universe is the inverse of the false_range equal to [44, +INF].  Whoops.

This craziness happens here:

  if (m_num_ranges == m_max_ranges
      && lower_bound () != type_min
      && upper_bound () != type_max)
    {
      m_base[1] = type_max;
      m_num_ranges = 1;
      return;
    }

I have no idea what we were trying to do here, but it's clearly wrong.  This
probably never triggered because the old legacy code didn't use this code, and
the new code used int_range<255> (int_range_max) which made it extremely
unlikely this would ever trigger.

[Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 55140
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55140&action=edit
untested patch in testing

[Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

https://gcc.gnu.org/g:8d5f050dabbf6dd3b992c3b46661848dbcf30d9e

commit r14-1133-g8d5f050dabbf6dd3b992c3b46661848dbcf30d9e
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Tue May 23 12:34:45 2023 +0200

    Remove buggy special case in irange::invert [PR109934].

    This patch removes a buggy special case in irange::invert which seems
    to have been broken for a while, and probably never triggered because
    the legacy code was handled elsewhere, and the non-legacy code was
    using an int_range_max of int_range<255> which made it extremely
    likely for num_ranges == 255.  However, with auto-resizing ranges,
    int_range_max will start off at 3 and can hit this bogus code in the
    unswitching code.

            PR tree-optimization/109934

    gcc/ChangeLog:

            * value-range.cc (irange::invert): Remove buggy special case.

    gcc/testsuite/ChangeLog:

            * gcc.dg/tree-ssa/pr109934.c: New test.

[Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

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

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
fixed.  Thanks for reporting.