ASan allows incorrect reordering of memory accesses about address-sanitizer HOT 5 CLOSED

How did you find it? Do you have a source reproducer? 

I was just debugging a (non-existing) hang in Chrome.
I have a repro of ~300 lines that produces almost the same code:


     1b7:       8b 44 24 1c             mov    0x1c(%esp),%eax
     1bb:       8d 80 69 35 02 00       lea    0x23569(%eax),%eax
     1c1:       89 c1                   mov    %eax,%ecx
     1c3:       c1 e9 03                shr    $0x3,%ecx
     1c6:       8a 89 00 00 00 20       mov    0x20000000(%ecx),%cl
     1cc:       8b 94 24 c0 01 00 00    mov    0x1c0(%esp),%edx

, which corresponds to the following assembly:

Ltmp14:
LBB0_3:                                 ## %if.else
  ##DEBUG_VALUE: PostMainMessageLoopStart:this <- EBP+4294967295
  .loc  2 214 0                 ## browser.ii:214:0
  movl  %esi, %eax
  shrl  $3, %eax
  movb  536870912(%eax), %al
  testb %al, %al
  jne LBB0_32
LBB0_4:
  ##DEBUG_VALUE: PostMainMessageLoopStart:this <- EBP+4294967295
  movl  28(%esp), %eax          ## 4-byte Reload
  leal  __ZN12_GLOBAL__N_123g_shutdown_pipe_read_fdE-L0$pb(%eax), %eax
  movl  %eax, %ecx
  shrl  $3, %ecx
  movb  536870912(%ecx), %cl
  movl  448(%esp), %edx
Ltmp15:
  ##DEBUG_VALUE: ShutdownDetector:shutdown_fd <- EDX+0 
  ##DEBUG_VALUE: ShutdownDetector:shutdown_fd <- EDX+0 
  ##DEBUG_VALUE: CheckNEImpl:v1 <- EDX+0 
  ##DEBUG_VALUE: CheckNEImpl:v1 <- EDX+0 
  testb %cl, %cl
  je  LBB0_6


But I'm not completely sure now that "movb  536870912(%ecx), %cl" and "movl  
448(%esp), %edx" access the shadow and the client memory for the same address.

So, there is not bug here, right? 

Not sure yet. Let us leave this as an invalid bug, but keep in mind that we may 
miss  a bug someday because of this.

Adding Project:AddressSanitizer as part of GitHub migration.