[Issue 3808] New: Assertion Failure : Assertion failure: 'classinfo-structsize == CLASSINFO_SIZE' on line 870 in file 'toobj.c'
http://d.puremagic.com/issues/show_bug.cgi?id=3808 Summary: Assertion Failure : Assertion failure: 'classinfo-structsize == CLASSINFO_SIZE' on line 870 in file 'toobj.c' Product: D Version: unspecified Platform: x86 OS/Version: Windows Status: NEW Severity: blocker Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: petitv.i...@gmail.com --- Comment #0 from Petit Vincent petitv.i...@gmail.com 2010-02-16 14:23:36 PST --- Created an attachment (id=568) sc.ini, makefile, binding, screen Well, I found this bug when I was trying to make the win32lib from the binding available on Dsource.org. I'll try to explain the environment with lot of details : 1. DMD Compiler : Version 1.033, 1.056 ; 2.040, dmd2beta have been tested. Each one returned the bug. So, the version of the compiler don't play a role to have this bug. 2. Libraries : - Standard Library : tango 0.98 and tango 0.99.9 kai have been tried too. Same result. - Others : tried with and without these ones : tangobos (latest), DFL (latest), INI (from dprogramming.com). Nothing changed the result. 3. Binding : - Win32 from DSource - the latest one from trunk version (trunk-r337) 4. Attachement : - The makefile for the binding (and the binding itself) - A screen from my dmd\lib directory - sc.ini file I'm using (there's lot of comments cause of tests I made for this bug or other things ...) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3808] Assertion Failure : Assertion failure: 'classinfo-structsize == CLASSINFO_SIZE' on line 870 in file 'toobj.c'
http://d.puremagic.com/issues/show_bug.cgi?id=3808 --- Comment #1 from Petit Vincent petitv.i...@gmail.com 2010-02-16 14:25:18 PST --- Well, I found this bug when I was trying to make the win32lib from the binding available on Dsource.org. I'll try to explain the environment with lot of details : 1. DMD Compiler : Version 1.033, 1.056 ; 2.040, dmd2beta have been tested. Each one returned the bug. So, the version of the compiler don't play a role to have this bug. 2. Libraries : - Standard Library : tango 0.98 and tango 0.99.9 kai have been tried too. Same result. - Others : tried with and without these ones : tangobos (latest), DFL (latest), INI (from dprogramming.com). Nothing changed the result. 3. Binding : - Win32 from DSource - the latest one from trunk version (trunk-r337) 4. Attachement : - The makefile for the binding (and the binding itself) - A screen from my dmd\lib directory - sc.ini file I'm using (there's lot of comments cause of tests I made for this bug or other things ...) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3809] New: Struct initializers apparently always CTFE'd, and incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=3809
Summary: Struct initializers apparently always CTFE'd, and
incorrectly
Product: D
Version: 1.056
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic, rejects-valid, wrong-code
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: matti.niemenmaa+dbugzi...@iki.fi
--- Comment #0 from Matti Niemenmaa matti.niemenmaa+dbugzi...@iki.fi
2010-02-16 14:25:34 PST ---
This worked at least as late as 1.051, but now fails in 1.056:
struct S { int xx; int x() { return xx; } }
void foo(S s) {
S a = {100 / s.x()};
S b = {100 / s.x()};
}
$ dmd arst.d
Error: divide by 0
arst.d(4): Error: cannot evaluate s.x() at compile time
It seems like it's CTFEing the s.x() calls, which would explain the (bonus:
location-lacking) division by zero error as well: xx is zero by default, after
all.
Confirmed by changing int xx to int xx = 1 and returning b from foo: the
code compiles, and the disassembly shows that no divisions are being performed,
it was erroneously done at compile time. Similarly, changing the code to
perform e.g. a multiplication instead of a division makes it compile (as the
division by zero is the cause for the lack of compilation), but again the s.x()
has been improperly CTFE'd.
An additional point of interest: the cannot evaluate error is only reported
for the S's after the first: with only one, the code compiles (to wrong code,
again).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
