[Bug tree-optimization/116420] New: wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu

[Bug tree-optimization/116420] New: wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 116420
           Summary: wrong code at -O{2,3} with "-fno-forward-propagate
                    -fno-tree-ch" on x86_64-linux-gnu
           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 as it doesn't reproduce with 14.* and
earlier. 

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


[524] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.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 15.0.0 20240819 (experimental) (GCC) 
[525] % 
[525] % gcctk -O2 small.c; ./a.out
[526] % 
[526] % gcctk -O2 -fno-forward-propagate -fno-tree-ch small.c
[527] % ./a.out
Aborted
[528] % cat small.c
int a, d, e;
char b = -1, c, f;
int main() {
  int g;
  for (; d < 1; d++) {
    g = b;
    for (; c; c = g)
      ;
  }
  f = g;
  for (; e < 1; e++)
    if (g >= a)
      __builtin_abort();
  return 0;
}

[Bug tree-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|wrong code at -O{2,3} with  |[15 Regression] wrong code
                   |"-fno-forward-propagate     |at -O{2,3} with
                   |-fno-tree-ch" on            |"-fno-forward-propagate
                   |x86_64-linux-gnu            |-fno-tree-ch" on
                   |                            |x86_64-linux-gnu
             Target|                            |x86_64-linux-gnu
   Target Milestone|---                         |15.0

[Bug tree-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |law at gcc dot gnu.org
   Last reconfirmed|                            |2024-08-19
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. -fno-ext-dce makes the failure go away.

[Bug rtl-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug rtl-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |law at gcc dot gnu.org

--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So what's really interesting here is it appears that we're not queuing preds of
the current block for reprocessing during the liveness computation.  But it
seems to be specific to a particular pred/succ in a given loop -- the other
loop seems to iterate and reach a fixed point just fine.  Weird.  But
definitely mine.

[Bug rtl-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Fun.

The DF framework provides us a way to run dataflow problems on sub-graphs. 
Naturally a bitmap of interesting blocks is passed into those routines.   At a
confluence point, the DF framework will not mark a block for re-processing if
it's not in that set of interesting blocks.

When ext-dce sets up that set of interesting blocks it's using the wrong
counter.  ie, it's using n_basic_blocks rather than last_basic_block.  If there
are holes in the block indices, some number of blocks won't get marked as
interesting.

In this case the block needing reprocessing has an index higher than
n_basic_blocks.  It never gets reprocessed and the newly found live chunks
don't propagate further up the CFG -- ultimately resulting in a pseudo
appearing to have only the low 8 bits live, when in fact the low 32 bits are
actually live.

Testing a pretty obvious fix.

[Bug rtl-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:

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

commit r15-3095-gc9377734b798d8d311dfd3a5618dc49407703b93
Author: Jeff Law <jlaw@ventanamicro.com>
Date:   Thu Aug 22 12:48:49 2024 -0600

    [PR rtl-optimization/116420] Fix interesting block bitmap DF dataflow

    The DF framework provides us a way to run dataflow problems on sub-graphs.
    Naturally a bitmap of interesting blocks is passed into those routines.  
At a
    confluence point, the DF framework will not mark a block for re-processing
if
    it's not in that set of interesting blocks.

    When ext-dce sets up that set of interesting blocks it's using the wrong
    counter.  ie, it's using n_basic_blocks rather than last_basic_block.  If
there
    are holes in the block indices, some number of blocks won't get marked as
    interesting.

    In this case the block needing reprocessing has an index higher than
    n_basic_blocks.  It never gets reprocessed and the newly found live chunks
    don't propagate further up the CFG -- ultimately resulting in a pseudo
    appearing to have only the low 8 bits live, when in fact the low 32 bits
are
    actually live.

    Fixed in the obvious way, by using last_basic_block instead.

    Bootstrapped and regression tested on x86_64.  Pushing to the trunk.

            PR rtl-optimization/116420
    gcc/
            * ext-dce.cc (ext_dce_init): Fix loop iteration when setting up the
            interesting block for DF to analyze.

    gcc/testsuite
            * gcc.dg/torture/pr116420.c: New test.

[Bug rtl-optimization/116420] [15 Regression] wrong code at -O{2,3} with "-fno-forward-propagate -fno-tree-ch" on x86_64-linux-gnu

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

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

--- Comment #5 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Fixed on the trunk.