<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 12/16/11 2:19 PM, John Criswell wrote:
    <blockquote cite="mid:4EEBA7EE.3090208@illinois.edu" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      On 12/16/11 12:24 PM, Kostya Serebryany wrote:
      <blockquote
cite="mid:CAN=P9pjeUaOPpnX57w3+Bzpin3rUCi5i0CgL8Cy83438-_0-Gw@mail.gmail.com"
        type="cite"> 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>
      </blockquote>
      <br>
      SAFECode would have the same problem on this code as it now checks
      for loads and stores that "fall off" the beginning or end of a
      memory object.<br>
      <br>
      <blockquote
cite="mid:CAN=P9pjeUaOPpnX57w3+Bzpin3rUCi5i0CgL8Cy83438-_0-Gw@mail.gmail.com"
        type="cite">
        <div><br>
        </div>
        <div>Do we consider the above transformation legal? <br>
        </div>
      </blockquote>
      <br>
      I would argue that it should not be legal.  We don't actually know
      what comes after the 22 byte object.  Is it another memory
      object?  A memory-mapped I/O device?  Unmapped memory?  Padded
      junk space?  Reading memory-mapped I/O could have nasty side
      effects, and accessing unmapped memory could cause the program to
      fault even though it was written correctly as the source-language
      level.<br>
    </blockquote>
    <br>
    Sorry.  Typo.  I meant to write  "at the source-language level."<br>
    <br>
    -- John T.<br>
    <br>
    <blockquote cite="mid:4EEBA7EE.3090208@illinois.edu" type="cite"> <br>
      While some may consider these sorts of scenarios to be unlikely,
      consider the possibility that the alloca is transformed into a
      global variable or heap allocation.  That would be a legitimate
      transform and makes the above scenarios more likely.<br>
      <br>
      -- John T.<br>
      <br>
      <br>
      <blockquote
cite="mid:CAN=P9pjeUaOPpnX57w3+Bzpin3rUCi5i0CgL8Cy83438-_0-Gw@mail.gmail.com"
        type="cite">
        <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 moz-do-not-send="true"
            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 moz-do-not-send="true"
            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>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
LLVM Developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>