Bug 21733 - bogus uninitialized warning (huge testcase)
Summary: bogus uninitialized warning (huge testcase)
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: diagnostic
Depends on: 36296
Blocks: Wuninitialized
  Show dependency treegraph
Reported: 2005-05-24 07:47 UTC by olh
Modified: 2013-11-20 00:49 UTC (History)
5 users (show)

See Also:
Known to work:
Known to fail: 3.3.3, 3.4.0, 4.0.0, 4.1.0
Last reconfirmed: 2009-02-09 15:56:21

/tmp/filecmp.i.bz2 (22.17 KB, application/x-bzip2)
2005-05-24 07:48 UTC, olh

Note You need to log in before you can comment on or make changes to this bug.
Description olh 2005-05-24 07:47:39 UTC
if I understand the code flow in FileCmpCmd correctly,
the first loop will initialize n1 and n2 because e1 = e2 = 0,
and k1 && k2 is always < BSIZE.
Even if the read() will return an error, the last check
to return either TCL_ERROR or TCL_OK is not undefined.

This is from http://ozlabs.org/~paulus/dirdiff-2.1.tar.gz

/usr/lib/gcc/powerpc64-suse-linux/4.0.1/cc1 -fpreprocessed filecmp.i -quiet -dumpbase filecmp.c -auxbase filecmp -O3 -Wall -version -fPIC -o filecmp.s
GNU C version 4.0.1 20050521 (prerelease) (SUSE Linux) (powerpc64-suse-linux)
        compiled by GNU C version 4.0.1 20050521 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
filecmp.c: In function #FileCmpCmd#:
filecmp.c:252: warning: #n2# may be used uninitialized in this function
filecmp.c:252: warning: #n1# may be used uninitialized in this function
Comment 1 olh 2005-05-24 07:48:02 UTC
Created attachment 8957 [details]
Comment 2 Andrew Pinski 2005-05-24 14:29:42 UTC
This is not a regression, oh and this is much harder to get right which is why this is a "may"/"might" 
Comment 3 Andrew Pinski 2005-11-26 16:52:58 UTC
  if (!e1)  if(k1<1111)
    set n1
    if (n1 <0)
  if (!e2)  if(k2<1111)
    set n2
    if (n2 <0)
if (n1 < 0 || n2 < 0)
  return 1;
return 2;

The problem is that "n1 < 0 || n2 < 0" is being executed in one bb and not conditionaly
Comment 4 Andrew Pinski 2006-08-26 03:52:35 UTC
This is not a target specific bug either.
Comment 5 Manuel López-Ibáñez 2008-08-20 11:32:24 UTC
There is some connection with PR 36296 but perhaps they are not exactly the same issue.
Comment 6 Manuel López-Ibáñez 2009-02-09 15:56:20 UTC
This testcase is too big to see clearly what is going on. A reduced testcase would be appreciated (preferably with just 1 function).
Comment 7 Jeffrey A. Law 2013-11-20 00:49:34 UTC
Trunk seems to handle this just fine now.