[LLVMbugs] [Bug 11470] New: clang incorrectly marks all return slot parameters as noalias

[bugzilla-daemon at llvm.org]

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

             Bug #: 11470
           Summary: clang incorrectly marks all return slot parameters as
                    noalias
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: miscompilation
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu,
                    nicholas at mxc.ca
    Classification: Unclassified


Consider the following:


struct foo { int a, b; double c, d, e; };
extern foo x;
foo f() { return { 1, x.a }; }
foo x = f();


Depending on what copy elision happens, x is initialized as either {1,0} or
{1,1}. With the double members in struct foo, we elide all the copies and an
-O0 build initializes x as {1,1}. (Without the double members, we return as i64
and get the resulting value {1,0}). However, we define f as:

define void @_Z1fv(%struct.foo* noalias sret %agg.result) nounwind uwtable {   

This is wrong! %agg.result is not noalias. This results in us incorrectly
assuming the write to %agg.result.a and the read of @x.a do not alias, and
producing the result {1,0}. This coincidentally happens to be a legal outcome
in this case, but not in general.

Another example:


struct bar {
  bar(bar *o) : ok(true) {
    o->ok = false;
    if (!ok)
      ok = true;
  }

  bool ok;
  double make, it, bigger;
};

bar f(bar *p) {
  return p;
}

int main() {
  bar self_reference = f(&self_reference);
  return !self_reference.ok;
}


In a compliant compiler, main must always return 0, whether we elide the copies
or not. But in clang at -O3, it returns 1! This is again because we've
incorrectly marked the return slot in bar as noalias.

Note that, while the above initializations have undefined behaviour for const
objects, by C++11[class.ctor]p14, I believe they have well-defined behaviour in
these cases, since the objects are not const.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.