Bug 5656 – dmd fails to compile optimized foreach over a big enum

Status
RESOLVED
Resolution
DUPLICATE
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2011-02-26T14:28:00Z
Last change time
2011-03-03T00:39:59Z
Keywords
ice-on-valid-code
Assigned to
nobody
Creator
jens.k.mueller

Attachments

IDFilenameSummaryContent-TypeSize
923test.dTest program that fails to compiletext/x-dsrc1439

Comments

Comment #0 by jens.k.mueller — 2011-02-26T14:28:45Z
Created attachment 923 Test program that fails to compile Compiling the attached file with $ dmd -O -c test.d fails with Internal error: ../ztc/blockopt.c 619 If you disable the optimization it works, i.e. $ dmd -c test.d If the enum contains more than 197 elements it fails. Don't know why this number. Though such a big enum may be very artificial, you can run into the same problem if you nest foreach of smaller enums (see the commented out code in the attached file). $ dmd | head -1 Digital Mars D Compiler v2.051 I could not reproduce the problem in dmd v2.039. But it also exists in v2.047. I haven't checked any dmd between v2.039 and v2.047.
Comment #1 by clugdbug — 2011-02-28T00:54:23Z
Please test this on 2.052. I'm almost certain this is a duplicate of bug 4379. In general, please don't report crashing bugs without testing on the latest compiler. They are given a very high priority, so a large number of them are fixed in every release.
Comment #2 by jens.k.mueller — 2011-02-28T01:31:57Z
You're right. It does work with dmd v2.052. I only searched for similar bug reports but I didn't find any (I'll guess the fixed ones are not searched by default.). Sorry. Next time I do better. Thanks very much.
Comment #3 by samukha — 2011-02-28T01:46:38Z
Don, may I ask you to rethink the way you prioritize bugs? You seem to go for ICE bugs regardless of their importance for real use of the compiler. Something is not right if wrong-code, artificially elicited or easy to work around ICE bugs are prioritized over really critical non-ICE ones like http://d.puremagic.com/issues/show_bug.cgi?id=3516. 3516 is *very* important for anyone who uses destructible structs. It makes structs unusable while many of the recently fixed ICEs are trivial to work around. BTW, it has 24 votes, which means people really care. Thank you!
Comment #4 by clugdbug — 2011-02-28T04:41:03Z
(In reply to comment #3) > Don, may I ask you to rethink the way you prioritize bugs? You seem to go for > ICE bugs regardless of their importance for real use of the compiler. Something > is not right if wrong-code, artificially elicited or easy to work around ICE > bugs are prioritized over really critical non-ICE ones like > http://d.puremagic.com/issues/show_bug.cgi?id=3516. 3516 is *very* important > for anyone who uses destructible structs. It makes structs unusable while many > of the recently fixed ICEs are trivial to work around. BTW, it has 24 votes, > which means people really care. Yes, I know, that one has been top of the list for more than a year. But it's hard! Really hard! For reference, this is my current list of top ten bugs: 4854 Regression(2.047, Mac 10.5 only) writefln Segmentation fault if no globals 3516 Destructor not called on temporaries 314 [module] Static, renamed, and selective imports are always public 4714 Cannot return ref this when struct has invariant = 3273 Regression(2.031) struct invariant + dtor fails to compile (no line number) = 1251 Final template class w/ constructor and invariant causes compile error = 3973 out contracts fail with ref return types 4269 Regression(2.031) invalid type accepted if evaluated while errors are gagged [design issue] Signature of opEquals *All* of these are very difficult bugs. I have spent a lot of time on each one of them. Then comes a pile of wrong-code bugs, starting with: 1350 delegate literal inside tuple; wrong values The reason for the focus on wrong-code and ICE bugs, is that they often indicate fundamental problems with the compiler. In particular, I have zero tolerance for back-end bugs.
Comment #5 by samukha — 2011-02-28T11:08:26Z
(In reply to comment #4) > Yes, I know, that one has been top of the list for more than a year. But it's > hard! Really hard! You will cope with it! > For reference, this is my current list of top ten bugs: > > 4854 Regression(2.047, Mac 10.5 only) writefln Segmentation fault if no globals > 3516 Destructor not called on temporaries > 314 [module] Static, renamed, and selective imports are always public > > 4714 Cannot return ref this when struct has invariant > = 3273 Regression(2.031) struct invariant + dtor fails to compile (no line > number) > = 1251 Final template class w/ constructor and invariant causes compile error > = 3973 out contracts fail with ref return types > 4269 Regression(2.031) invalid type accepted if evaluated while errors are > gagged > [design issue] Signature of opEquals > > *All* of these are very difficult bugs. I have spent a lot of time on each one > of them. > Then comes a pile of wrong-code bugs, starting with: > 1350 delegate literal inside tuple; wrong values > > The reason for the focus on wrong-code and ICE bugs, is that they often > indicate fundamental problems with the compiler. In particular, I have zero > tolerance for back-end bugs. I understand. One fundamental problem fixed is better than a million of hacks stacked on a broken foundation. Thanks for the work you are doing.
Comment #6 by clugdbug — 2011-03-03T00:39:59Z
*** This issue has been marked as a duplicate of issue 4379 ***