Bug 15206 – [REG2.077] ICE on optimized build, tym = x1d Internal error: backend\cgxmm.c 547
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
All
Creation time
2015-10-15T15:44:59Z
Last change time
2018-11-21T14:29:52Z
Keywords
ice-on-valid-code, industry, SIMD
Assigned to
No Owner
Creator
d bug report
Comments
Comment #0 by h1054820 — 2015-10-15T15:44:59Z
Works fine on debug but, on optimized builds (-O -release -inline -noboundscheck) it takes a lot longer to build and finally outputs:
tym = x1d
Internal error: backend\cgxmm.c 547
It's specifically the -O flag that causes this.
Tried to minimize with dustmite, but it's still way too big to post here.
I don't really have a clue if this is the cause, but the biggest 'component' of the reduced dustmite case is a system that builds custom compile-time type info and shoves it into a hashmap. Then builds some data arrays, switches and the runtime part of the system using those.
Comment #1 by dlang-bugzilla — 2015-10-15T15:50:35Z
A reproducible test case is needed, reduced or not.
Comment #2 by briancschott — 2018-01-09T00:51:36Z
Here's a test case minimized from a failed build of some data processing code at EMSI. This is partially a 2.078.0 regression, but I wasn't sure about filing a new issue since it seems to be a duplicate of this bug.
-----------------------------
void main()
{
}
struct Line
{
double slope;
double intercept;
}
Line nLineProjection(double[] historicData)
{
Line projLine;
projLine.intercept = historicData[$-1] + projLine.slope;
return projLine;
}
-----------------------------
$ dmd -O test.d
tym = x1d
Internal error: dmd/backend/cgxmm.c 684
$ dmd --version
DMD64 D Compiler v2.078.0
Copyright (c) 1999-2017 by The D Language Foundation written by Walter Bright
Comment #3 by hsteoh — 2018-01-09T21:47:19Z
All ICEs should be critical.
Comment #4 by briancschott — 2018-01-10T00:26:28Z
It seems that the problem is in the allocreg function called from loaddata.
I added some debugging printfs before and after calls to `allocreg` and I see the following:
before: tym = 0x1d, forregs = 0x020000, reg = BP|SI|DI|R10|R12|R15|XMM0|XMM1|XMM3|XMM4|XMM5|XMM6|XMM7|PSW|NOREG|RMload
after: tym = 0x1d, forregs = 0x020000, reg = AX|SP
It seems that the `forregs` variable (The `pretregs` parameter to allocreg) is not getting modified properly. It still has the value 0x20000, which matches the XMMREGS mask even though `allocreg` has correctly removed all the XMM registers from the list of valid registers in the `reg` variable. Because this `forregs` variable is not masked out by XMMREGS, there is a call to `xmmload` even though `xmmload` doesn't support `tym` values of 0x1d.
This is frustrating. I cannot reproduce this issue.
Comment #7 by john.loughran.colvin — 2018-04-03T19:55:48Z
I found a different piece of code that triggers the same error:
% cat test.d:
alias A = Complex!double;
struct Complex(T)
{
double re, im;
Complex!double baz()
{
return Complex!double(re).blah;
}
ref Complex!double blah()
{
im = re;
return this;
}
}
% dmd -c -inline -O -m64 test.d
tym = x1d
Internal error: dmd/backend/cgxmm.c 684
Walter, I can produce the error for both this and the original example on both macOS and linux (haven't tried windows). -m32 avoids the bug.