On Friday, 23 October 2020 at 19:39:52 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 23 October 2020 at 19:23:03 UTC, frame wrote:
>> So how can I avoid this issue with DMD? Disabling any optimization? In fact it does not occur with debug mode enabled.
>>
>
> A dirty fix is to manually add the pointer as a GC root.

Well that works thanks. But shouldn't the runtime do this automatically?

On Friday, 23 October 2020 at 20:46:13 UTC, frame wrote:
> On Friday, 23 October 2020 at 19:39:52 UTC, Ola Fosheim Grøstad wrote:
>> On Friday, 23 October 2020 at 19:23:03 UTC, frame wrote:
>>> So how can I avoid this issue with DMD? Disabling any optimization? In fact it does not occur with debug mode enabled.
>>>
>>
>> A dirty fix is to manually add the pointer as a GC root.
>
> Well that works thanks. But shouldn't the runtime do this automatically?

No, because it means that the GC will not try to release the memory...
Maybe cleaner to use a global variable instead?

On Friday, 23 October 2020 at 19:36:38 UTC, H. S. Teoh wrote:
> On Fri, Oct 23, 2020 at 07:23:03PM +0000, frame via Digitalmars-d wrote:
>> On Friday, 23 October 2020 at 17:47:34 UTC, Steven Schveighoffer wrote:
> [...]
>> > The optimizer is wrong, and should be changed.
>> > 
>> > Note that LDC does not do this optimization.
> [...]
>> So how can I avoid this issue with DMD? Disabling any optimization? In fact it does not occur with debug mode enabled.
> [...]
>
> IMNSHO, drop dmd and use ldc2 instead.  Life is too short to have to deal with dmd backend bugs when I'm trying to get things *done*.  This isn't the first time the dmd backend has problems when optimization / inlining are enabled, and I fear it won't be the last.

LDC is better at detecting unreachable code so it actually does worse than DMD.

https://run.dlang.io/is/2U5OgM

LDC -O3 fails
DMD -release succeeds

Not the prettiest or fastest trick, but the following code will prevent the end of the scope being viewed as unreachable. You could do a lot better with just loading a 1 into a register using machine language. Probably something else you can test in the standard library that the compiler does not have access to.


    auto nevernull = malloc(1);
    if (nevernull != null){
        free(nevernull);

        while(1){…};

    }
    // this is no longer viewed as unreachable

On Friday, 23 October 2020 at 20:27:37 UTC, frame wrote:
>
> Even if I do not run into memory problems, calling the destructor on a live object is an unepxected side effect which makes the dtor concept useless for me. It closes the remote connection the object hold (please don't ask about the meaning, it just the way it has to work) and this must not happen while the program is still running.

Hi frame,
  Regardless of the topic being discussed, you should not do resource management using ctor/dtor of a GC-managed object. The dtor is not guaranteed to be called (not even on program exit). Indeed, the dtor as you know from stack allocated objects works very differently for GC-allocated objects; this feels like the dtor concept is useless (I agree, I've also grown used to RAII-thinking about dtors).

cheers,
  Johan

On Friday, 23 October 2020 at 21:55:36 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 23 October 2020 at 19:36:38 UTC, H. S. Teoh wrote:
>> On Fri, Oct 23, 2020 at 07:23:03PM +0000, frame via Digitalmars-d wrote:
>>> On Friday, 23 October 2020 at 17:47:34 UTC, Steven Schveighoffer wrote:
>> [...]
>>> > The optimizer is wrong, and should be changed.
>>> > 
>>> > Note that LDC does not do this optimization.
>> [...]
>>> So how can I avoid this issue with DMD? Disabling any optimization? In fact it does not occur with debug mode enabled.
>> [...]
>>
>> IMNSHO, drop dmd and use ldc2 instead.  Life is too short to have to deal with dmd backend bugs when I'm trying to get things *done*.  This isn't the first time the dmd backend has problems when optimization / inlining are enabled, and I fear it won't be the last.
>
> LDC is better at detecting unreachable code so it actually does worse than DMD.

I would certainly expect so. Same for GDC.

We can fix this in LDC (quite easily it looks like. We can force LLVM to put&keep certain pointers on the stack), but I first would like to see consensus about this issue from the language designers and see it in text in the language spec.

-Johan

On Friday, 23 October 2020 at 19:23:03 UTC, frame wrote:
> So how can I avoid this issue with DMD? Disabling any optimization?

You avoid it by correctly designing your code. Resource management with class destructors is incorrect design.

On Friday, 23 October 2020 at 23:33:59 UTC, Johan Engelen wrote:
> We can fix this in LDC (quite easily it looks like. We can force LLVM to put&keep certain pointers on the stack), but I first would like to see consensus about this issue from the language designers and see it in text in the language spec.

Maybe you only need to do it in functions that are marked as not returning normally (bottom). It is already implicit in the current spec that variables are valid throughout their scope, so it is the current behaviour that should be documented as it violates static binding principles.

On Saturday, 24 October 2020 at 06:50:13 UTC, Ola Fosheim Grøstad wrote:
> Maybe you only need to do it in functions that are marked as not returning normally (bottom).

That would require that functions are marked as "sometimes does not return normally"...

I guess another option is to go over the ssa after optimization and do a rerun with spilled pointers to the stack... Spilling all potential gc pointers returned from functions to the stack is exessive. It would include void pointers etc.

On Saturday, 24 October 2020 at 06:35:00 UTC, Kagamin wrote:
> On Friday, 23 October 2020 at 19:23:03 UTC, frame wrote:
>> So how can I avoid this issue with DMD? Disabling any optimization?
>
> You avoid it by correctly designing your code. Resource management with class destructors is incorrect design.

Yeah, I understand but this doesn't help if resources are wiped when the object gets destroyed too. I have no problem with that GC may not call the destructor - I have a problem if the GC call the destructor out of the wild. It's also ok that the optimizations are done in my point of view but as a newbie, for me this should be well documented somewhere.