[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-11-20 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

--- Comment #11 from Dmitry G. Dyachenko  ---
r278496 fix my original problem.
Thank you

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-11-20 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-11-20 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 20 08:26:52 2019
New Revision: 278479

URL: https://gcc.gnu.org/viewcvs?rev=278479=gcc=rev
Log:
PR middle-end/91195
* tree-ssa-phiopt.c (cond_store_replacement): Move lhs unsharing
earlier.  Set TREE_NO_WARNING on the rhs1 of the artificially added
load.

* gcc.dg/pr91195.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr91195.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-07-23 Thread jiangning.liu at amperecomputing dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

Jiangning Liu  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Jiangning Liu  ---
Martin is arguing setting the no-warning bit in middle-end for this scenario is
not a robust solution at
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01525.html.

What about moving the case below to -O3? Could it be acceptable by
-Wmaybe-uninitialized tests?

tree base = get_base_address (lhs);
if (!nontrap->contains (lhs)
&& auto_var_p (base)
&& TREE_ADDRESSABLE (base)
&& optimization_level > 2)
  {
/* Do conditional store replacement by inserting a load. */
  }

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-07-22 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

--- Comment #7 from Jeffrey A. Law  ---
It's inherent in the transformation you're making.  You're introducing loads on
paths where they didn't exist before.

Depending on the exact circumstances you may trigger an uninit warning.  It's
worth nothing that the uninit pass isn't terribly good with memory references
and as a result it's easy to get missed warnings.

You may need to mark the memory loads you generate with TREE_NO_WARNING or
something similar.

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-07-22 Thread jiangning.liu at amperecomputing dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

--- Comment #6 from Jiangning Liu  ---
It seems -Werror=maybe-uninitialized cannot always work, and it fails to report
the error message for the case below. However, the option name is "maybe-xxx",
so I can understand it is OK, but for the same reason, it should be also OK if
we report error message for the original case.

$ cat pr89430-1.c
unsigned test(unsigned k, unsigned b) {
unsigned a[2];
if (b < a[k]) {
a[k] = b;
}
return a[0]+a[1];
}
$ gcc -O2 -S pr89430-1.c -Werror=maybe-uninitialized
$ cat pr89430-1.s
.file   "pr89430-1.c"
.text
.p2align 4
.globl  test
.type   test, @function
test:
.LFB0:
.cfi_startproc
movl%edi, %edi
cmpl%esi, -8(%rsp,%rdi,4)
cmovbe  -8(%rsp,%rdi,4), %esi
movl%esi, -8(%rsp,%rdi,4)
movl-4(%rsp), %eax
addl-8(%rsp), %eax
ret
.cfi_endproc
.LFE0:
.size   test, .-test
.ident  "GCC: (GNU) 10.0.0 20190722 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-07-22 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  ---
Just a comment on c#3.  Warning options are not allowed to change decisions in
the optimizers or code generation.

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-07-22 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

--- Comment #4 from Andrew Pinski  ---
I think the switch statement could be optimized better. There is a loop pass
which already handles if statements for the splitting one loop into two.  Maybe
it could do the same for switch statements.
Or the other thing that could be done here is change the switch statement into
an if statement because there is only one case and the default case.

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-07-21 Thread jiangning.liu at amperecomputing dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

--- Comment #3 from Jiangning Liu  ---
The gcc compilation difference between FOR_UP_LIMIT is 3 and 4 is that,
cunrolli can do loop unrolling when FOR_UP_LIMIT is 3, for which the control
flow can be significantly simplified, so the conditional store optimization in
phiopt will not be triggered.

The following code is generated with conditional store optimization, and
"cstore_8 = MEM  [(void *)][0];" is inserted in the else branch
"if (m1_9(D) != 0B)" statement.

   [local count: 214748364]:
  if (m1_9(D) != 0B)
goto ; [70.00%]
  else
goto ; [30.00%]

   [local count: 64424509]:
  cstore_8 = MEM  [(void *)][0];

   [local count: 214748364]:
  # num_2 = PHI <1(2), 0(3)>
  # cstore_4 = PHI 
  MEM  [(void *)][0] = cstore_4;

The possible solution is to disable this optimization when
"-Werror=maybe-uninitialized" is enabled.

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-07-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jiangning.liu@amperecomputi
   ||ng.com, law at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r273449.

[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]

2019-07-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-18
 Blocks||24639
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The uninit predicate analysis definitely doesn't handle the connection between
num == 0 and !m1.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues