|
From: Julian S. <js...@ac...> - 2009-01-07 17:29:18
|
> I just found a piece of really simple and sensible looking code that
> produces a false positive:
>
> for( i = 0; i < 12; ++i )
> {
> longmonth[i] = NULL;
> shortmonth[i] = NULL;
> }
I can't reproduce this failure, on openSUSE 11.0 (gcc 4.3.1, 64 bit),
compiled -O1 or -O0:
#include <stdio.h>
void* longmonth[12];
void* shortmonth[12];
int main ( void )
{
long i;
for( i = 0; i < 12; ++i )
{
longmonth[i] = NULL;
shortmonth[i] = NULL;
}
return 0;
}
$ vTRUNK --tool=exp-ptrcheck ./months
[...]
==18554== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> The reason, obviously, is that the compiler has reused the same register
> to hold the base address of both arrays - the compiled body of that loop
> looks like this:
>
> 1388e: 8b 45 f4 mov -0xc(%rbp),%eax
> 13891: 48 98 cltq
> 13893: 48 8d 14 c5 00 00 00 lea 0x0(,%rax,8),%rdx
> 1389a: 00
> 1389b: 48 8d 05 7e 22 22 00 lea 0x22227e(%rip),%rax
> # 235b20 <longmonth>
> 138a2: 48 c7 04 02 00 00 00 movq $0x0,(%rdx,%rax,1)
> 138a9: 00
> 138aa: 8b 45 f4 mov -0xc(%rbp),%eax
> 138ad: 48 98 cltq
> 138af: 48 8d 14 c5 00 00 00 lea 0x0(,%rax,8),%rdx
> 138b6: 00
> 138b7: 48 8d 05 c2 22 22 00 lea 0x2222c2(%rip),%rax
> # 235b80 <shortmonth>
> 138be: 48 c7 04 02 00 00 00 movq $0x0,(%rdx,%rax,1)
What the checking does (for these global arrays) is to watch which
arrays the store instructions write into. It doesn't care what value
is in what register -- that's only of interest for heap-allocated arrays.
What it is trying to establish is that the first store ..
> 138a2: 48 c7 04 02 00 00 00 movq $0x0,(%rdx,%rax,1)
> 138a9: 00
always writes the same array (longmonth, presumably) and that the second
store
> 138be: 48 c7 04 02 00 00 00 movq $0x0,(%rdx,%rax,1)
always writes in the same array (shortmonth, presumably). As per
http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.how-works.sg-checks
> The trouble is that if code as simple as that produces a false positive
> then you have to wonder how much people will be prepared to try and wade
> through the warnings?
Absolutely. But I think there's something else going on here. Could you
send a complete test case, + details of gcc, optimisation level, etc,
you used?
J
|