Hi,

It would be great if someone could take care of the regression https://issues.dlang.org/show_bug.cgi?id=20809.
This issue hold me back to use a newer version of the dmd compiler.

Unfortunately my internal knowledge of the dmd compiler is not large enough to fix this issue my self.

It seems to be a result of the PR: https://github.com/dlang/dmd/pull/10577, thanks to moonlightsentinel to figure this out.

- foerdi

On 09.06.20 13:16, foerdi wrote:
> Hi,
> 
> It would be great if someone could take care of the regression https://issues.dlang.org/show_bug.cgi?id=20809.
> This issue hold me back to use a newer version of the dmd compiler.
> 
> Unfortunately my internal knowledge of the dmd compiler is not large enough to fix this issue my self.
> 
> It seems to be a result of the PR: https://github.com/dlang/dmd/pull/10577, thanks to moonlightsentinel to figure this out.
> ...

As far as I can tell, the optimization was wrong all along, and the PR just extends it to all cases where the return expression is an lvalue.

A possible fix would be to always create a temporary variable that stores the return expression and let it be a reference based on whether or not its address is actually taken instead of whether or not it is an lvalue, but I am not sure how to do that in DMD.

On 09.06.20 15:25, Timon Gehr wrote:
> 
> As far as I can tell, the optimization was wrong all along

Here's a case that fails for the same reason with DMD 2.089.1 (i.e., even before the pull request that introduced the regression):

@safe:
struct S{
    @safe:
    int[8] a;
    ~this(){ a[] = 0; }
    ref val(){ return a; }
}
S bar(){ return S([2,2,2,2,2,2,2,2]); }
int[8] foo(){ return bar.val; }

void main(){ assert(foo() == [2,2,2,2,2,2,2,2]); } // error

However, just removing the wrong transformation will not work, because that would delete the "fix" of issue 20401.

On Tuesday, 9 June 2020 at 13:40:38 UTC, Timon Gehr wrote:
> However, just removing the wrong transformation will not work, because that would delete the "fix" of issue 20401.

That "fix" only works for ref int. If we replace int a; to int[8] a; it still fails.

On Tuesday, 9 June 2020 at 19:58:50 UTC, welkam wrote:
> On Tuesday, 9 June 2020 at 13:40:38 UTC, Timon Gehr wrote:
>> However, just removing the wrong transformation will not work, because that would delete the "fix" of issue 20401.
>
> That "fix" only works for ref int. If we replace int a; to int[8] a; it still fails.

I talk nonsense I should not test these things with my modified compiler...
Ups.

On 09.06.20 21:58, welkam wrote:
> On Tuesday, 9 June 2020 at 13:40:38 UTC, Timon Gehr wrote:
>> However, just removing the wrong transformation will not work, because that would delete the "fix" of issue 20401.
> 
> That "fix" only works for ref int. If we replace int a; to int[8] a; it still fails.

?

If you remove the wrong transformation entirely, it will disappear in all cases.

On 09.06.20 22:08, welkam wrote:
> On Tuesday, 9 June 2020 at 19:58:50 UTC, welkam wrote:
>> On Tuesday, 9 June 2020 at 13:40:38 UTC, Timon Gehr wrote:
>>> However, just removing the wrong transformation will not work, because that would delete the "fix" of issue 20401.
>>
>> That "fix" only works for ref int. If we replace int a; to int[8] a; it still fails.
> 
> I talk nonsense I should not test these things with my modified compiler...
> Ups.

np. :)

On 09.06.20 22:10, Timon Gehr wrote:
> On 09.06.20 22:08, welkam wrote:
>> On Tuesday, 9 June 2020 at 19:58:50 UTC, welkam wrote:
>>> On Tuesday, 9 June 2020 at 13:40:38 UTC, Timon Gehr wrote:
>>>> However, just removing the wrong transformation will not work, because that would delete the "fix" of issue 20401.
>>>
>>> That "fix" only works for ref int. If we replace int a; to int[8] a; it still fails.
>>
>> I talk nonsense I should not test these things with my modified compiler...
>> Ups.
> 
> np. :)

(Thank you for taking the time to test it, by the way. Many people don't.)