David Friedman wrote:
>

>> I don't think you need to do that. You can release this as gdc 0.11 ?
>> And then release DMD 0.120 compatibility as gdc 0.12 "pre" instead...
> 
> I still need to fix some bugs and update the documentation (including your man pages ;-)

I meant "fix the bugs in this one, *then* release it as 0.11" :-)

And wait with the new DMD features and stuff for 0.12 instead ?
(Assuming that it would be easier to release 0.11 without them)

--anders

This problem also doesn't work under gdc:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/21401

Some info regarding my bug with large files: I have lot's of things like (T/A/B) as described in the above.

Separate compilation always gives many errors like:

b.d:9: size of type T!(B) is not known
b.d:9: size of type T!(B) is not known

I'm not sure if this is a bug or feature? (both DMD and GDC behave the same.)

So I wrote a script to generate all of them into one big file, then DMD works. But GDC fails with: "virtual memory exhausted: Cannot allocate memory".

By setting CFLAGS='-O0 -g', I was able to debug gdc, but I don't know where to set breakpoint.

Detaching after fork from child process 20376.
virtual memory exhausted: Cannot allocate memory

Program exited with code 01.
(gdb)

Grep the error message doesn't give me much help, there are many occurance of "virtual memory exhausted", but not occurance of "Cannot allocate memory".

Can you give me some hint here, where to set break point to catch the stack trace?

David Friedman wrote:
> Lots of new features, not much documentation.  The full release will be made when I sync up with the latest DMD version.
> 
> http://home.earthlink.net/~dvdfrdmn/d/
> 
> Major Improvements:
> 
> * Updated to DMD 0.113
> * Phobos is now built as target library (i.e., no need for a separate build step.)
> * Boehm-gc is no longer used and the Java package is no longer required.
> * Inline assembler for x86 (some limitations compared to DMD)
> * Included Anders Björklund's patches to enable the use of frameworks on Darwin.
> 
> David

I just wanted to say thank you for all the work that you have put in to GDC.

Thanks
Brad

bug@d.com wrote:
> This problem also doesn't work under gdc:
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/21401
> 
> Some info regarding my bug with large files: I have lot's of things like (T/A/B)
> as described in the above.
> 
> Separate compilation always gives many errors like:
> 
> b.d:9: size of type T!(B) is not known
> b.d:9: size of type T!(B) is not known
> 
> I'm not sure if this is a bug or feature? (both DMD and GDC behave the same.)
> 
> So I wrote a script to generate all of them into one big file, then DMD works.
> But GDC fails with: "virtual memory exhausted: Cannot allocate memory".
> 
> By setting CFLAGS='-O0 -g', I was able to debug gdc, but I don't know where to
> set breakpoint.
> 
> Detaching after fork from child process 20376.
> virtual memory exhausted: Cannot allocate memory
> 
> Program exited with code 01.
> (gdb)
> 
> Grep the error message doesn't give me much help, there are many occurance of
> "virtual memory exhausted", but not occurance of "Cannot allocate memory".
> 
> Can you give me some hint here, where to set break point to catch the stack
> trace?
> 
> 

The program to run in gdb is 'cc1d'.  You can run gdc with the '-v' option to see what the exact command line for cc1d is.  Then set breakpoints on 'exit' and 'perror'.

David

In article <d3kfqs$2ptg$1@digitaldaemon.com>, David Friedman says...
>
>The program to run in gdb is 'cc1d'.  You can run gdc with the '-v' option to see what the exact command line for cc1d is.  Then set breakpoints on 'exit' and 'perror'.

Ah, I tried to set BP on 'exit' and 'perror' before with gdc, now I know why it doesn't work :-)

Here is the stack trace I got by watching cc1d.  If you need any more info, let me know.  Thanks.

-------------------------------------------------------------------------

(gdb) b perror
Breakpoint 2 at 0x4015f256
(gdb) b exit
Breakpoint 3 at 0x4013a386
(gdb) cont
Continuing.
GNU D version 3.3.5 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2,
pie-8.7.6).
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768

cc1d: out of memory allocating 4072 bytes after a total of 199913472 bytes

