[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #18 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[law at gcc dot gnu.org]

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

--- Comment #17 from Jeffrey A. Law  ---
Author: law
Date: Fri Dec 15 22:35:51 2017
New Revision: 255731

URL: https://gcc.gnu.org/viewcvs?rev=255731=gcc=rev
Log:
PR tree-optimization/36550
* tree-ssa-threadupdate.c (count_stmts_and_phis_in_block): New.
(mark_threaded_blocks): Rewrite code to avoid block copying when
optimizing for size.  Don't pessimize blocks which will be
copied, but all the statements will be dead.

PR tree-optimization/36550
* gcc.dg/tree-ssa/pr36550.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr36550.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||joel at gcc dot gnu.org

--- Comment #16 from Jeffrey A. Law  ---
*** Bug 63224 has been marked as a duplicate of this bug. ***

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #15 from Jeffrey A. Law  ---
Note that Os throttles jump threading as jump threading often increases
codesize.  

That's why you get this warning at -Os, but not at -O2.Jump threading does
not have a good way to estimate how much of the duplicated block will be
eliminated as dead code.

In this testcase, the contents of the duplicated block would be entirely
eliminated as dead code making threading jumps 100% free from a codesize
standpoint.

That's where I think the focus is better spent (rather than adding additional
cases to tree-ssa-uninit.c).  Improve the jump threading heuristics -- the net
result will be better code *and* the warning goes away as a side effect.

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez  ---
Predicate analysis is not able to figure out this case because it cannot see
that the default def is also conditional on cond1_8(D) != 0, thus warn_15 is
never warn_5(D)(13). 

(The callgraph is also a bit of a mess).

This case seems easier to fix, but still would need someone to figure out how
to evaluate and combine the predicates for default defs.


[WORKLIST]: add to initial list: warn_15 = PHI 
[CHECK]: examining phi: warn_15 = PHI 

