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
Created attachment 8957 [details] /tmp/filecmp.i.bz2
This is not a regression, oh and this is much harder to get right which is why this is a "may"/"might" warning.
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
This is not a target specific bug either.
There is some connection with PR 36296 but perhaps they are not exactly the same issue.
This testcase is too big to see clearly what is going on. A reduced testcase would be appreciated (preferably with just 1 function).
Trunk seems to handle this just fine now.