[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