Bug 7156 – ICE(go.c): with 199 or 200 repeated integer increments, only with -O
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2011-12-22T14:53:00Z
Last change time
2015-06-09T05:10:40Z
Keywords
ice
Assigned to
nobody
Creator
peter.alexander.au
Comments
Comment #0 by peter.alexander.au — 2011-12-22T14:53:02Z
This is a bit of a bizarre one. If you have 199 or 200 repeated integer increments then you get an ICE when optimisations are enabled.
string rep(string s, int n)
{
return n > 1 ? s ~ rep(s, n-1) : s;
}
void main()
{
int i;
version (A) mixin(rep("++i;", 198));
version (B) mixin(rep("++i;", 199));
version (C) mixin(rep("++i;", 200));
version (D) mixin(rep("++i;", 201));
}
% time dmd test.d -O -version=A
dmd test.d -O -version=A 0.53s user 0.03s system 80% cpu 0.687 total
% time dmd test.d -O -version=B
Internal error: ../ztc/go.c 242
dmd test.d -O -version=B 0.49s user 0.01s system 95% cpu 0.528 total
% time dmd test.d -O -version=C
Internal error: ../ztc/go.c 242
dmd test.d -O -version=C 0.50s user 0.01s system 92% cpu 0.547 total
% time dmd test.d -O -version=D
dmd test.d -O -version=D 0.54s user 0.03s system 93% cpu 0.613 total
Notice the internal errors in versions B and C, but not A or D.
With no -O flag, there is no ICE in any version.
Comment #1 by bugzilla — 2013-10-05T21:19:18Z
What's happening is the optimizer has a check for going into an infinite loop, because sometimes two optimization states will flip-flop back and forth instead of converging on a solution.
Although this isn't an infinite loop case, the optimizer can't tell that.
The assert trip is line 241 of go.c.