D.gnu - gdc-4.7 (git) ICE
- H. S. Teoh (47/47) Oct 24 2012 I need some help to track down...
I need some help to track down a GDC bug. I'm getting a bunch of ICE's (on gdc-4.7 git branch) that seem to be highly sensitive to the precise amount of code being compiled: For example: /mnt/1/usr/src/d/gdcroot/include/d/4.7/std/algorithm.d: In member function= 'map': /mnt/1/usr/src/d/gdcroot/include/d/4.7/std/algorithm.d:368:0: internal com= piler error: tree check: expected class 'type', have 'exceptional' (H=89=DF= =E8=183=FE=FF=85=C0=0F=84=F8 ) in getFrameInfo, at d/d-codegen.cc:3836 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. And: veclist.d: In function 'matchOp': veclist.d:79:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. On one or two occasions, GDC complains that virtual memory is exhausted, but by simply adding a few more lines of code, it miraculously compiles with no problem. So it doesn't seem to be an actual OOM problem, but probably some internal memory corruption that makes it think it's run out of memory. These errors only happen when I pass a whole bunch of files to gdc at once. Compiling each of the files separately does not have this problem. Permuting the order of files passed to GDC also sometimes makes the problem disappear. I've tried to reduce the code, but was unable to get beyond trimming a few files and most of the code in one or two files. I still have 6 non-trivial files, and have gotten to the point where deleting any more code appears to make the problem go away. Judging from where the errors occur, though, the problem appears to be related to deeply-nested templates and enums (but I'm not 100% sure about the latter). The reported location of the error is not constant, but randomly moves about as I reduced the code, usually sitting on a function call or a template instantiation, and always roughly near a certain line number in the source file (though it does migrate from file to file). Any thoughts as to how to reduce the code further so that I can narrow down the problem? Any clues that might be indicated by the error messages above? Thanks! T --=20 He who sacrifices functionality for ease of use, loses both and deserves ne= ither. -- Slashdotter
Oct 24 2012