[llvm-bugs] [Bug 51693] New: UBSan reports an error and incorrect alignment when global new returns an offset pointer
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Aug 31 15:41:30 PDT 2021
https://bugs.llvm.org/show_bug.cgi?id=51693
Bug ID: 51693
Summary: UBSan reports an error and incorrect alignment when
global new returns an offset pointer
Product: compiler-rt
Version: 12.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: ubsan
Assignee: unassignedbugs at nondot.org
Reporter: lambert.clara at yahoo.fr
CC: llvm-bugs at lists.llvm.org
Hello!
I found that ubsan will report an incorrect alignment for a type in case it is
allocated with the global operator new (without alignment), if we have it
return an offset ptr.
I wrote a small repro: https://godbolt.org/z/n8Yh8eoaE
The type is aligned on 8 bytes (verified by static_assert on its alignof), but
ubsan reports: "constructor call on misaligned address 0x000002af8fd8 for type
'Param', which requires 16 byte alignment".
Now I suppose changing the ptr returned by new that way breaks the
__STDCPP_DEFAULT_NEW_ALIGNMENT__, but in the specs in
[basic.stc.dynamic.allocation] it says for the non-aligned, non array new:
"Otherwise, the storage is aligned for any object that does not have
new-extended alignment and is of the requested size", which is pretty vague.
I would either expect to get an error message to indicate that break, or
nothing, because in the end the pointer returned by new is 8 bytes aligned, and
matches the 8 bytes alignment requirement of the type.
I think the issue comes from this line:
https://github.com/llvm/llvm-project/blob/4f7fb13f87e10bd2cd89ccf2be70b026032237a7/clang/lib/CodeGen/CGExprCXX.cpp#L1737
Instead of the allocator alignment result.getAlignment(), it should be the type
alignment allocAlign. I've tried it, and ran the tests, the error goes away and
the tests pass.
Open to ideas :)
Thanks!
--
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/20210831/3c7ec308/attachment.html>
More information about the llvm-bugs
mailing list