[LLVMbugs] [Bug 16047] New: Use of unspecified value wrongly optimized to undefined behavior.

[bugzilla-daemon at llvm.org]

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

            Bug ID: 16047
           Summary: Use of unspecified value wrongly optimized to
                    undefined behavior.
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: patrik.h.hagglund at ericsson.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The LLVM optimizers seems to be too aggressive, transforming the use of an
unspecified value into undefined behavior. Consider the following program:

#include <stdio.h>
#include <string.h>
#include <stdbool.h>

int main(void) {

  int *obj; // obj is initialized to an indeterminate value (either an
            // unspecified value or a trap representation) 6.7.9 section 10

  typedef unsigned char byte_t;
  byte_t *begin = (byte_t *)&obj; // 6.3.2.3 section 7
  byte_t *end = begin + sizeof(obj);
  byte_t cbuf[sizeof(obj)];

  // Copy obj, byte by byte, into cbuf.

  // This is the object representation of obj. We only access obj
  // through 'unsigned char'. Therefore, the indeterminate value of obj is now
  // only read as unspecified values (i.e. no undefined behavior).

  // 6.2.6.1 section 4
#if 0
  memcpy(cbuf, &obj, sizeof(obj));
#else
  for (byte_t *ip = begin, *bp = cbuf; ip < end; ++bp, ++ip)
    *bp = *ip;
#endif

  // Check the result.
  // Here, we also only use 'unsigned char'. No undefined behavior.
  bool t = true;
  for (byte_t *ip = begin, *bp = cbuf; ip < end; ++bp, ++ip) {
    t &= *bp == *ip;
    printf("%02x ", *bp);
  }

  printf("\n%d\n", t);

  return 0;
}

Compiling this with clang -std=c11 -O3 (on x86_64) gives SIGSEGV at the first
dereference of ip, despite that this program do not expose any undefined
behavior.

The problem seems to be this IR:
  %ip.039 = phi i8* [ %incdec.ptr1, %for.body ], [ undef, %middle.block ]
  %4 = load i8* %ip.039, align 1, !tbaa !0

(I don't know which optimization pass that produce this 'undef'.)

-- 
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/20130517/bb18a0c8/attachment.html>