Bug 21733 - bogus uninitialized warning (huge testcase)
bogus uninitialized warning (huge testcase)
Status: RESOLVED WORKSFORME
Product: gcc
Classification: Unclassified
Component: middle-end
4.0.1
: P2 normal
: ---
Assigned To: Not yet assigned to anyone
: 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:
Host:
Target:
Build:
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


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

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]
/tmp/filecmp.i.bz2
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" 
warning.
Comment 3 Andrew Pinski 2005-11-26 16:52:58 UTC
k1=k2=0;
e1=e2=0;
for(;;)
{
  if (!e1)  if(k1<1111)
  {
    set n1
    if (n1 <0)
     {
        ....
        break;
     }
  }
  if (!e2)  if(k2<1111)
  {
    set n2
    if (n2 <0)
     {
        ....
        break;
     }
  }
}
...
if (n1 < 0 || n2 < 0)
  return 1;
L1:
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.