[llvm-bugs] [Bug 24982] New: Compiler not properly honoring alignment when calling trivial default copy constructor

[via llvm-bugs]

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

            Bug ID: 24982
           Summary: Compiler not properly honoring alignment when calling
                    trivial default copy constructor
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: douglas_yung at playstation.sony.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

After change r246985, the compiler started to emit calls to memcpy that do not
take into account the alignment requirements of the target. Consider the
following code:

/***********/
struct C { float a; float b; float c; float d; } __attribute__((aligned(16)));

typedef C C4 __attribute__((aligned(4)));

C4 c4 = {0.0,1.0,1.0,0.0};

C test4() {
  return c4;
}
/***********/

Prior to change r246985, the compiler generated the following IR for the call
to memcpy:

call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast (%struct.C* @c4 to
i8*), i64 16, i32 16,i1 false)

In this case, note the alignment parameter "i32 16" which is what the target
requires.

However, following the change in r246985 up to the most recent build I have
(r248770), the compiler is now generating an incorrect value for the alignment
for the memcpy call which only seems to take into account the source alignment.
The new IR is the following:

call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast (%struct.C* @c4 to
i8*), i64 16, i32 4, i1 false)

Note that the alignment parameter is now 4 instead of 16 as it was previously.

-- 
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/20150929/e6dfae40/attachment.html>