[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu

2023-07-31 Thread amacleod at redhat dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582

Andrew Macleod  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Andrew Macleod  ---
There was a bug in the implementation of fur_list where it was using the
supplied values for *any* encountered operand, not just ssa_names.   so when
the phi analyzer was trying to find an initial value fro the PHI a_lsm.2_29 it
was miscalculating the value of iftmp.1_15 and thought it had an (incorrect)
limited range of [-2,2].

 # a_lsm.12_29 = PHI 
  iftmp.1_15 = 3 / a_lsm.12_29; 

it then though it could fold away the condition.

The patch adjusts the operand fetcher to work properly, and then the phi
analyzer calcualtes the range for the statement properly, and we can no longer
remove the condtion.

[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu

2023-07-31 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r14-2883-gb769811e7c1b3dff2fa0ec2c37b52859d7bceed4
Author: Andrew MacLeod 
Date:   Mon Jul 31 10:08:51 2023 -0400

fur_list should not use the range vector for non-ssa operands.

gcc/
PR tree-optimization/110582
* gimple-range-fold.cc (fur_list::get_operand): Do not use the
range vector for non-ssa names.

gcc/testsuite/
* gcc.dg/pr110582.c: New.

[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu

2023-07-30 Thread shaohua.li at inf dot ethz.ch via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582

--- Comment #5 from Shaohua Li  ---
Bisect to r14-1179-g1cd5bc387c4

[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu

2023-07-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582

--- Comment #4 from Andrew Pinski  ---
Another testcase:
```
int a, b;
int main() {
  char a = 0;
  int t = 0;
  for (; t <253; t ++){
int d = 2;
d ^= 2 && a;
b = a == 0 ? d : d / a;
a = b;
  }
  for (; (1 + 95 << 24) + b + 1 + 686658714L + b - 2297271457;)
;
}
```

Just to show that you could count up from 0 to 253 and still have an issue
without any wrapping happening in the original code.

[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu

2023-07-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> It works with -fno-tree-loop-optimize but the difference from loop opts is
> just

So changing it to what -ftree-loop-optimize, it still passes with
-fno-tree-loop-optimize (which is even odder):
```
int a, b;
int main() {
  char c = a = 0;
  unsigned char t = 253;
  for (; t != 0; t --){
int d = 2;
d ^= 2 && a;
b = a == 0 ? d : d / a;
a = b;
  }
  for (; (1 + 95 << 24) + b + 1 + 686658714L + b - 2297271457;)
;
}
```

The difference in this case is:
+  unsigned charD.20 ivtmp_32;
+  unsigned charD.20 ivtmp_33;
...
-  # RANGE [irange] unsigned char [1, 253]
-  # t_19 = PHI 
   # .MEM_20 = PHI <.MEM_20(5), .MEM_11(D)(2)>
   # a_lsm.11_2 = PHI 
+  # ivtmp_33 = PHI 

...
-  # RANGE [irange] unsigned char [0, 252]
-  t_16 = t_19 + 255;
-  if (t_16 != 0)
+  ivtmp_32 = ivtmp_33 - 1;
+  if (ivtmp_32 != 0)
```
The only thing I can of which might be causing the issue is +255 vs -1 here.

[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu

2023-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||amacleod at redhat dot com

--- Comment #2 from Richard Biener  ---
It works with -fno-tree-loop-optimize but the difference from loop opts is just

 int main ()
 {
   int D.2782;
   int b_lsm.13;
   int a_lsm.12;
   char c;
-  unsigned char c.6_2;
-  unsigned char _3;
   int iftmp.1_11;
   int _12(D);
   int iftmp.1_15;
+  unsigned char ivtmp_36;
+  unsigned char ivtmp_37;
   int _38;
   long int _39;
   long int _40;
@@ -23,8 +21,8 @@
[local count: 10737416]:

[local count: 1063004409]:
-  # c_21 = PHI 
   # a_lsm.12_4 = PHI 
+  # ivtmp_37 = PHI 
   if (a_lsm.12_4 != 0)
 goto ; [50.00%]
   else
@@ -35,10 +33,8 @@

[local count: 1063004409]:
   # iftmp.1_11 = PHI 
-  c.6_2 = (unsigned char) c_21;
-  _3 = c.6_2 + 1;
-  c_18 = (char) _3;
-  if (c_18 != -3)
+  ivtmp_36 = ivtmp_37 - 1;
+  if (ivtmp_36 != 0)
 goto ; [98.99%]
   else

with that indeed threadfull2 miscompiles this somehow.  Andrew?

[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu

2023-07-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Keywords||wrong-code
Summary|Wrong code at -O2/3 on  |[14 Regression] Wrong code
   |x86_64-linux-gnu|at -O2/3 on
   ||x86_64-linux-gnu
   Last reconfirmed||2023-07-07
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |14.0
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
threadfull2 seems to producing the wrong code but I could be wrong.

Confirmed.