https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Alex from comment #0)
> This code:
>
> import std.stdio;
>
> ubyte sum(ubyte[] bytes)
> {
> ubyte result;
> foreach(x;bytes)
> result += x;
> return result;
> }
>
> int main()
> {
> ubyte[] bytes = [0,1];
> bytes ~= bytes.sum;
> writefln("sum = %s",bytes[$-1]);
> return 0;
> }
>
> Expected output :
> sum = 1 as confirmed at https://dlang.org/ your code here
> Actual output :
> sum = <random number>
So the array is extended before calling sum(), which doesn't violate LTR order
of precedence that is expected in assignment operations.
A() = B() + C(); // A, B, C
A() += B() + C(); // A, B, C
Despite there being a slight deviation with array concatenation, but that down
to some implementation specific detail that will be resolved upstream druntime
at some point in the future.
X() = Y() ~ Z(); // x86: X, Z, Y
// ARM: X, Y, Z
However, order of evaluation in assignment expressions is explicitly undefined,
both in 10.2.7 [1] and 12.9.5 [2] of the spec. So it would be difficult to
justify whether it is indeed bad code-gen, and writing code that depends on a
specific order of evaluation is not recommended anyway.
[1]: https://dlang.org/spec/expression.html#order-of-evaluation
[2]: https://dlang.org/spec/arrays.html#array-operations
