Re: Defect in linearization of short circuit &&

["Jacek Śliwerski" <sliwers@googlemail.com>]

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