[llvm-bugs] [Bug 49184] New: sizeof(struct) == 0 for struct with large, explicitly aligned non-static data member

[via llvm-bugs]

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

            Bug ID: 49184
           Summary: sizeof(struct) == 0 for struct with large, explicitly
                    aligned non-static data member
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: joejev at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

Created attachment 24525
  --> https://bugs.llvm.org/attachment.cgi?id=24525&action=edit
A reproducer which shows how the structure size is incorrectly reported as 0.

For structs which contain very large non-static data members with an explicit
alignment, sizeof can report 0. I believe I have tracked this down to an
overflow in llvm::alignTo from clang/lib/AST/MathExtras.H (clarifying because I
found an alternative implementation in llvm/Support/Alignment.h).

The example struct I have tested is:

struct node {
    alignas(2) char data[2305843009213693951u];  //
std::numeric_limits<std::ptrdiff_t>::max() / 4;
};

With this definition, sizeof(node) == 0 even though sizeof(node::data) ==
2305843009213693951u.

In ItaniumRecordLayoutBuilder::FinishLayout, when computing RoundedSize, which
appears to be the final size of the struct, we start with a proper Size and
DataSize of 18446744073709551608 (std::numeric_limits<std::ptrdiff_t>::max() /
4 * 8, where 8 is the number of bits in char on my system). The Alignment also
appears correct at 16 (2 * 8, where 8 is the number of bits in char on my
system).
llvm::alignTo is defined as: (Value + Align - 1 - Skew) / Align * Align + Skew
In this invocation, Skew is 0.
When we take Value + Align, 18446744073709551608 + 16, we overflow and get 8,
which is less than Align and the division truncates to 0.

I would be happy to contribute a patch to either fix this issue, but I am not
sure if this should be corrected in llvm::alignTo or if this case should be
detected earlier and error.

-- 
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/20210215/dfe7d94a/attachment.html>