D.gnu - GDC release 1e
- David Friedman (11/11) Mar 28 2004 Another small update.
- resistor mac.com (4/15) Mar 28 2004 Very nice. Is there going to be a standardized naming scheme for versio...
- David Friedman (3/31) Mar 29 2004 Yes. Once the project gets out of "preview" state it is in now, I'll
- resistor mac.com (6/17) Mar 29 2004 Do you have any information about what the problems are compiling the fr...
- David Friedman (14/44) Mar 29 2004 The problem is that Apple integrated the C-specific code into the
- D user (5/5) Apr 04 2004 it really should be called GCD - GNU Compiler for the D Programming Lang...
- Another D user (4/4) Apr 06 2004 Well, I might as well add my two cents to this detail, since everyone el...
- =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= (9/13) Apr 14 2004 Precedent was set by GPC (Gnu Pascal Compiler, fyi)
- s31552 mail.ecc.u-tokyo.ac.jp (87/88) Apr 09 2004 Hello,
Another small update. http://home.earthlink.net/~dvdfrdmn/d/d-for-gcc-r1e.tgz Removed debug code from std.thread Autogenerate Unix definitions Instrinsics implemented in D code Correct iteration bounds for foreach on a static array Fix ICE when using an assignment expressions as a boolean value Fix ICE for new <struct> I installed Cygwin, DJGPP, and FreeBSD on my laptop. I should be able to Phobos working on these environments this week. David
Mar 28 2004
Very nice. Is there going to be a standardized naming scheme for versioning? Owen In article <pan.2004.03.29.03.39.55.564113 earthlink.net>, David Friedman says...Another small update. http://home.earthlink.net/~dvdfrdmn/d/d-for-gcc-r1e.tgz Removed debug code from std.thread Autogenerate Unix definitions Instrinsics implemented in D code Correct iteration bounds for foreach on a static array Fix ICE when using an assignment expressions as a boolean value Fix ICE for new <struct> I installed Cygwin, DJGPP, and FreeBSD on my laptop. I should be able to Phobos working on these environments this week. David
Mar 28 2004
Yes. Once the project gets out of "preview" state it is in now, I'll switch standard scheme. resistor mac.com wrote:Very nice. Is there going to be a standardized naming scheme for versioning? Owen In article <pan.2004.03.29.03.39.55.564113 earthlink.net>, David Friedman says...Another small update. http://home.earthlink.net/~dvdfrdmn/d/d-for-gcc-r1e.tgz Removed debug code from std.thread Autogenerate Unix definitions Instrinsics implemented in D code Correct iteration bounds for foreach on a static array Fix ICE when using an assignment expressions as a boolean value Fix ICE for new <struct> I installed Cygwin, DJGPP, and FreeBSD on my laptop. I should be able to Phobos working on these environments this week. David
Mar 29 2004
Do you have any information about what the problems are compiling the frontend with Apple's GCC code? Cause I think I'm going to have a go at it. Owen In article <pan.2004.03.29.03.39.55.564113 earthlink.net>, David Friedman says...Another small update. http://home.earthlink.net/~dvdfrdmn/d/d-for-gcc-r1e.tgz Removed debug code from std.thread Autogenerate Unix definitions Instrinsics implemented in D code Correct iteration bounds for foreach on a static array Fix ICE when using an assignment expressions as a boolean value Fix ICE for new <struct> I installed Cygwin, DJGPP, and FreeBSD on my laptop. I should be able to Phobos working on these environments this week. David
Mar 29 2004
The problem is that Apple integrated the C-specific code into the language independent parts. If I add in the C code, there are all sorts of symbol conflicts. Even if that was straightended out, there would be logic conflicts. When I started, I thought the C compiler would restrict what I wanted to do and that it did uneeded work (semantic analysis is already done by the DMD code), so I made a completely separate compiler like GNU Pascal. In retrospect, this may have been a mistake because I ended up duplicated a lot of code and missing out on some optimizations. Now that I know more about GCC, I think it would be feasible to base GDC on the C compiler. If you want to try to do this, good luck! The first thing to take a look at is the 'lang hooks'. David resistor mac.com wrote:Do you have any information about what the problems are compiling the frontend with Apple's GCC code? Cause I think I'm going to have a go at it. Owen In article <pan.2004.03.29.03.39.55.564113 earthlink.net>, David Friedman says...Another small update. http://home.earthlink.net/~dvdfrdmn/d/d-for-gcc-r1e.tgz Removed debug code from std.thread Autogenerate Unix definitions Instrinsics implemented in D code Correct iteration bounds for foreach on a static array Fix ICE when using an assignment expressions as a boolean value Fix ICE for new <struct> I installed Cygwin, DJGPP, and FreeBSD on my laptop. I should be able to Phobos working on these environments this week. David
Mar 29 2004
it really should be called GCD - GNU Compiler for the D Programming Language because the GCC stands for GNU Compiler Collection precedent was set by GCJ the name "GDC" looks like a new GNU debugger by the way great job on getting the D front end going !!
Apr 04 2004
Well, I might as well add my two cents to this detail, since everyone else will. Not many of the GCC compilers are acronyms today (and there really aren't that many: gcc, g++, g77, gnat). I'd just prefer getting the point "It's the D compiler" across. Wouldn't the name "gdd" fit?
Apr 06 2004
D user wrote:it really should be called GCD - GNU Compiler for the D Programming Language because the GCC stands for GNU Compiler CollectionGnu D Compilerprecedent was set by GCJPrecedent was set by GPC (Gnu Pascal Compiler, fyi)the name "GDC" looks like a new GNU debuggerAll the GCC tools look exactly the same. In fact, this entire malpractice of putting a G in front of pretty much anything is rather retarded, but there you go. My suggestion would be "Fllribid", courtesy of Rowan Atkinson. Cheers, Sigbjørn Lund Olsen
Apr 14 2004
Hello, I'll report some bugs. bug_foreach_continue.d: int main() { foreach (int i, char c; "ab") { printf("%d %c\n", i, c); continue; } return 0; } It can be compiled and linked and run. But it runs forever. I disassembled it and found no incl are called. foreach (int i, char c; "ab") { 8048efa: c6 45 ff 00 movb $0x0,0xffffffff(%ebp) 8048efe: c7 45 f8 00 00 00 00 movl $0x0,0xfffffff8(%ebp) 8048f05: c7 45 f4 e8 3f 05 08 movl $0x8053fe8,0xfffffff4(%ebp) 8048f0c: b8 01 00 00 00 mov $0x1,%eax 8048f11: 01 c0 add %eax,%eax 8048f13: 05 e8 3f 05 08 add $0x8053fe8,%eax 8048f18: 39 45 f4 cmp %eax,0xfffffff4(%ebp) 8048f1b: 72 02 jb 8048f1f <_Dmain+0x2b> 8048f1d: eb 26 jmp 8048f45 <_Dmain+0x51> 8048f1f: 8b 45 f4 mov 0xfffffff4(%ebp),%eax 8048f22: 0f b6 00 movzbl (%eax),%eax 8048f25: 88 45 ff mov %al,0xffffffff(%ebp) printf("%d %c\n", i, c); 8048f28: 0f b6 45 ff movzbl 0xffffffff(%ebp),%eax 8048f2c: 89 44 24 08 mov %eax,0x8(%esp,1) 8048f30: 8b 45 f8 mov 0xfffffff8(%ebp),%eax 8048f33: 89 44 24 04 mov %eax,0x4(%esp,1) 8048f37: c7 04 24 ea 3f 05 08 movl $0x8053fea,(%esp,1) 8048f3e: e8 11 fe ff ff call 8048d54 <_init+0x1a8> continue; 8048f43: eb c7 jmp 8048f0c <_Dmain+0x18> } bug_sync.d: void bug() { synchronized {} // compiler crash. } The gdb trace is following:gdb /usr/local/stow/gcc-gdc-3.3.2/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/cc1dGNU gdb Red Hat Linux (5.3.90-0.20030710.41rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run bug_sync.d -quiet -dumpbase bug_sync.d -auxbase bug_sync -g -version -o /tmp/ccTSGEeK.s Starting program: /usr/local/stow/gcc-gdc-3.3.2/lib/gcc-lib/i686-pc- inux-gnu/3.3.2/cc1d bug_sync.d -quiet -dumpbase bug_sync.d -auxbase bug_sync -g -version -o /tmp/ccTSGEeK.s GNU D version 3.3.2 (i686-pc-linux-gnu) compiled by GNU C version 3.3.2. GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=15833 Program received signal SIGSEGV, Segmentation fault. 0x080b4e24 in SynchronizedStatement::toIR(IRState*) (this=0x8db98b0, irs=0x8dc0d48) at ../../gcc/d/d-glue.cc:2625 2625 tree init = build(MODIFY_EXPR, void_type_node, decl, exp->toElem(irs)); Current language: auto; currently c++ (gdb) where irs=0x8dc0d48) at ../../gcc/d/d-glue.cc:2625 irs=0x8dc0d48) at ../../gcc/d/d-glue.cc:3039 at ../../gcc/d/d-glue.cc:2041 at ../../gcc/d/d-glue.cc:2108 at ../../gcc/toplev.c:5432 It's because this->exp is NULL when the second constructor of SynchronizedStatement is called. dmd/statement.c: SynchronizedStatement::SynchronizedStatement(Loc loc, elem *esync, Statement *bo dy) : Statement(loc) { this->exp = NULL; this->body = body; this->esync = esync; } ------------------ shinichiro.h s31552 mail.ecc.u-tokyo.ac.jp http://user.ecc.u-tokyo.ac.jp/~s31552/wp/
Apr 09 2004