gdc-4.7 (git) ICE

H. S. Teoh hsteoh at
Wed Oct 24 14:05:31 PDT 2012

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 compiler error: tree check: expected class 'type', have 'exceptional' (H‰ßè3þÿ
	) in getFrameInfo, at d/
	Please submit a full bug report,
	with preprocessed source if appropriate.
	See <> for instructions.


	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 <> 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?



He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter

More information about the D.gnu mailing list