Hello, <div><br></div><div>We've just got a bug report from Mozilla folks about AddressSanitizer false positive with -O2.</div><div>Turns out there is a conflict between load widening and AddressSanitizer. </div><div><br>
</div><div>Simple reproducer: </div><div><pre style="font-size:12px;white-space:pre-wrap;max-width:80em;padding-left:0.7em;background-color:rgb(255,255,255)">% cat load_widening.c && echo ========= && clang  -O2  -c  load_widening.c -flto && llvm-dis load_widening.o && cat load_widening.o.ll 
void init(char *);
int foo() {
  char a[22];
  init(a);
  return a[16] + a[21];
}
=========
; ModuleID = 'load_widening.o'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i32 @foo() nounwind uwtable {
entry:
  %a = alloca [22 x i8], align 16
  %arraydecay = getelementptr inbounds [22 x i8]* %a, i64 0, i64 0
  call void @init(i8* %arraydecay) nounwind
  %arrayidx = getelementptr inbounds [22 x i8]* %a, i64 0, i64 16
  %0 = bitcast i8* %arrayidx to i64*
  %1 = load i64* %0, align 16 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  %2 = trunc i64 %1 to i32
  %sext = shl i32 %2, 24
  %conv = ashr exact i32 %sext, 24
  %3 = lshr i64 %1, 16
  %.tr = trunc i64 %3 to i32
  %sext3 = ashr i32 %.tr, 24
  %add = add nsw i32 %sext3, %conv
  ret i32 %add
}
</pre></div><div><br></div><div>Here, the load widening replaces two 1-byte loads with one 8-byte load which partially goes out of bounds. </div><div>Since the array is 16-byte aligned, this transformation should never cause problems in regular compilation, </div>
<div>but it causes AddressSanitizer false positives because the generated load *is* in fact out of bounds.</div><div><br></div><div>Do we consider the above transformation legal? </div><div>If yes, can we disable load widening when AddressSanitizer is enabled? How? </div>
<div><br></div><div>This problem is a bit similar to <a href="http://llvm.org/bugs/show_bug.cgi?id=11376">http://llvm.org/bugs/show_bug.cgi?id=11376</a>, but that time there was an obvious bug in LLVM. </div><div>More info: <a href="http://code.google.com/p/address-sanitizer/issues/detail?id=20">http://code.google.com/p/address-sanitizer/issues/detail?id=20</a></div>
<div><br></div><div>Thanks, </div><div><br></div><div>--kcc </div><div><br></div>