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

--- Comment #11 from Manu <turkeyman@gmail.com> ---
Please don't do that; allow LDC to continue to remove such code as usual. `= void` initialisation is used specifically to avoid that work. DMD is a reference, we don't want to emulate its had habits.

--

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

--- Comment #12 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to anonymous4 from comment #10)
> AFAIK, Walter's suggestion is not supported by LLVM. Currently LLVM removes code that uses uninitialized value. To work it around LDC will need to initialize variables initialized with void and provide an different way to declare uninitialized variables. Likely not a problem, but results in minor fragmentation of language. I believe LDC way will have a priority, because DMD is not really about performance anyway, so default initialized variables for it are good enough.

I don't understand how the suggestion that the behavior is implementation defined doesn't jive with LLVM's chosen behavior.

--

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

--- Comment #13 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to Steven Schveighoffer from comment #12)
> I don't understand how the suggestion that the behavior is implementation defined doesn't jive with LLVM's chosen behavior.

As a whole, using an uninitialized variable wouldn't be implementation defined. That would be silly. Walter's PR doesn't do that. It only says that the value you get is up to the implementation. Everything else must work as usual.

So LLVM would have to give you some value. It wouldn't be allowed to just omit the whole access and everything that depends on it (as it apparently does at the moment).

--

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

--- Comment #14 from Manu <turkeyman@gmail.com> ---
> As a whole, using an uninitialized variable wouldn't be implementation defined. > That would be silly.

I don't think it's silly at all. It's perfectly fine.
Please don't butcher LDC to accommodate DMD's quirks.
Reading from uninitialised memory is an invalid operation, and unnecessarily
initialising memory has real cost.

--

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

--- Comment #15 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to ag0aep6g from comment #13)

> So LLVM would have to give you some value. It wouldn't be allowed to just omit the whole access and everything that depends on it (as it apparently does at the moment).

How would it omit the return statement?

The code above seems to compile with ldc and writeln(f()) seems to print
something (0 in fact on my test). Where is the omission? Not saying your
assertion is false, I just don't understand how it can omit everything that
depends on an access of uninitialized data.

--

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

--- Comment #16 from anonymous4 <dfj1esp02@sneakemail.com> ---
(In reply to Steven Schveighoffer from comment #12)
> I don't understand how the suggestion that the behavior is implementation defined doesn't jive with LLVM's chosen behavior.
Walter suggests that value should be implementation defined, not behavior. LLVM's optimization is inspired by gcc's understanding of undefined behavior, I suspect it won't provide safety.

--

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

--- Comment #17 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to Manu from comment #14)
> > As a whole, using an uninitialized variable wouldn't be implementation defined. > That would be silly.
> 
> I don't think it's silly at all. It's perfectly fine.
> Please don't butcher LDC to accommodate DMD's quirks.
> Reading from uninitialised memory is an invalid operation, and unnecessarily
> initialising memory has real cost.

If we made it implementation defined, the operation would become valid. You would expressly be allowed to write `void main() { int x = void; return x; }`. The spec would say: "I am 100% sure that that's a valid program, and I have no opinion whatsoever on what it should do." I think that'd be silly.

As it is, the operation is invalid, because its behavior is undefined. That's not silly. As far as I can tell, you're arguing for this, not for implementation defined behavior.


(In reply to Steven Schveighoffer from comment #15)
> How would it omit the return statement?
> 
> The code above seems to compile with ldc and writeln(f()) seems to print
> something (0 in fact on my test). Where is the omission? Not saying your
> assertion is false, I just don't understand how it can omit everything that
> depends on an access of uninitialized data.

I think I was wrong there. I had tested something like this:

----
int main(string[] args)
{
    int x = void;
    int y = cast(int) args.length;
    return x + y;
}
----

`ldc2 -O test.d` generates this:

----
0000000000000000 <_Dmain>:
   0:   c3                      ret
----

Here, everything's gone, including args.length. The result isn't "return args.length plus garbage", it's just "return garbage". That looked to me like LDC omits code that depends on the value of x.

But it can be interpreted differently: The value of `x` is arbitrary. LDC can choose it so that whatever `ret` returns is the same as returning x + args.length. Then omitting the args.length line is just normal optimization.

So I don't have an example where LDC's current behavior is incompatible with Walter's PR.

In fact, when I try to restrict the values that `x` can possibly have, e.g. by returning `x & 1`, LDC catches that and emits code that matches. Maybe LDC already adheres to the "implementation defined value" rule.

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--

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

ag0aep6g <ag0aep6g@gmail.com> changed:

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

--- Comment #18 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to ag0aep6g from comment #0)
> I see a couple different ways to approach to this:
[...]
> 2) Give some defined behavior to void initialized values (without indirections). For example, say that the value of `x` is unpredictable, but that the program at large is unaffected (no undefined behavior). With this approach, issue 15542 would become actual. That is, `pure` would need special consideration.
[...]

Walter has chosen this option in <https://github.com/dlang/dlang.org/pull/2990> which has been merged. But he didn't bother updating this issue. Closing as fixed.

As mentioned before, this revives issue 15542.

--