[Python-checkins] r67907 - python/trunk/Modules/_testcapimodule.c

Tue Dec 23 00:36:05 CET 2008

> I wasn't aware of that policy. This is just a backport of a revision
> in the py3k branch.
>
I think the policy goes like this: "Don't add nonsensical code just
to make the compiler happy". If the compiler warning is legitimate,
find a reformulation to make the problem go away. If the compiler
warning is meaningless, try to rewrite it so that the good is still
efficient and clear, but doesn't give the warning; if that is not
possible, ignore the compiler (or turn off its warnings).
>> I don't think there is a way to really test for this bug, but
>> as a starting point, making x global should do the trick.
>> I don't understand the desirability of this over the current change.

See above. With the current code, the compiler could *still*
conclude that x isn't used (it is assigned a value that is never
read, so the assignment could go away; in turn, the prior assignment
can go away).
In fact, for the code
extern int y[100];
void foo(){
 int x = 3 < 10 ? y[3] : -1;
 x = x;
}
gcc 4.3.2 generates with no optimization
foo:
 subl 16,ドル %esp
 movl y+12, %eax
 movl %eax, 12(%esp)
 addl 16,ドル %esp
 ret
With -O2, it emits
foo:
 rep
 ret
As you can see, the reference to y is gone; this makes the
test futile (which tries to test whether the array gets
referenced).
With a global variable, the compiler is less likely
to find out that the write is never read:
foo:
 movl y+12, %eax
 movl %eax, x
 ret
If you want to be sure that the store really happens,
you also need to declare x as volatile.
Regards,
Martin