2010/2/15 Jacek Śliwerski <sliwers@xxxxxxxxxxxxxx>: > > Please, check my case. The condition is: I did, I did not see any thing wrong with it. > > if (st && st->other && st->value > i && i > 0)... > > Obviously, if st is NULL, then the execution should be transferred > immediately to the else branch. But it does not. It skips the second test > and goes directly to the third one: st->value > i. If a compiler was built > with sparse as a frontend, execution of the generated code would end up with > a segmentation fault. And this code is perfectly valid. I totally agree the source code is valid. I just haven't see the seg fault part. $ ./test-linearize parser_check.c parser_check: .L0x7f4e12de3130: <entry-point> br %arg1, .L0x7f4e12de32e0, .L0x7f4e12de3250 .L0x7f4e12de32e0: load.32 %r3 <- 4[%arg1] br %r3, .L0x7f4e12de3208, .L0x7f4e12de3250 .L0x7f4e12de3208: load.32 %r5 <- 0[%arg1] setgt.32 %r7 <- %r5, %arg2 phisrc.1 %phi1 <- %r7 br .L0x7f4e12de3298 .L0x7f4e12de3250: phisrc.1 %phi2 <- $0 br .L0x7f4e12de3298 .L0x7f4e12de3298: phi.1 %r8 <- %phi1, %phi2 setgt.32 %r10 <- %arg2, $0 and-bool.1 %r11 <- %r8, %r10 br %r11, .L0x7f4e12de3178, .L0x7f4e12de31c0 .L0x7f4e12de3178: call execute_a, %arg1, %arg2 br .L0x7f4e12de3328 .L0x7f4e12de31c0: call execute_b, %arg1 br .L0x7f4e12de3328 .L0x7f4e12de3328: ret In the fast test, the false branch is L0x7f4e12de3250. Which is doing the (i > 0) part and it is safe to do so. It skip the two load.32 operation. It will not generate the seg fault. I still don't see where the is seg fault part. Please let me know if I am missing some thing obvious. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
