[llvm-bugs] [Bug 42668] New: Clang generates overaligned load of thrown object

[via llvm-bugs]

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

            Bug ID: 42668
           Summary: Clang generates overaligned load of thrown object
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Keywords: ABI, miscompilation
          Severity: normal
          Priority: P
         Component: C++
          Assignee: diogo.sampaio at arm.com
          Reporter: diogo.sampaio at arm.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

For the C++ code:
===
#include <arm_neon.h>

int main(void) {
  try {
    throw vld1q_u64(((const uint64_t[2]){1, 2}));
  } catch (uint64x2_t exc) {
    return 0;
  }
  return 1;
}

====
and command:
clang --target=arm-arm-none-eabi -march=armv8-a -c test_upstream.cpp -o - -Os
-o - -S -emit-llvm
====
we obtain this:
entry:
  %exception = tail call i8* @__cxa_allocate_exception(i32 16) #2
  %0 = bitcast i8* %exception to <2 x i64>*
  store <2 x i64> <i64 1, i64 2>, <2 x i64>* %0, align 16, !tbaa !5
========
Which, passing to llc will generate:
   vld1.64 {d16, d17}, [r1]
   vst1.64 {d16, d17}, [r0:128]  << Not 128, but 64!!!
========

The store assumes an alignment of 16. However, %exception has alignment 64 as
defined in
https://github.com/llvm-mirror/libunwind/blob/master/include/unwind.h
where we have:
struct _Unwind_Exception {
 ...
} __attribute__((__aligned__)); //<< For the ARM ABI the largest alignment is 8
(64 bits).

I do believe that the missing "align 8" in %exception should be the root of the
error, as that should be passed further to %0 and, finally, to the store.

I also believe that clang should not assume data-width alignment when the
pointer is a bitcast from a smaller data-type.

-- 
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/20190718/b455691b/attachment.html>