Bug 6733 – Regression(2.054) ICE(cod2.c) pure nothrow func with side-effect parameters
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2011-09-26T10:30:00Z
Last change time
2011-12-08T00:57:29Z
Keywords
ice-on-valid-code
Assigned to
nobody
Creator
wfunction
Comments
Comment #0 by wfunction — 2011-09-26T10:30:20Z
I have no idea what the heck is going on, but this crashes on DMD32 D Compiler v2.055:
struct Zero { }
void test(T1, T2)(T1 a, T2 b) { }
void main() { test(Zero(), Zero()); }
Comment #1 by wfunction — 2011-09-26T10:30:56Z
Oh, and the error is:
Internal error: ..\ztc\cod2.c 4624
Comment #2 by clugdbug — 2011-10-21T00:03:39Z
This worked in 2.053 and earlier.
Comment #3 by braddr — 2011-10-21T00:44:05Z
I just bisected it down to:
commit 4c9661fa9fbd427909a334133dfc7f3869e47c31
Author: Walter Bright <[email protected]>
Date: Thu Jun 23 00:50:46 2011 -0700
nothrow inference
Reverting it from tip of master yields a successful build of the code above.
Comment #4 by clugdbug — 2011-10-21T01:04:13Z
(In reply to comment #3)
> I just bisected it down to:
>
> commit 4c9661fa9fbd427909a334133dfc7f3869e47c31
> Author: Walter Bright <[email protected]>
> Date: Thu Jun 23 00:50:46 2011 -0700
>
> nothrow inference
>
> Reverting it from tip of master yields a successful build of the code above.
Thanks. The backend failure is occuring inside a comma expression (x, y). Fails because x isn't an expression, it's just a parameter (presumably the struct literal).
Comment #5 by clugdbug — 2011-10-21T01:19:10Z
Actually this is more a pseudo-regresssion, it's just an expansion of an existing bug into a few more cases. Walter's commit has nothing to do with the root cause. The test case below fails in exactly the same way on 2.025 (but passed on 2.023).
struct Zero { int x; }
void test(T)(T a, T b) pure nothrow { }
void main() { test(Zero(7), Zero(4)); }
The bug is triggered when test() gets completely optimized away because it's pure nothrow.
Comment #6 by clugdbug — 2011-10-21T05:05:58Z
Reduced test case:
void bug6733(int a, int b) pure nothrow { }
void main() {
int z;
bug6733(z++, z++);
}
This is definitely a backend bug. What happens is, that since it's pure nothrow and the result is unused, it's a no-side-effect call (OPcallns).
In the first optimisation step (optelem in cgelem.c), the call gets discarded, and simply replaced with the parameter list (wrapped in an OPparam). If the parameters had no side-effects, the whole thing would be discarded.
If there's only one with a side-effect, it's the only thing that's left. But if there are TWO with side-effects, the OPparam remains.
The rest of the backend can't cope with a naked OPparam. Boom.
Solution would be to replace the OPparam with comma expressions.