gdc-4.7 (git) ICE

[Iain Buclaw]

On 24 October 2012 22:05, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:
> 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/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
>
> --
> He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter


The D FE's type system is not integrated into GCC's garbage collector.
 What I've done on the current trunk at least (will have to check what
4.7 looks like) is delay the genericizing of the codegen till after
all functions have been processed, instead of inbetween each function
- which has caused things to be GC'd in the past.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';