[llvm-bugs] [Bug 33191] New: Assertion on zero-byte type in -O0 AArch64 compile

[via llvm-bugs]

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

            Bug ID: 33191
           Summary: Assertion on zero-byte type in -O0 AArch64 compile
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: srhines at google.com
                CC: kristof.beyls at arm.com, llvm-bugs at lists.llvm.org

Created attachment 18523
  --> https://bugs.llvm.org/attachment.cgi?id=18523&action=edit
Reduced test case for failed AArch64 compile

Running the following command on this source file results in an assertion
because each type is actually zero bytes, but the AArch64 backend doesn't seem
to handle all zero-byte types appropriately (at least not those that don't also
count as zero bytes for isEmptyRecord() in TargetInfo.cpp).

$ clang++ -std=c++14 --target=arm64-v8a -O0 -c t.cpp
...
clang++: external/llvm/lib/IR/Type.cpp:229: static llvm::IntegerType
*llvm::IntegerType::get(llvm::LLVMContext &, unsigned int): Assertion `NumBits
>= MIN_INT_BITS && "bitwidth too small"' failed.

The size (as reported) for the struct is indeed 0, yet isEmptyRecord() doesn't
flag it as being empty. This is because this is a record containing another
record, and according to comments in TargetInfo.cpp, C++ record fields are
never empty in the Itanium ABI.

I think the correct fix is to update the AArch64 functions (both for return
type and regular parameters) to handle a zero-byte aggregate, but I wanted to
make sure that there isn't a better reason to make
isEmptyRecord()/isEmptyField() do something better in this case (i.e. claim
that it is indeed empty, and force all the callers to handle the Itanium ABI
requirements themselves).

-- 
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/20170527/b77175f7/attachment.html>