What happens if you use the same code in Visual Studio?

If you are right, I would say that there is a bug in the GCC compiler.. and it has probably been there for a super long time.

Back in the day, I had issues with some C/C++ code throwing some weird errors when compiled with GCC but it worked fine when compiled through Visual Studio.

I never looked into what was causing the issue with GCC and just kept using Visual Studio instead.

Some of this is undefined behavior, and some is implementation defined.

In general: do not shift signed ints.

SAR of -1 does not clear the MSB. It copies the sign bit into the next bit, and retains the sign bit.
Also, your comments don't match your code.
SHR EDX, 1F = 1, not 7FFFFFFFF.
and
LEA EAX, [EDX+EAX-1] isn't encoded as 8D 04 02, it's 8D 44 02 FF.

Looking at it again, you're right(1f, so bit 31=result, not bit shifted right by 1, miscounted there(did that one off the top of my head, thus miscounted 32 instead of 31)), cf=1. Then EDX(1)+EAX(ffffffff)+1=1. Then SAR 1 results in 0(and CF=1), thus correct result?

So it's correct, but it requires that extra logic, a simple sar isn't enough(as can be seen(sar -1=>-1 carry 1).

@realnc: That code isn't generated using a signed shift. That code was generated by a simple

1int arithmetic0(x) {return x/2;}

It just looked strange, but it actually isn't.

And it does require extra logic with sar for the extra -1/2=0 result(everything before said opcode, so the val=(val+(val shr 1f)+1)) for the correct divide result.

Edit: It might still go wrong that way if done with bigger powers of 2(SAL still shifts more, thus a repeating cause for troubles).
Edit: Looks like a different algorithm with divide by 4 indeed:

100000050 <arithmetic4>:
2  50:   55                      push   %ebp
3  51:   89 e5                   mov    %esp,%ebp
4  53:   8b 55 08                mov    0x8(%ebp),%edx
5  56:   5d                      pop    %ebp
6; divide by four:
7  57:   89 d0                   mov    %edx,%eax
8  59:   c1 f8 1f                sar    $0x1f,%eax
9  5c:   c1 e8 1e                shr    $0x1e,%eax
10  5f:   01 d0                   add    %edx,%eax
11  61:   c1 f8 02                sar    $0x2,%eax
12; result ready
13  64:   c3                      ret    

Looks like a different algorithm there ((((x sar 1f) shr 1e)+x) sar 2).

So... sar 1f results in -1(negative numbers) or 0(positive numbers). Then, shr 1e results in 3(for negative) or 0(for positive). So it's shifting x by 2 bits for positive or x+3 by 2 bits for negative?