Bug 2560 – ICE(cod4.c) on invoking method that takes ref const struct parameter
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2009-01-06T23:26:00Z
Last change time
2015-06-09T01:21:01Z
Keywords
ice-on-valid-code
Assigned to
nobody
Creator
2korden
Comments
Comment #0 by 2korden — 2009-01-06T23:26:27Z
module bug;
struct S
{
static S opCall()
{
S s;
return s;
}
}
void foo(ref const(S) s)
{
}
void bar()
{
foo(S());
}
Output:
Internal error: ..\ztc\cod4.c 357
Note that this is a regression since DMD2.022
Comment #1 by sludwig — 2009-01-07T04:16:32Z
*** Bug 2561 has been marked as a duplicate of this bug. ***
Comment #2 by spam — 2009-01-07T09:39:28Z
Wow this one really sucks. For me this makes nearly every D2 using project unbuildable since D2.023 ;(
Comment #3 by dransic — 2009-01-07T16:48:27Z
Though I'm not sure why, I guess this is related:
struct Foo {
int x, y, z;
this(int dummy) {}
}
invariant(Foo) createFoo() {
return cast(invariant) Foo(0);
}
void main() {
auto foo = createFoo;
}
causes the same compilation error without the -inline option. Compiles OK if I remove z, the constructor, or 'invariant' in the return type of createFoo.
Comment #4 by sludwig — 2009-03-08T04:17:23Z
OK, it seems that the crash does not happen with DMD 2.026 anymore. Output is instead analogous to the second case in #2561. The test case in #2665 still crashes though. And another similar code snippet, too:
---
struct S { int x; }
const(S) f(){ return S(0); }
void g(){ int a = f().x; }
---
Comment #5 by clugdbug — 2009-08-31T02:22:44Z
*** Issue 2847 has been marked as a duplicate of this issue. ***
Comment #6 by clugdbug — 2009-08-31T02:25:02Z
*** Issue 2969 has been marked as a duplicate of this issue. ***
Comment #7 by hskwk — 2009-08-31T02:41:10Z
(In reply to comment #5)
> *** Issue 2847 has been marked as a duplicate of this issue. ***
However I agree these issues are duplicate of this, don't forget specialty of real.
In Issue 2847, only real causes ICE, besides float and double do not.
Both const(struct) and const(real) may be behind assertion failure at cod4.c 35#.
Bugs about real have harmful effects on numeric computing, so that this point must be important for you.
Comment #8 by clugdbug — 2009-08-31T02:52:15Z
(In reply to comment #7)
> (In reply to comment #5)
> > *** Issue 2847 has been marked as a duplicate of this issue. ***
>
> However I agree these issues are duplicate of this, don't forget specialty of
> real.
> In Issue 2847, only real causes ICE, besides float and double do not.
> Both const(struct) and const(real) may be behind assertion failure at cod4.c
> 35#.
> Bugs about real have harmful effects on numeric computing, so that this point
> must be important for you.
The reason why it doesn't fail for float and double is that they have sizes of 4=int.sizeof and 8=long.sizeof, and get inlined at an earlier stage in the backend. So structs with size 1,2,4, and 8 are immune from the ICE. Real is size 10, so it ICEs. It's nothing to do with floating point at all.
Comment #9 by hskwk — 2009-08-31T03:03:17Z
(In reply to comment #8)
> The reason why it doesn't fail for float and double is that they have sizes of
> 4=int.sizeof and 8=long.sizeof, and get inlined at an earlier stage in the
> backend. So structs with size 1,2,4, and 8 are immune from the ICE. Real is
> size 10, so it ICEs. It's nothing to do with floating point at all.
I am reassured by your good analysis. thank you.