I understand your point and I agree that the optimization might make
sense. The problem is that my version of sparse gives different results.
parser_check:
.L0xb7ef00ac:
<entry-point>
br %arg1, .L0xb7ef019c, ****.L0xb7ef014c****
.L0xb7ef019c:
load.32 %r3 <- 4[%arg1]
br %r3, .L0xb7ef0124, .L0xb7ef014c
.L0xb7ef0124:
phisrc.1 %phi1 <- $0
br .L0xb7ef0174
****.L0xb7ef014c:****
load.32 %r5 <- 0[%arg1]
setgt.32 %r7 <- %r5, %arg2
phisrc.1 %phi2 <- %r7
br .L0xb7ef0174
.L0xb7ef0174:
phi.1 %r8 <- %phi1, %phi2
setgt.32 %r10 <- %arg2, $0
and-bool.1 %r11 <- %r8, %r10
br %r11, .L0xb7ef00d4, .L0xb7ef00fc
.L0xb7ef00d4:
call execute_a, %arg1, %arg2
br .L0xb7ef01c4
.L0xb7ef00fc:
call execute_b, %arg1
br .L0xb7ef01c4
.L0xb7ef01c4:
ret
Above, you can see that the execution will segfault within the label
.L0xb7ef014c, on load 0[%arg1].
So my question is: do you have any code that is not committed to
git.kernel.org?
Jacek
--
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
