shiva0217 added a comment. In D79378#4103366 <https://reviews.llvm.org/D79378#4103366>, @rjmccall wrote:
> In D79378#4101935 <https://reviews.llvm.org/D79378#4101935>, @shiva0217 wrote: > >> In D79378#4101829 <https://reviews.llvm.org/D79378#4101829>, @rjmccall wrote: >> >>> In D79378#4101613 <https://reviews.llvm.org/D79378#4101613>, @shiva0217 >>> wrote: >>> >>>> Hi, >>>> >>>> I have a question for the delete function call sinking in -Oz. >>>> >>>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf. >>>> According to 3.7.4.2/3 >>>> ` The value of the first argument supplied to a deallocation function may >>>> be a null pointer value; if so, and if the deallocation function is one >>>> supplied in the standard library, the call has no effect. Otherwise, the >>>> behavior is undefined` >>>> >>>> It seems the null checking can be skipped only when the delete is not from >>>> the standard library(have been overloaded by the user), isn't it? >>> >>> The paragraph you just quoted says that the deallocation functions provided >>> by the standard library are required have no effect on null pointers. That >>> means it's fine to call them with a null pointer even if the source >>> wouldn't normally execute that call. We could just insert these calls into >>> random other code if we wanted to. >> >> Is a null operand of delete in the source code no effect because there will >> be null pointer checking generated? Or the delete(null) in assembly code >> also valid? > > In [expr.delete], the standard specifies that using the `delete` operator on > a null pointer is required to have no effect. It does not specify how that > should be implemented. In [basic.std.dynamic.deallocation], the standard > also specifies that the library-provided `operator delete` functions must > have no effect when given a null pointer. This requirement applies no matter > how the function is called, so yes, a call from assembly that passed a null > pointer would also be required to have no effect. More officially, you can > simply take the address of `operator delete`, yielding an rvalue of `void > (*)(void *)` (or similar, depending on which `operator delete` you use), > which can then be called later in a context that doesn't understand it's > calling a deallocation function; such a call is still required to have no > effect when passing a null pointer, because the requirement is laid on the > function, separate from the circumstances of it being called as part of the > `delete` operator. > > Note also that calling `operator delete` unconditionally when implementing > the `delete` operator is explicitly blessed by [expr.delete]p7: > >> If the value of the operand of the delete-expression is not a null pointer >> value, then: >> >> ... >> >> Otherwise, it is unspecified whether the deallocation function will be >> called. Hi @rjmccall, That make sense to me. Thanks for sharing your insight of C++ standard and taking time to answer the questions. Thank you ^^ Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79378/new/ https://reviews.llvm.org/D79378 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
