[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]
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]
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]
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&root=gcc&view=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]
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]
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]
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]
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]
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]
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 *)&Msg][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 *)&Msg][0]; [local count: 214748364]: # num_2 = PHI <1(2), 0(3)> # cstore_4 = PHI MEM [(void *)&Msg][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]
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]
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