[llvm-bugs] [Bug 37742] New: struct return mis-compilation in C with escaped address

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37742

            Bug ID: 37742
           Summary: struct return mis-compilation in C with escaped
                    address
           Product: new-bugs
           Version: 3.8
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: travis.downs at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 20403
  --> https://bugs.llvm.org/attachment.cgi?id=20403&action=edit
bugpoint stdout

Consider the following small program:

/*
 * main.c
 */

#include <stdio.h>
#include <stdlib.h>

typedef struct { char x[32]; } Foo;

void sink(void *l, void *r)
{
   puts(l == r ? "equal" : "not equal");
}

Foo make(void *p) {
    Foo f2;
    sink(&f2, p);
    return f2;
}

int main() {
    Foo f1 = make(&f1);
}

Since f1 and f2 are distinct objects, they must also have unequal addresses and
we expect the above to return "not equal". However, on clang 3.8 through trunk
(7ish) it returns "equal" for -O1 and above.

Note that "return f2" is returning an uninitialized struct - but this isn't a
necessary component of the issue (and I don't think its UB anyways): if you put
sink in a separate compilation unit, and call exit(0) after the comparison, the
issue still happens even though we never reach the return of the uninitialized
value. I just used the example above since it is a single-file example (no
doubt you can find some way to get it to work single-file w/o the uninitialized
return).

Bugpoint reports that the miscompiling pass is memcpyopt. The full bugpoint
output is attached.

-- 
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/20180608/d2d87b69/attachment.html>