Bug 2665 – ICE(cod4.c) on certain const struct function return types

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2009-02-14T16:31:00Z
Last change time
2017-07-02T13:24:08Z
Keywords
ice-on-valid-code
Assigned to
nobody
Creator
spam
See also
https://issues.dlang.org/show_bug.cgi?id=16104

Comments

Comment #0 by spam — 2009-02-14T16:31:10Z
struct S{ byte[10] m_a; //byte[9] does not ice } S var; const(S) getVar() //returning just S does not crash { return var; } void main() { const(S) foo = getVar(); } crashes dmd with: Internal error: ..\ztc\cod4.c 357
Comment #1 by sludwig — 2009-02-15T02:13:08Z
This is probably related to or a duplicate of #2560.
Comment #2 by clugdbug — 2009-08-19T07:27:24Z
*** Issue 3203 has been marked as a duplicate of this issue. ***
Comment #3 by hskwk — 2009-08-20T07:45:11Z
(In reply to comment #0) here is (probably) another case of this problem. struct A {} struct B { const A a; } B f() { return B(A()); } Internal error: ..\ztc\cod4.c 354 @ DMD2.031 "const(struct)" is the common component for the issues related to ICE(cod4.c) 35#. Here is a list of problematic code: In the function "cdeq" which generates code for an assignment sz = tysize[tyml]; assert((int)sz > 0); <- failed this assertion. where tyml is a type of lvalue, sz represents # of bytes to transfer. This issue is apparently due to bypass of type-size{tysize} registration for const(struct), besides registration for struct itself is done.
Comment #4 by clugdbug — 2009-08-26T00:56:09Z
(In reply to comment #3) > "const(struct)" is the common component for the issues related to ICE(cod4.c) > 35#. > Here is a list of problematic code: > In the function "cdeq" which generates code for an assignment > > sz = tysize[tyml]; > assert((int)sz > 0); <- failed this assertion. > > where tyml is a type of lvalue, sz represents # of bytes to transfer. > > This issue is apparently due to bypass of type-size{tysize} registration for > const(struct), besides registration for struct itself is done. A variation of that test case is interesting: struct A {} struct B { const A a; } void f() { //A a; // ---- if you uncomment this, it doesn't ICE! B b = B(A()); } Comparing the intermediate code using elem_print(e); shows that there's a difference between the two cases by the start of codelem(). But there's no difference in the code generated by DeclarationExp::toElem() in e2ir.c. Somewhere between the two, an optimisation/rewriting step is performed in the correct case, but not in the ICE case. I haven't yet worked out where it happens.
Comment #5 by clugdbug — 2009-08-31T02:18:24Z
Like 2560, this is a regression between 2.022 and 2.023. It's clearly the same bug.
Comment #6 by bugzilla — 2009-09-03T13:35:07Z
Fixed dmd 2.032