• foerdi (11/11) Jun 09 2020 Hi,
• Timon Gehr (7/20) Jun 09 2020 As far as I can tell, the optimization was wrong all along, and the PR
• Timon Gehr (15/17) Jun 09 2020 Here's a case that fails for the same reason with DMD 2.089.1 (i.e.,
• welkam (3/5) Jun 09 2020 That "fix" only works for ref int. If we replace int a; to int[8]
• welkam (4/9) Jun 09 2020 I talk nonsense I should not test these things with my modified
• Timon Gehr (2/12) Jun 09 2020 np. :)
• Timon Gehr (2/16) Jun 09 2020 (Thank you for taking the time to test it, by the way. Many people don't...
• Timon Gehr (4/10) Jun 09 2020 ?

foerdi <dlang foerdi.net> writes:

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

Timon Gehr <timon.gehr gmx.ch> writes:

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.

Timon Gehr <timon.gehr gmx.ch> writes:

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.

welkam <wwwelkam gmail.com> writes:

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.

welkam <wwwelkam gmail.com> writes:

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.

Timon Gehr <timon.gehr gmx.ch> writes:

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. :)

Timon Gehr <timon.gehr gmx.ch> writes:

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.)

Timon Gehr <timon.gehr gmx.ch> writes:

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.