[llvm-bugs] [Bug 35901] New: Unaligned movaps in virtual base constructor

[via llvm-bugs]

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

            Bug ID: 35901
           Summary: Unaligned movaps in virtual base constructor
           Product: clang
           Version: 5.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: securesneakers at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 19653
  --> https://bugs.llvm.org/attachment.cgi?id=19653&action=edit
Minimal example that reproduces the issue

Issue can be reproduced with attached example:

$ uname -s -m
Linux x86_64

$ clang++ --version
clang version 5.0.0 (tags/RELEASE_500/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ clang++ -std=c++11 -O2 minimal.cpp && ./a.out
Segmentation fault (core dumped)

Example contains class hierarchy similar to this:

struct alignas(16) Base1 { };
struct Base2 : virtual Base1 { };
struct Base3 : virtual Base2 { };

Clang assigns all three types alignment of 16 (alignas(T) equals 16). At the
same time Base2 is placed at offset 8 inside Base3 instance as it should be
according to Itanium ABI:
https://refspecs.linuxfoundation.org/cxxabi-1.75.html. This is due to
requirement that Base2 should be aligned by "non-volatile alignment" or
"nvalign" in ABI spec. So far everything seems to be correct and both Clang and
GCC generate identical layout for Base3.

The problem is that Clang tries to initialize member fields using "movaps"
instruction, using in with 8-byte aligned address, causing segfault. Seems that
optimizer checks "normal" type alignment when making a decision to use
"movaps", when "non-virtual" alignment should be used.

-- 
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/20180111/39b918f9/attachment.html>