Breakpoint 3, 0x4013a386 in exit () from /lib/libc.so.6
(gdb) where
#0  0x4013a386 in exit () from /lib/libc.so.6
#1  0x08396eb9 in xexit (code=1) at xexit.c:52
#2  0x08396d3d in xmalloc_failed (size=4072) at xmalloc.c:132
#3  0x08396d6f in xmalloc (size=4072) at xmalloc.c:145
#4  0x401740e1 in _obstack_newchunk () from /lib/libc.so.6
#5  0x082ab8fb in new_insn_chain () at reload1.c:532
#6  0x08366405 in build_insn_chain (first=0x43c93840) at global.c:1826
#7  0x082e679e in rest_of_compilation (decl=0x4174f1c0) at toplev.c:3320
#8  0x080c86ed in FuncDeclaration::toObjFile() (this=0xe1eb1e8)
at d/d-glue.cc:1967
#9  0x0804bd35 in AttribDeclaration::toObjFile() (this=0xe1eb190)
at d/dmd/attrib.c:129
#10 0x080b3575 in ClassDeclaration::toObjFile() (this=0xe1e1490)
at d/dmd/toobj.c:211
#11 0x080b04d4 in TemplateInstance::toObjFile() (this=0x8626c48)
at d/dmd/template.c:1829
#12 0x080c8884 in Module::genobjfile() (this=0x8520ad0) at d/d-glue.cc:2217
#13 0x080b7d7e in d_parse_file(int) () at d/d-lang.cc:815
#14 0x082e4846 in compile_file () at toplev.c:2130
#15 0x082ea225 in do_compile () at toplev.c:5414
#16 0x082ea278 in toplev_main (argc=23, argv=0xbfffecb4) at toplev.c:5444
#17 0x080df626 in main (argc=23, argv=0xbfffecb4) at main.c:35
(gdb)

bug@d.com wrote:
> In article <d3kfqs$2ptg$1@digitaldaemon.com>, David Friedman says...
> 
>>The program to run in gdb is 'cc1d'.  You can run gdc with the '-v' option to see what the exact command line for cc1d is.  Then set breakpoints on 'exit' and 'perror'.
> 
> 
> Ah, I tried to set BP on 'exit' and 'perror' before with gdc, now I know why it doesn't work :-)
> 
> Here is the stack trace I got by watching cc1d.  If you need any more info, let me know.  Thanks.
> 
> -------------------------------------------------------------------------
> 
> (gdb) b perror
> Breakpoint 2 at 0x4015f256
> (gdb) b exit
> Breakpoint 3 at 0x4013a386
> (gdb) cont
> Continuing.
> GNU D version 3.3.5 (i686-pc-linux-gnu)
> compiled by GNU C version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2,
> pie-8.7.6).
> GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768
> 
> cc1d: out of memory allocating 4072 bytes after a total of 199913472 bytes
> 
> Breakpoint 3, 0x4013a386 in exit () from /lib/libc.so.6
> (gdb) where
> #0  0x4013a386 in exit () from /lib/libc.so.6
> #1  0x08396eb9 in xexit (code=1) at xexit.c:52
> #2  0x08396d3d in xmalloc_failed (size=4072) at xmalloc.c:132
> #3  0x08396d6f in xmalloc (size=4072) at xmalloc.c:145
> #4  0x401740e1 in _obstack_newchunk () from /lib/libc.so.6
> #5  0x082ab8fb in new_insn_chain () at reload1.c:532
> #6  0x08366405 in build_insn_chain (first=0x43c93840) at global.c:1826
> #7  0x082e679e in rest_of_compilation (decl=0x4174f1c0) at toplev.c:3320
> #8  0x080c86ed in FuncDeclaration::toObjFile() (this=0xe1eb1e8)
> at d/d-glue.cc:1967
> #9  0x0804bd35 in AttribDeclaration::toObjFile() (this=0xe1eb190)
> at d/dmd/attrib.c:129
> #10 0x080b3575 in ClassDeclaration::toObjFile() (this=0xe1e1490)
> at d/dmd/toobj.c:211
> #11 0x080b04d4 in TemplateInstance::toObjFile() (this=0x8626c48)
> at d/dmd/template.c:1829
> #12 0x080c8884 in Module::genobjfile() (this=0x8520ad0) at d/d-glue.cc:2217
> #13 0x080b7d7e in d_parse_file(int) () at d/d-lang.cc:815
> #14 0x082e4846 in compile_file () at toplev.c:2130
> #15 0x082ea225 in do_compile () at toplev.c:5414
> #16 0x082ea278 in toplev_main (argc=23, argv=0xbfffecb4) at toplev.c:5444
> #17 0x080df626 in main (argc=23, argv=0xbfffecb4) at main.c:35
> (gdb)
> 
> 

Here's something else to try:  Apply this patch to gcc/ggc-page.c and rebuild.  There's no need to run it in gdb; just try compiling the source file.  If it works, it means I have a garbage collection bug.

David

Tried, the same problem:

virtual memory exhausted: Cannot allocate memory

But the line number is different, I'm using gcc-3.3.5.


>Here's something else to try:  Apply this patch to gcc/ggc-page.c and rebuild.  There's no need to run it in gdb; just try compiling the source file.  If it works, it means I have a garbage collection bug.
>
>David
>
>
>--------------010200080606090909070300
>Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0";
> name="gcc-page.patch"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="gcc-page.patch"
>
>*** ggc-page.c.orig	Tue Apr 19 19:14:34 2005
>--- ggc-page.c	Sun Apr 24 15:24:37 2005
>***************
>*** 1774,1779 ****
>--- 1774,1780 ----
>  void
>  ggc_collect (void)
>  {
>+     return;
>    /* Avoid frequent unnecessary work by skipping collection if the
>       total allocations haven't expanded much since the last
>       collection.  */
>
>--------------010200080606090909070300--