aqjune added inline comments.
================ Comment at: clang-tools-extra/docs/clang-tidy/checks/misc-no-inttoptr.rst:12 +if you got that integral value via a pointer-to-integer cast originally, +the new pointer will lack the provenance information from the original pointer. + ---------------- aaron.ballman wrote: > Does this run afoul of the C++ standard's requirements for pointer > traceability: http://eel.is/c++draft/basic.stc.dynamic.safety ? This is fine because the compiled IR is allowed to be more defined than the C++ source. In C++, accessing a pointer that is derived from an integer is UB if it is out-of-bounds location of the object pointed by the integer. In LLVM IR (I mean in the suggested memory model), it is relaxed to have well-defined behavior if the pointer is pointing to a different, but in-bounds location of an object. This loses the precision of points-to analysis if inttoptr is involved, but makes more arithmetic optimizations on integers valid. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91055/new/ https://reviews.llvm.org/D91055 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
