https://issues.dlang.org/show_bug.cgi?id=22277

--- Comment #11 from Dennis <dkorpel@live.nl> ---
(In reply to Ate Eskola from comment #10)
> I think the compiler is allowed to elide a `free` call implemented like that.

Agreed, I used a `debug` statement for demonstration purposes based on the knowledge that the compiler doesn't inspect the function body in this case.

A proper test case would hide the implementation:
```
void free(immutable void* mem) pure nothrow;
```

And then compile the implementation separately.

--

https://issues.dlang.org/show_bug.cgi?id=22277

--- Comment #12 from Ate Eskola <Ajieskola@gmail.com> ---
Currently, the compiler is allowed to elide such a `free` call if it can prove that `free` has been called before with a similar value in the pointed object. In that case, any potential crash or infinite loop would have happened in the prior call.

This is directly not a problem. The compiler cannot judge whether two void pointers have similar values in the object, since it does not know the type of the object. The exception to that rule might be a double free, but that is undefined behaviour anyway.

However, this one is still a problem:

------
pure immutable void* mallocSomething(int arg);

auto a = mallocSomething(8), b = mallocSomething(8);
free(a);
free(b);
------

Even without the knowledge of what the pointers point to, the compiler is free to assume the objects are similar since they are returned by a strongly pure function with similar arguments. Thus it may skip the latter `free` call.

I'm not sure how to handle this. I guess the short-term solution is to simply forbid a pure `free` with an immutable pointer.

--

https://issues.dlang.org/show_bug.cgi?id=22277

timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch

--- Comment #13 from timon.gehr@gmx.ch ---
Created attachment 1831
  --> https://issues.dlang.org/attachment.cgi?id=1831&action=edit
__mutable early DIP draft

This is precisely what `__mutable` functions were supposed to solve. `__mutable` draft proposal attached for reference.

--

https://issues.dlang.org/show_bug.cgi?id=22277

--- Comment #14 from Ate Eskola <Ajieskola@gmail.com> ---
And Andrei killed that before the draft review? What was the rationale?

--

https://issues.dlang.org/show_bug.cgi?id=22277

--- Comment #15 from timon.gehr@gmx.ch ---
(In reply to Ate Eskola from comment #14)
> And Andrei killed that before the draft review? What was the rationale?

I was too busy to spend a lot of time on it, especially given that Andrei was not a huge fan of the details of my idea. I think they just wanted a very specialized solution that works for reference counting. Andrei and Razvan tried to finish the proposal, but they completely changed it in the process:

https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md

I then requested to be removed as co-author as I did not think it was a good approach, and they ultimately did not go ahead with that DIP.

Regarding Andrei's proposal of never eliding pure `void` functions, I think that is a bad idea, e.g.:

auto a = [1,2,3];
writeln(a);
// a is dead now
void foo(int[] x)pure{ x[]*=2; }
foo(a); // this call can be elided, as a will never be read again

I really think the only sane way to make progress on this is to specify precisely which rewrites are allowed for data and functions of each qualification, giving special treatment low-level functions that implement the high-level semantics, as in my draft. `__mutable` fields and functions solve a lot of issues at once. (E.g., they can be used to initialize `immutable` arrays in druntime, for sound lazy initialization of `immutable` data, or to store metadata such as reference counts.)

Until such a solution is specced out, I think DMD should probably refrain from optimizing on qualifiers.

--

https://issues.dlang.org/show_bug.cgi?id=22277

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/dmd pull request #13047 "Fix issue 22277 - removing strongly pure function calls is an incorrect optimization" was merged into master:

- f5a75f5834a3ee9efa14c0e2a4da86a0c356b6df by dkorpel:
  fix issue 22277 - removing strongly pure function calls is an incorrect
optimization

https://github.com/dlang/dmd/pull/13047

--