[LLVMbugs] [Bug 18775] New: Miscompile with -D_FORTIFY_SOURCE=2 on Ubuntu 13.10

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=18775

            Bug ID: 18775
           Summary: Miscompile with -D_FORTIFY_SOURCE=2 on Ubuntu 13.10
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: kcc at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Building Chrome on Ubuntu 13.10 using fresh clang leads to a miscompile
(infinite loop) around the call to read(). 
https://code.google.com/p/chromium/issues/detail?id=341809

Here is a preprocessed reproducer:

extern "C" {
  extern long __read_chk (int __fd, void *__buf, unsigned long __nbytes,
      unsigned long __buflen) __attribute__ ((__warn_unused_result__));
  extern long __read_alias (int __fd, void *__buf, unsigned long __nbytes)
    __asm__ ("" "read") __attribute__ ((__warn_unused_result__));
  extern long __read_chk_warn (int __fd, void *__buf, unsigned long __nbytes,
      unsigned long __buflen) __asm__ ("" "__read_chk") 
    __attribute__ ((__warn_unused_result__)) ;
  extern __inline __attribute__ ((__always_inline__))
    long read (int __fd, void *__buf, unsigned long __nbytes)
    {
      if (__builtin_object_size (__buf, 0) != (unsigned long) -1)
      {
        //  if (!__builtin_constant_p (__nbytes))
        //    return __read_chk (__fd, __buf, __nbytes, __builtin_object_size
(__buf, 0));
        if (__nbytes > __builtin_object_size (__buf, 0))
          return __read_chk_warn (__fd, __buf, __nbytes, __builtin_object_size
(__buf, 0));
      }
      return __read_alias (__fd, __buf, __nbytes);
    }
  extern int *__errno_location (void) throw () __attribute__ ((__const__));
}

void  ReadFromFD(int fd, char* buffer, unsigned long bytes) {
  read(fd, buffer, bytes);
}


% clang++ -O2 -c a.cc && objdump -d a.o  
0000000000000000 <_Z10ReadFromFDiPcm>:
   0:    eb fe                    jmp    0 <_Z10ReadFromFDiPcm>

For some reason, the call to read() transforms into "jmp 0",
i.e. an infinite loop.
Maybe clang treats the call to __read_alias as a recursive call to itself
(due to __asm__ ("" "read")???).
But gcc compiles this code correctly: 
0000000000000000 <_Z10ReadFromFDiPcm>:
   0:    e9 00 00 00 00           jmpq   5 <_Z10ReadFromFDiPcm+0x5>


Looking at the final IR: 
define void @_Z10ReadFromFDiPcm(i32 %fd, i8* %buffer, i64 %bytes) #0 {
entry:
  %0 = tail call i64 @llvm.objectsize.i64.p0i8(i8* %buffer, i1 false)
  %cmp.i = icmp ne i64 %0, -1
  %cmp1.i = icmp ult i64 %0, %bytes
  %or.cond.i = and i1 %cmp.i, %cmp1.i
  br i1 %or.cond.i, label %read.exit.split, label %tailrecurse.i

tailrecurse.i:                                    ; preds = %entry,
%tailrecurse.i
  br label %tailrecurse.i

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ infinite loop ^^^^^^^^^^^^^^^

read.exit.split:                                  ; preds = %entry
  %call.i = tail call i64 @__read_chk(i32 %fd, i8* %buffer, i64 %bytes, i64 %0)
  ret void
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140208/560173cb/attachment.html>