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]
This is not a regression, oh and this is much harder to get right which is why this is a "may"/"might"
if (!e1) if(k1<1111)
if (n1 <0)
if (!e2) if(k2<1111)
if (n2 <0)
if (n1 < 0 || n2 < 0)
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.