[cfe-dev] Can replacement delete[] have side-effects?

Krzysztof Parzyszek via cfe-dev cfe-dev at lists.llvm.org
Tue Aug 29 14:38:55 PDT 2017


That explains it.  Thanks, both of you.

-Krzysztof


On 8/29/2017 3:36 PM, Ben Craig wrote:
> This is similar in spirit to copy constructor elision.  Copy 
> constructors are allowed to have side effects, but the compiler is 
> allowed to elide the copy constructor skipping the side effects.
> 
> *From:*cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] *On Behalf Of 
> *Richard Smith via cfe-dev
> *Sent:* Tuesday, August 29, 2017 3:03 PM
> *To:* Krzysztof Parzyszek <kparzysz at codeaurora.org>
> *Cc:* Clang Dev <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] Can replacement delete[] have side-effects?
> 
> On 29 Aug 2017 12:56, "Krzysztof Parzyszek via cfe-dev" 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> 
>     Other than deallocating memory, that is?
> 
>     This testcase will either print nothing, or print "Failed",
>     depending on how much inlining takes place. The replacement delete[]
>     operator is treated as the usual deallocation function and is
>     removed despite having an observable side-effect other than
>     deallocation of memory.
> 
>     Is the testcase correct, or is this a bug in LLVM?
> 
> A replacement global (de)allocation function can have side effects. But 
> the C++ standard does not require a new/delete expression to actually 
> call the (de)allocation function, and is permitted to provide the 
> storage in another way instead.
> 
> For the full details, see http://eel.is/c++draft/expr.new#10 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__eel.is_c-2B-2Bdraft_expr.new-2310&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=rVrVFHB4NkiL-jex01SK7BSm6EuiEWx26H8A2bTEgjc&s=N2GL_JNYvKC35qR8twzO-FTXHa9MdJ6SunV2QgSIIAA&e=>
> 
> If you want to guarantee that your functions are called (eg when testing 
> an allocator implementation), you can call them directly ("operator 
> new(size)").
> 
>     --- new.cc ---
>     #include <new>
>     #include <cstdlib>
>     #include <cstddef>
>     #include <iostream>
> 
>     using namespace std;
> 
>     static bool global = false;
> 
>     void* operator new[](::size_t size) throw(bad_alloc) {
>        return ::malloc(size);
>     }
> 
>     void operator delete[](void *ptr) throw() {
>        global = true;
>        if (ptr != NULL)
>          ::free(ptr);
>     }
> 
>     int main(void) {
>        int *p = new int[2];
>        global = false;
>        delete[] p;
>        if (!global)
>          cout << "Failed\n";
>     }
>     --------------
> 
>     $ clang++ -O2 new.cc -mllvm -inline-threshold=10
>     $ ./a.out
>     Failed
> 
>     $ clang++ -O2 new.cc -mllvm -inline-threshold=100
>     $ ./a.out
> 
> 
>     -Krzysztof
> 
> 
> 
>     -- 
>     Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>     hosted by The Linux Foundation
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=rVrVFHB4NkiL-jex01SK7BSm6EuiEWx26H8A2bTEgjc&s=Zzcj9OSXYESOZCtCF0Mtaqh-PXiFpIKzGjn3QCT1W0k&e=>
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation



More information about the cfe-dev mailing list