[CHECK] Found def edge 1 in warn_15 = PHI 
[BEFORE SIMPLICATION -- [USE]:
warn_16 = PHI 
is guarded by :

cond2_4(D) != 0


[BEFORE NORMALIZATION --[USE]:
warn_16 = PHI 
is guarded by :

cond2_4(D) != 0


[AFTER NORMALIZATION -- [USE]:
warn_16 = PHI 
is guarded by :

cond2_4(D) != 0

[BEFORE SIMPLICATION -- [DEF]:
warn_15 = PHI 
is guarded by :

cond2_4(D) != 0 (.AND.) cond1_8(D) != 0


[BEFORE NORMALIZATION --[DEF]:
warn_15 = PHI 
is guarded by :

cond2_4(D) != 0 (.AND.) cond1_8(D) != 0


[AFTER NORMALIZATION -- [DEF]:
warn_15 = PHI 
is guarded by :

cond1_8(D) != 0 (.AND.) cond2_4(D) != 0


[CHECK]: Found unguarded use: warn_16 = PHI 
[WORKLIST]: Update worklist with phi: warn_16 = PHI 
[CHECK]: examining phi: warn_16 = PHI 
[CHECK]: Found unguarded use: a = warn_16;

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[rootkit85 at yahoo dot it]

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

rootkit85 at yahoo dot it  changed:

   What|Removed |Added

 CC||rootkit85 at yahoo dot it

--- Comment #13 from rootkit85 at yahoo dot it  ---
can it be the same as this bug I'm experimenting?

/*/
/*
 * compile with:
 * gcc -Wall -Werror -Os -c test.c -o test.o
 */

int a;
int b;

void warn_func(int cond1, int cond2)
{
int warn;

if (cond2)
warn = a;

if (cond1)
b = 1;

if (cond2)
a = warn;
}
/*/

I can reproduceit only with -Os, and it makes libgo compilation fail because of
this:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgo/runtime/mprof.goc#l403

[Bug middle-end/36550] Wrong may be used uninitialized warning (conditional PHIs)

[vincent.riviere at freesbee dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

--- Comment #12 from Vincent Riviere vincent.riviere at freesbee dot fr 
2011-04-17 22:17:35 UTC ---
Created attachment 24023
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24023
Very simple testcase

I hit the may be used uninitialized in this function bug when compiling this
small testcase. I think it is the same as the bug described here.

$ gcc -c bug.c -Os -Wuninitialized
bug.c: In function 'f':
bug.c:9: warning: 'b' may be used uninitialized in this function

This happens with:
- GCC 4.4.5 (Debian 4.4.5-8) for the target i486-linux-gnu
- GCC 4.5.2 for the target m68k-atari-mint

[Bug middle-end/36550] Wrong may be used uninitialized warning (conditional PHIs)

[davidxl at gcc dot gnu dot org]

--- Comment #11 from davidxl at gcc dot gnu dot org  2010-04-20 23:55 
---
(In reply to comment #2)
 (In reply to comment #1)
  check() can return 1 on the first call and 0 on the second and if *argv is 
  NULL
  then then bug will be used uninitialized.
 
 right, but this doesn't matter here. Better testcase:
 
 /* { dg-do compile } */
 /* { dg-options -Os -Wuninitialized } */
 void bail(void) __attribute__((noreturn));
 unsigned once(void);
 int pr(char**argv)
 {
 char *bug;
 unsigned check = once();
 if (check) {
 if (*argv)
 bug = *++argv;
 } else {
 bug = *argv++;
 if (!*argv)
 bail();
 }
 /* now bug is set except if (check  !*argv) */
 if (check) {
 if (!*argv)
 return 0;
 }
 /* if we ever get here then bug is set */
 return *bug != 'X';
 }
 


The example is a little tricky for the compiler to reason because of the
'++argv'. Predicate analysis
(http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00706.html -- with additional fix
to a never return handling) will catch the following case (while the trunk gcc
does not):


void bail(void) __attribute__((noreturn));
int foo(void);
unsigned once(void);
int pr(char**argv)
{
char *bug;
unsigned check = once();
char * a = *argv;
if (check) {
if (a)
bug = *++argv;
} else {
bug = *argv++;
if (!*argv)
bail();
}

if (foo ())
  once();

/* now bug is set except if (check  !*argv) */
if (check) {
if (!a || !*argv)
return 0;
}
/* if we ever get here then bug is set */
return *bug != 'X';
}


-- 

davidxl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||davidxl at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

[Bug middle-end/36550] Wrong may be used uninitialized warning (conditional PHIs)

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2009-02-12 11:22 ---
*** Bug 39133 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||corinl at gmx dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

[Bug middle-end/36550] Wrong may be used uninitialized warning (conditional PHIs)

[corinl at gmx dot de]

--- Comment #9 from corinl at gmx dot de  2009-02-12 21:53 ---
I do not really understand problem 5 for the case when the only dependancy for
the code-path check is a local variable. In this case the value cannot be
change by any other code than existing between the two checks, so this case
should be handled reliable for sure. Of course this is not possible with global
oder class variables which might be affected by some other thread.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

[Bug middle-end/36550] Wrong may be used uninitialized warning (conditional PHIs)

[manu at gcc dot gnu dot org]

--- Comment #10 from manu at gcc dot gnu dot org  2009-02-12 22:05 ---
(In reply to comment #9)
 I do not really understand problem 5 for the case when the only dependancy for
 the code-path check is a local variable. In this case the value cannot be
 change by any other code than existing between the two checks, so this case
 should be handled reliable for sure.

Should? I guess you meant could. Because it is obviously not handled right
now at the moment of warning.

That page simply lists causes, testcases and possible solutions for existing
problems. As always, contributions are welcome.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

[Bug middle-end/36550] Wrong may be used uninitialized warning (conditional PHIs)

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2009-02-07 15:05 ---
*** Bug 27289 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fnf at specifix dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

[Bug middle-end/36550] Wrong may be used uninitialized warning (conditional PHIs)

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-02-04 00:09 ---
*** Bug 39088 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||av1474 at comtv dot ru


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

[Bug middle-end/36550] Wrong may be used uninitialized warning (conditional PHIs)

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-11-06 21:11 ---
*** Bug 38037 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||edwintorok at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

[Bug middle-end/36550] Wrong may be used uninitialized warning (conditional PHIs)

[manu at gcc dot gnu dot org]

-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-18 17:29:25
   date||
Summary|Wrong may be used  |Wrong may be used
   |uninitialized warning  |uninitialized warning
   ||(conditional PHIs)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550