Bug 97760 - [10 Regression] GCC outputs wrong values when compiling the testcase with -O3 since r10-4200-gb7ff7cef5005721e
Summary: [10 Regression] GCC outputs wrong values when compiling the testcase with -O3...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 11.0
: P2 normal
Target Milestone: 10.3
Assignee: Richard Biener
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2020-11-09 02:58 UTC by yangyang
Modified: 2020-12-01 15:45 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 10.2.1, 11.0, 9.3.0
Known to fail: 10.2.0
Last reconfirmed: 2020-11-09 00:00:00


Attachments
testcase (165 bytes, text/x-csrc)
2020-11-09 03:01 UTC, yangyang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description yangyang 2020-11-09 02:58:48 UTC
Hi, gcc-trunk outputs wrong values when compiling the attached testcase with -O3.


gcc -O0 test.c -w && ./a.out

159,150,150
150

gcc -O3 test.c -w && ./a.out

159,123,123
123

GCC version: 11.0.0 20201106 (experimental)
Comment 1 yangyang 2020-11-09 03:01:38 UTC
Created attachment 49521 [details]
testcase
Comment 2 Martin Liška 2020-11-09 08:13:19 UTC
Confirmed, started with r10-4200-gb7ff7cef5005721e.
Comment 3 Richard Biener 2020-11-09 08:17:16 UTC
Mine.
Comment 4 Richard Biener 2020-11-09 13:38:24 UTC
int b=1;
static int *g = &b;

void __attribute__((noipa))
h (unsigned int n)
{
  int i = 3;
  int f = 3;
  for (; f <= 50; f += 4) {
    i += 4;
    *g = i;
    i += n;
  }
}

int main ()
{
  h (9);
  if (*g != 150 || b != 150)
    __builtin_abort ();
  return 0;
}
Comment 5 Richard Biener 2020-11-09 14:19:21 UTC
t.c:9:12: note:   worklist: examine stmt: i_16 = PHI <i_11(5), 3(2)>
t.c:9:12: note:   vect_is_simple_use: operand (int) _3, type of def: reduction
t.c:9:12: note:   reduc-stmt defining reduc-phi in the same nest.
t.c:9:12: note:   mark relevant 1, live 1: i_11 = (int) _3;

so reduc PHI defs are marked live magically - that's obviously wrong here,
the live stmt is one in the middle of the reduction path (which _is_ marked
live).  What happens is that we generate two vectorized epilogues and depending
on the order we end up with the wrong result in b.

Now, what's _also_ wrong is that we cannot handle this situation since
the epilogue of the middle stmt fails to account for the all-but-the-last
lane effect of the _not_ live stmt.

While the former bug is easy to fix the latter is not.

I have a patch.
Comment 6 GCC Commits 2020-11-10 09:18:04 UTC
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:2686de5617bfb572343933be2883e8274c9735b5

commit r11-4865-g2686de5617bfb572343933be2883e8274c9735b5
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Nov 9 15:19:56 2020 +0100

    tree-optimization/97760 - reduction paths with unhandled live stmt
    
    This makes sure we reject reduction paths with a live stmt that
    is not the last one altering the value.  This is because we do not
    handle this in the epilogue unless there's a scalar epilogue loop.
    
    2020-11-09  Richard Biener  <rguenther@suse.de>
    
            PR tree-optimization/97760
            * tree-vect-loop.c (check_reduction_path): Reject
            reduction paths we do not handle in epilogue generation.
    
            * gcc.dg/vect/pr97760.c: New testcase.
Comment 7 Richard Biener 2020-11-10 09:22:03 UTC
Fixed on trunk sofar.
Comment 8 GCC Commits 2020-12-01 15:44:52 UTC
The releases/gcc-10 branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:7b523f3dff5d7bf49294fe5b794f63cae28d5c5b

commit r10-9102-g7b523f3dff5d7bf49294fe5b794f63cae28d5c5b
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Nov 9 15:19:56 2020 +0100

    tree-optimization/97760 - reduction paths with unhandled live stmt
    
    This makes sure we reject reduction paths with a live stmt that
    is not the last one altering the value.  This is because we do not
    handle this in the epilogue unless there's a scalar epilogue loop.
    
    2020-11-09  Richard Biener  <rguenther@suse.de>
    
            PR tree-optimization/97760
            * tree-vect-loop.c (check_reduction_path): Reject
            reduction paths we do not handle in epilogue generation.
    
            * gcc.dg/vect/pr97760.c: New testcase.
    
    (cherry picked from commit 2686de5617bfb572343933be2883e8274c9735b5)
Comment 9 Richard Biener 2020-12-01 15:45:31 UTC
Fixed.