[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


            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


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:


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 :)

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