[PATCH] D100037: [clang][UBSan] Passing underaligned pointer as a function argument is undefined behaviour
Roman Lebedev via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Apr 7 07:48:48 PDT 2021
lebedev.ri created this revision.
lebedev.ri added reviewers: aaron.ballman, rsmith, efriedma, vsk, filcab, vitalybuka.
lebedev.ri added projects: LLVM, clang, Sanitizers.
Herald added subscribers: jansvoboda11, dexonsmith, dang.
lebedev.ri requested review of this revision.
Herald added subscribers: Sanitizers, cfe-commits.
This is somewhat related to the following RFC by @rjmccall:
https://lists.llvm.org/pipermail/llvm-dev/2016-January/094012.html
> C 6.3.2.3p7 (N1548) says:
>
> A pointer to an object type may be converted to a pointer to a
> different object type. If the resulting pointer is not correctly
> aligned) for the referenced type, the behavior is undefined.
>
> C++ [expr.reinterpret.cast]p7 (N4527) defines pointer conversions in terms
> of conversions from void*:
>
> An object pointer can be explicitly converted to an object pointer
> of a different type. When a prvalue v of object pointer type is
> converted to the object pointer type “pointer to cv T”, the result
> is static_cast<cv T*>(static_cast<cv void*>(v)).
>
> C++ [expr.static.cast]p13 says of conversions from void*:
>
> A prvalue of type “pointer to cv1 void” can be converted to a
> prvalue of type “pointer to cv2 T” .... If the original pointer value
> represents the address A of a byte in memory and A satisfies the alignment
> requirement of T, then the resulting pointer value represents the same
> address as the original pointer value, that is, A. The result of any
> other such pointer conversion is unspecified.
Currently clang does not optimize based on the fact that the pointers
passed into the function must be appropriately aligned for their pointee type.
We now have a motivation to change that. Namely, it was estabilished that
not doing so prevents LICM, and it is likely not the only penalized transform.
See D99249 <https://reviews.llvm.org/D99249>.
Now, somehow i don't think we can just start optimizing on that.
Let's first give users tools to weed out the cases where the pointer
passed into function's argument is underaligned.
I've yet to actually see just how much mayhem this causes,
at least on the LLVM stage-2 build.
Repository:
rG LLVM Github Monorepo
https://reviews.llvm.org/D100037
Files:
clang/docs/ClangCommandLineReference.rst
clang/docs/ReleaseNotes.rst
clang/docs/UsersManual.rst
clang/include/clang/Basic/CodeGenOptions.def
clang/include/clang/Driver/Options.td
clang/lib/CodeGen/CGExpr.cpp
clang/lib/CodeGen/CodeGenFunction.cpp
clang/lib/CodeGen/CodeGenFunction.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGen/catch-function-pointer-argument-alignment.cpp
compiler-rt/lib/ubsan/ubsan_handlers.cpp
compiler-rt/test/ubsan/TestCases/Pointer/function-pointer-argument.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D100037.335807.patch
Type: text/x-patch
Size: 14655 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20210407/387e0be5/attachment-0001.bin>
More information about the cfe-commits
mailing list