<html>
<head>
<base href="http://bugzilla.gdcproject.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Optimization makes incorrect results"
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=198#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Optimization makes incorrect results"
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=198">bug 198</a>
from <span class="vcard"><a class="email" href="mailto:ibuclaw@gdcproject.org" title="Iain Buclaw <ibuclaw@gdcproject.org>"> <span class="fn">Iain Buclaw</span></a>
</span></b>
<pre>(In reply to Iain Buclaw from <a href="show_bug.cgi?id=198#c2">comment #2</a>)
<span class="quote">> Seems to be something bizarre going on with struct member functions,
> possibly only related to instantiated members. Having a bare function works
> just fine.
>
> ref Vector opOpAssign (ref Vector rthis, Vector operand)
> {
> rthis.x += operand.x;
> rthis.y += operand.y;
> rthis.z += operand.z;
> return rthis;
> }
>
> Either a mismatch between function type and function parameter types are
> throwing off the optimizer, or something else is afoot to make it believe
> that the 'this' value members can never change.
>
> In gdc-5, all optimisation levels constfold the answer correctly in the
> testcase, except for -Og level, which calls f(), but the entire foreach loop
> has been reduced to nothing, so it passes Vector(0,0,0) to sum().</span >
All wrong, I was able to reproduce the bug by applying @forceinline on the
function, some deeper digging and I've found via: -Og -finline-functions
-fdump-tree-cddce-stats-details:
Eliminating unnecessary statements:
Deleting : sum.z = _50;
Deleting : _50 = _48 + 3.0e+0;
Deleting : _48 = sum.z;
Deleting : sum.y = _47;
Deleting : _47 = _45 + 2.0e+0;
Deleting : _45 = sum.y;
Deleting : sum.x = _44;
Deleting : _44 = _9 + 1.0e+0;
Deleting : _9 = sum.x;
Deleting : operand = D.3725;
Deleting : D.3725 = __ctmp4;
Deleting : __ctmp4.z = 3.0e+0;
Deleting : __ctmp4.y = 2.0e+0;
Deleting : __ctmp4.x = 1.0e+0;
Deleting : __ctmp4 = {};
Deleting : _14 = v_1 <= 2;
Deleting : sum.z = 0.0;
Deleting : sum.y = 0.0;
Deleting : sum.x = 0.0;
And yet it doesn't remove the sum.v[] deferences as it's able to properly
associate it with a shared memory location.
Making the anonymous union a named union fixes this indefinitely. So it seems
like it all comes down to lack of association in our anonymous members. So we
should at least give anonymous structs/unions a dummy name, even though people
will see it as a flat structure in debug.
So this would be a duplicate of another bug related to unions/structs...</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>