www.digitalmars.com         C & C++   DMDScript  

D.gnu - GDC Release

reply teqDruid <me teqdruid.com> writes:
David (or anyone else capable of doing it), are you planning on releasing
an updated GDC anytime soon?  My program uses features introduced in 0.99,
so it don't work too well with GDC.

Thanks
John
Sep 24 2004
parent reply David Friedman <d3rdclsmail earthlink.net> writes:
teqDruid wrote:
 David (or anyone else capable of doing it), are you planning on releasing
 an updated GDC anytime soon?  My program uses features introduced in 0.99,
 so it don't work too well with GDC.
 
 Thanks
 John

GDC is synched up to DMD 0.102 and am I now regression testing. If there are no serious setbacks, I will release a new version this weekend. David
Sep 28 2004
next sibling parent reply Benjamin Herr <ben 0x539.de> writes:
David Friedman wrote:
 GDC is synched up to DMD 0.102 and am I now regression testing.  If 
 there are no serious setbacks, I will release a new version this weekend.
 
 David
 

I am looking forward to this weekend for yet one more reason then :) I would appreciate if you provided your test suite so I could do some amd64 tests, once I manage to build gdc. Also, if I can help you without challenging my less than awesome coding skills, I would like to assist. -ben
Sep 28 2004
next sibling parent David Friedman <d3rdclsmail earthlink.net> writes:
Benjamin Herr wrote:
 David Friedman wrote:
 
 GDC is synched up to DMD 0.102 and am I now regression testing.  If 
 there are no serious setbacks, I will release a new version this weekend.

 David

I am looking forward to this weekend for yet one more reason then :) I would appreciate if you provided your test suite so I could do some amd64 tests, once I manage to build gdc. Also, if I can help you without challenging my less than awesome coding skills, I would like to assist. -ben

I'll try to put something toghether that is usable ;-) Although the compiler can generate 64-bit code, the RTTI pieces and Phobos assume 32-bit in a lot places. Still, please do try it out to the extent that it is possible. David
Sep 28 2004
prev sibling parent reply David Friedman <d3rdclsmail earthlink.net> writes:
Benjamin Herr wrote:

[snip]
 
 I am looking forward to this weekend for yet one more reason then :)
 I would appreciate if you provided your test suite so I could do some 
 amd64 tests, once I manage to build gdc.
 
 Also, if I can help you without challenging my less than awesome coding 
 skills, I would like to assist.
 
 -ben

Ben, Adding 64-bit support to gdc is going to require a lot of changes to Phobos. You can help by identifying what needs to be changed and/or coding. I don't have access to a 64-bit environment (*) so this will be a big help. David (*) Hoping Apple releases Tiger soon...
Oct 03 2004
parent reply Benjamin Herr <ben 0x539.de> writes:
David Friedman wrote:
 Ben,
 
 Adding 64-bit support to gdc is going to require a lot of changes to 
 Phobos.  You can help by identifying what needs to be changed and/or 
 coding.  I don't have access to a 64-bit environment (*) so this will be 
  a big help.
 
 David
 
 (*) Hoping Apple releases Tiger soon...

$ gdc foo.d cc1d: /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/dmd/lexer.c:1533: TOK Lexer::number(Token*): Assertion `sizeof(long) == 4' failed. foo.d:0: internal compiler error: Aborted Release 1f did not fail like this, which surprises me.
Oct 04 2004
parent reply Benjamin Herr <ben 0x539.de> writes:
Hoi,

this is a kind of a transcript of my attempts to compile a hello world D 
program with gdc. >-prefixed lines give console input and output, the 
other lines are my comments, obviously

I use Gentoo, so I installed gdc by emerge'ing gcc-3.4.2, stopped it 
before it started to compile, added the gdc directory, applied the 
patches and changed the gcc-related ebuilds to know about the D frontend.

 $ uname -a
 Linux oreichalkon 2.6.8-gentoo-r4 #1 Fri Sep 24 19:46:07 CEST 2004 

 $ cat foo.d
 int main() {
	printf("Hallo\n");
	return 0;
 }
 $ gdc -o foo foo.d
 cc1d: 

Lexer::number(Token*): Assertion `sizeof(long) == 4' failed.
 foo.d:0: internal compiler error: Aborted

I changed to assert(sizeof(long >= 4);
 gdc -o foo foo.d
 /usr/libexec/gcc/x86_64-pc-linux-gnu/3.4.2/cc1d: error while loading 

such file or directory
 $ gdc -o foo foo.d
 /usr/libexec/gcc/x86_64-pc-linux-gnu/3.4.2/cc1d: error while loading 

file or directory Both times the libs were in /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/ but according to strace, only /lib64/tls/x86_64, /lib64/x86_64, /lib64, /usr/lib64/tls/x86_64, /usr/lib64/x86_64, /usr/lib64/ were checked. I added symlinks in /usr/lib64 because I was too lazy to figure out how to do this correctly, or what I broke in first place.
 $ gdc -o foo foo.d
 

C style cast deprecated, use cast(void*)(this) ... and many more such warnings. object.d was casting this-pointers and object references to void-pointers and then to int. I fixed the (foo) casts to cast(foo), and replaced int and uint with ptrdiff_t and size_t respectively; however we need to come up with a better Object#toHash than converting `this' to an int, as int.sizeof < (void*).sizeof. Also, it might make sense to define opCmp as int opCmp(Object other) { void* t = cast(void *)this, o = cast(void *)other; return t == o ? 0 : t < o ? -1 : t > o ? 1 : (assert(false), 0); } A diff is at http://ilfirin.org/object.d.diff
 d $ gdc -o foo foo.d
 d $ ./foo
 Hallo
 Segmentation fault

gdb reveals: Program received signal SIGSEGV, Segmentation fault. _moduleDtor () at ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit.d:162 162 ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit.d: No such file or directory. in ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit I realise I forgot to rebuild phobos *cough*, although this error already happened last time with the 1f release and correctly built phobos. So I tried to compile phobos. There is a problem with phobos' configure passing 'CC=gcc' 'CXX=g++' to boehm-gc's configure, which it interprets as target hosts: > configure: warning: CC=gcc: invalid host type > configure: warning: CXX=g++: invalid host type > configure: error: can only configure for one host and one target at a time > configure: error: /bin/sh '../../../gcc-3.4.2/gcc/d/phobos/boehm-gc/configure' failed for boehm-gc I had a hacky Ruby script strip non-options from the command line > # make > gcc -o config/gen_unix.o -g -O2 -DPHOBOS_USE_PTHREADS=1 -DHAVE_CONFIG_H -I etc/c/stlsoft -I . -c /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/config/gen_unix.c > gcc -o gen_unix config/gen_unix.o > ./gen_unix > frag-unix > /bin/sh: line 1: 2060 Segmentation fault ./gen_unix >frag-unix > make: *** [frag-unix] Error 139 gdb says 0x0000000000402843 in __PRETTY_FUNCTION__.0 () I ended up using the output produced until the segfault and adding the rest manually. > cc1d: /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/dmd/toobj.c:252: virtual void ClassDeclaration::toObjFile(): Assertion `classinfo->structsize == 0x3C' failed. > /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/std/asserterror.d: In function `_ctor': > /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/std/asserterror.d:42: internal compiler error: Aborted Assumption that (void*).sizeof and a reference's size is 4, and a dynamic array's size is 8. I changed the #define'ition of CLASSINFO_SIZE from 0x3c to sizeof(void*)*2 * 4 + sizeof(void*)*4 + sizeof(int) in aggregate.h:197. Trying to recompile gdc, it does not find libgcc_s.so. I must have broken it somewhere above; I added another symlink and started compiling again. Now I do not have enough time until I have to leave for four more hours of school, so I will just post this now and continue trying after school. I greatly appreciate the effort you have already put into this project, and hope that my data is of use. I will certainly try to fix more issues as I come across them, and I will report them. I hope that Walter will make his part of the frontend less dependant on machine word sizes so porting will be easier. -ben
Oct 04 2004
parent reply David Friedman <d3rdclsmail earthlink.net> writes:
nowBenjamin Herr wrote:
 Hoi,
 
 this is a kind of a transcript of my attempts to compile a hello world D 
 program with gdc. >-prefixed lines give console input and output, the 
 other lines are my comments, obviously
 
 I use Gentoo, so I installed gdc by emerge'ing gcc-3.4.2, stopped it 
 before it started to compile, added the gdc directory, applied the 
 patches and changed the gcc-related ebuilds to know about the D frontend.
 
  > $ uname -a
  > Linux oreichalkon 2.6.8-gentoo-r4 #1 Fri Sep 24 19:46:07 CEST 2004 
 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
  > $ cat foo.d
  > int main() {
  >    printf("Hallo\n");
  >    return 0;
  > }
  > $ gdc -o foo foo.d
  > cc1d: 
 /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/dmd/lexer.c:1533: TOK 
 Lexer::number(Token*): Assertion `sizeof(long) == 4' failed.
  > foo.d:0: internal compiler error: Aborted
 
   I  changed to assert(sizeof(long >= 4);
 
  > gdc -o foo foo.d
  > /usr/libexec/gcc/x86_64-pc-linux-gnu/3.4.2/cc1d: error while loading 
 shared libraries: libstdc++.so.6: cannot open shared object file: No 
 such file or directory
 
  > $ gdc -o foo foo.d
  > /usr/libexec/gcc/x86_64-pc-linux-gnu/3.4.2/cc1d: error while loading 
 shared libraries: libgcc_s.so.1: cannot open shared object file: No such 
 file or directory
 
   Both times the libs were in /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/ 
 but according to strace, only /lib64/tls/x86_64, /lib64/x86_64, /lib64, 
 /usr/lib64/tls/x86_64, /usr/lib64/x86_64, /usr/lib64/ were checked.
   I added symlinks in /usr/lib64 because I was too lazy to figure out 
 how to do this correctly, or what I broke in first place.
 
 
  > $ gdc -o foo foo.d
  > 
 /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/../../../../include/d/object.d(32): 
 C style cast deprecated, use cast(void*)(this)
 
   ... and many more such warnings.
   object.d was casting this-pointers and object references to 
 void-pointers and then to int. I fixed the (foo) casts to cast(foo), and 
 replaced int and uint with ptrdiff_t and size_t respectively; however we 
 need to come up with a better Object#toHash than converting `this' to an 
 int, as int.sizeof < (void*).sizeof. Also, it might make sense to define 
 opCmp as
   int opCmp(Object other) {
     void* t = cast(void *)this, o = cast(void *)other;
     return t == o ? 0 : t < o ? -1 : t > o ? 1 : (assert(false), 0);
   }
   A diff is at http://ilfirin.org/object.d.diff
 
  > d $ gdc -o foo foo.d
  > d $ ./foo
  > Hallo
  > Segmentation fault
 
   gdb reveals:
   Program received signal SIGSEGV, Segmentation fault.
   _moduleDtor () at ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit.d:162
   162     ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit.d: No such file or 
 directory.
           in ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit
 
   I realise I forgot to rebuild phobos *cough*, although this error 
 already happened last time with the 1f release and correctly built phobos.
   So I tried to compile phobos.
   There is a problem with phobos' configure passing 'CC=gcc' 'CXX=g++' 
 to boehm-gc's configure, which it interprets as target hosts:
   > configure: warning: CC=gcc: invalid host type
   > configure: warning: CXX=g++: invalid host type
   > configure: error: can only configure for one host and one target at 
 a time
   > configure: error: /bin/sh 
 '../../../gcc-3.4.2/gcc/d/phobos/boehm-gc/configure' failed for boehm-gc
   I had a hacky Ruby script strip non-options from the command line
 
   > # make
   > gcc -o config/gen_unix.o -g -O2 -DPHOBOS_USE_PTHREADS=1 
 -DHAVE_CONFIG_H -I etc/c/stlsoft -I . -c 
 /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/config/gen_unix.c
   > gcc -o gen_unix config/gen_unix.o
   > ./gen_unix > frag-unix
   > /bin/sh: line 1:  2060 Segmentation fault      ./gen_unix >frag-unix
   > make: *** [frag-unix] Error 139
   gdb says 0x0000000000402843 in __PRETTY_FUNCTION__.0 ()
   I ended up using the output produced until the segfault and adding the 
 rest manually.
 
   > cc1d: 
 /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/dmd/toobj.c:252: 
 virtual void ClassDeclaration::toObjFile(): Assertion 
 `classinfo->structsize == 0x3C' failed.
   > 
 /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/std/asserterror.d: 
 In function `_ctor':
   > 
 /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/s
d/asserterror.d:42: 
 internal compiler error: Aborted
   Assumption that (void*).sizeof and a reference's size is 4, and a 
 dynamic array's size is 8.
   I changed the #define'ition of CLASSINFO_SIZE from 0x3c to 
 sizeof(void*)*2 * 4 + sizeof(void*)*4 + sizeof(int) in aggregate.h:197.
   Trying to recompile gdc, it does not find libgcc_s.so. I must have 
 broken it somewhere above; I added another symlink and started compiling 
 again.
   Now I do not have enough time until I have to leave for four more 
 hours of school, so I will just post this now and continue trying after 
 school.
 
 
 I greatly appreciate the effort you have already put into this project, 
 and hope that my data is of use. I will certainly try to fix more issues 
 as I come across them, and I will report them.
 
 I hope that Walter will make his part of the frontend less dependant on 
 machine word sizes so porting will be easier.
 
   -ben

Thanks for trying it out! I guess my own code isn't 64-bit clean (gen_unix crash.) The shared library error is similar to what I got when I tried to do a bootstrap build -- the C++ executables become dependent on the new libraries which are not yet installed. Once installed, though, you can set the LD_LIBRARY_PATH environment variable. For building Phobos, I usually just change the PATH so that gdc and the same-version C and C++ compilers are the default and I don't have to do anything special for the configure script. If you do this, remember to use the original system compiler to rebuild gdc. BTW, if you want to try out the compiler without Phobos, you can compile with -fno-exceptions and use a C-style main (i.e, extern(C) int main(int, char**) {...}). This severely limits what you can do, but at least you can make executables. David
Oct 04 2004
parent reply Benjamin Herr <ben 0x539.de> writes:
David Friedman wrote:
 Thanks for trying it out!  I guess my own code isn't 64-bit clean 
 (gen_unix crash.)

I have no idea how that piece of code could crash, and I would rather blame it on some messup on my side instead of your code.
 The shared library error is similar to what I got when I tried to do a 
 bootstrap build -- the C++ executables become dependent on the new 
 libraries which are not yet installed.  Once installed, though, you can 
 set the LD_LIBRARY_PATH environment variable.

 For building Phobos, I usually just change the PATH so that gdc and the 
 same-version C and C++ compilers are the default and I don't have to do 
 anything special for the configure script.  If you do this, remember to 
 use the original system compiler to rebuild gdc.

compile all this, and I did not attempt to do anything special. I do not think I did anything to cause the configure script to put these strange parameters, assuming that is what you are referring to.
 BTW, if you want to try out the compiler without Phobos, you can compile 
 with -fno-exceptions and use a C-style main (i.e, extern(C) int 
 main(int, char**) {...}).  This severely limits what you can do, but at 
 least you can make executables.

on my system, so I can indeed play around a bit already. But thanks for the hint, as this will probably need to non-segfaulting executables :) Slightly updated transcript, up to the point where I am now stuck: http://ilfirin.org/gdc Note that my previous attempt to redefine CLASSINFO_SIZE was wrong, and the current one is more or less based on coincidence as I have no clue what a monitor_t is. -ben
Oct 04 2004
parent David Friedman <d3rdclsmail earthlink.net> writes:
Benjamin Herr wrote:
 David Friedman wrote:
 
 Thanks for trying it out!  I guess my own code isn't 64-bit clean 
 (gen_unix crash.)

Thanks for allowing me to try it out :) I have no idea how that piece of code could crash, and I would rather blame it on some messup on my side instead of your code.

Ah, but did I did find a bug -- used a '%d' format with a ptrdiff_t argument.
 The shared library error is similar to what I got when I tried to do a 
 bootstrap build -- the C++ executables become dependent on the new 
 libraries which are not yet installed.  Once installed, though, you 
 can set the LD_LIBRARY_PATH environment variable.

Meh, it works like this.
 For building Phobos, I usually just change the PATH so that gdc and 
 the same-version C and C++ compilers are the default and I don't have 
 to do anything special for the configure script.  If you do this, 
 remember to use the original system compiler to rebuild gdc.

I do indeed use the original system compiler which now features gdc to compile all this, and I did not attempt to do anything special. I do not think I did anything to cause the configure script to put these strange parameters, assuming that is what you are referring to.

Now that you mention it, I think I saw this before. I can't remember what the cause was.
 BTW, if you want to try out the compiler without Phobos, you can 
 compile with -fno-exceptions and use a C-style main (i.e, extern(C) 
 int main(int, char**) {...}).  This severely limits what you can do, 
 but at least you can make executables.

I actually still have a semi-working phobos installation from release 1f on my system, so I can indeed play around a bit already. But thanks for the hint, as this will probably need to non-segfaulting executables :) Slightly updated transcript, up to the point where I am now stuck: http://ilfirin.org/gdc Note that my previous attempt to redefine CLASSINFO_SIZE was wrong, and the current one is more or less based on coincidence as I have no clue what a monitor_t is. -ben

The monitor field is a pointer to a platform-specific synchronization object. I'll check out the updated transcript. David
Oct 04 2004
prev sibling next sibling parent teqDruid <me teqdruid.com> writes:
Awesome! You da man David!

John

On Tue, 28 Sep 2004 08:05:26 -0500, David Friedman wrote:

 teqDruid wrote:
 David (or anyone else capable of doing it), are you planning on releasing
 an updated GDC anytime soon?  My program uses features introduced in 0.99,
 so it don't work too well with GDC.
 
 Thanks
 John

GDC is synched up to DMD 0.102 and am I now regression testing. If there are no serious setbacks, I will release a new version this weekend. David

Sep 28 2004
prev sibling next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
David Friedman wrote:

 teqDruid wrote:
 David (or anyone else capable of doing it), are you planning on releasing
 an updated GDC anytime soon?  My program uses features introduced in
 0.99, so it don't work too well with GDC.
 
 Thanks
 John

GDC is synched up to DMD 0.102 and am I now regression testing. If there are no serious setbacks, I will release a new version this weekend. David

excellent news! Thanks for not letting GDC drop.
Sep 28 2004
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
<posted & mailed>

David Friedman wrote:

 teqDruid wrote:
 David (or anyone else capable of doing it), are you planning on releasing
 an updated GDC anytime soon?  My program uses features introduced in
 0.99, so it don't work too well with GDC.
 
 Thanks
 John

GDC is synched up to DMD 0.102 and am I now regression testing. If there are no serious setbacks, I will release a new version this weekend. David

David - thanks for all of your work on this!! I would like to suggest a couple of changes to the default D -> GCC compiler option mappings: (In decending order of importance) -O implies -fno-bounds-check by default -O implies -fomit-frame-pointer -O implies -fweb and -fgcse-after-reload -O implies -mcpu=pentium4 (>= 3.4.x: -mtune=pentium4) Also add the -funroll-loops option. Rationale (sorry, this gets a bit long): The DMD 'reference compiler' turns off bounds checking with -0 and of course this can really make a large difference. From my understanding in following the NG threads it's pretty well accepted and understood by D users that -O will do this. -fomit-frame-pointer is something that (I've read) the GCC group has been discussing making implied for x86 with any -O option in coming versions of GCC (The docs. for <= 3.4.x said it was implied by -O[n] for x86 but it turns out it actually isn't currently..). D code should not have the legacy debugging issues to deal with and from what I've seen this switch can make a big difference in code speed where a lot of functions are being called. -fweb and -fgcse-after-reload.. Along with the -inline switch, this will bring the optimization up to '-O3' levels. I've used -O3 to good effect for a couple of production executables and seen it make a big difference in benchmarks as well - I've also never seen it degrade performance. I'm seeing a number of make files starting to use this option. -mtune=pentium4 - Can make a sizeable difference for P4 while not really effecting < P4 machines. Of course, the most performance intensive applications will be run on P4 class machines. Unroll loops - GCC seems to be getting pretty good at this and I've seen it make a difference in production code with GCC >= 3.3.x. The overall rationale for these changes is simply to make sure the GCC implementation of D puts its 'best foot' forward so D doesn't get needlessly/unfairly tagged with performance issues that can be avoided with default -O swtiches. I've noticed that many of the 'GCC vs X' benchmarks out there for which GCC does poorly are often due to /not/ applying the (perfectly legimate) -O3 and -fomit-frame-pointer switches. Besides, the 'competition' from Intel, MS, etc.. generally optimize with levels comparable to -O3 with any of their default 'for speed' switches. If there is some regression testing or something that I could help with if/when these changes are made, I'd be glad to do what I can.. Thanks, - Dave
Sep 30 2004
next sibling parent reply David Friedman <d3rdclsmail earthlink.net> writes:
Dave wrote:
 <posted & mailed>
 
 David Friedman wrote:
 
 
teqDruid wrote:

David (or anyone else capable of doing it), are you planning on releasing
an updated GDC anytime soon?  My program uses features introduced in
0.99, so it don't work too well with GDC.

Thanks
John

GDC is synched up to DMD 0.102 and am I now regression testing. If there are no serious setbacks, I will release a new version this weekend. David

David - thanks for all of your work on this!! I would like to suggest a couple of changes to the default D -> GCC compiler option mappings: (In decending order of importance) -O implies -fno-bounds-check by default -O implies -fomit-frame-pointer -O implies -fweb and -fgcse-after-reload -O implies -mcpu=pentium4 (>= 3.4.x: -mtune=pentium4) Also add the -funroll-loops option. Rationale (sorry, this gets a bit long): The DMD 'reference compiler' turns off bounds checking with -0 and of course this can really make a large difference. From my understanding in following the NG threads it's pretty well accepted and understood by D users that -O will do this. -fomit-frame-pointer is something that (I've read) the GCC group has been discussing making implied for x86 with any -O option in coming versions of GCC (The docs. for <= 3.4.x said it was implied by -O[n] for x86 but it turns out it actually isn't currently..). D code should not have the legacy debugging issues to deal with and from what I've seen this switch can make a big difference in code speed where a lot of functions are being called. -fweb and -fgcse-after-reload.. Along with the -inline switch, this will bring the optimization up to '-O3' levels. I've used -O3 to good effect for a couple of production executables and seen it make a big difference in benchmarks as well - I've also never seen it degrade performance. I'm seeing a number of make files starting to use this option. -mtune=pentium4 - Can make a sizeable difference for P4 while not really effecting < P4 machines. Of course, the most performance intensive applications will be run on P4 class machines. Unroll loops - GCC seems to be getting pretty good at this and I've seen it make a difference in production code with GCC >= 3.3.x. The overall rationale for these changes is simply to make sure the GCC implementation of D puts its 'best foot' forward so D doesn't get needlessly/unfairly tagged with performance issues that can be avoided with default -O swtiches. I've noticed that many of the 'GCC vs X' benchmarks out there for which GCC does poorly are often due to /not/ applying the (perfectly legimate) -O3 and -fomit-frame-pointer switches. Besides, the 'competition' from Intel, MS, etc.. generally optimize with levels comparable to -O3 with any of their default 'for speed' switches. If there is some regression testing or something that I could help with if/when these changes are made, I'd be glad to do what I can.. Thanks, - Dave

Dave, -fweb and -fomit-frame-pointer: I'll add these (along with -frename-registers). -fgcse-after-reload: does not seem to be in recent GCC versions. -mtune and -funroll-loops: I need to do some checking on these... What was the reference for -O turning off bounds checking? I made a quick test of bounds checking with -O and I still got an ArrayBoundsError. FYI, anyone comparing GCC to DMD is going to see GCC lagging behind a bit as there are some x86 optimizations that require extra coding. I still need to make D linkage functions use the same calling conventions as DMD (effectively, -mregparm=1 and -freg-struct-return.) David
Oct 01 2004
next sibling parent reply Dave <Dave_member pathlink.com> writes:
David Friedman wrote:

 Dave wrote:
 <posted & mailed>


 

Dave, -fweb and -fomit-frame-pointer: I'll add these (along with -frename-registers). -fgcse-after-reload: does not seem to be in recent GCC versions. -mtune and -funroll-loops: I need to do some checking on these... What was the reference for -O turning off bounds checking? I made a quick test of bounds checking with -O and I still got an ArrayBoundsError.

Oops, sorry - for DMD, ArrayBoundsChecking is removed with '-release', not '-O'. Since GDC offers -f[no-]bounds-check seperately, I guess I assumed that bounds checking is controlled independently of other switch(es). I don't have a machine available right now to install GDC and give this a shot myself.. If '-release' already implies -fno-bounds-check please disregard. Thanks again, - Dave
 
 FYI, anyone comparing GCC to DMD is going to see GCC lagging behind a
 bit as there are some x86 optimizations that require extra coding.  I
 still need to make D linkage functions use the same calling conventions
 as DMD (effectively, -mregparm=1 and -freg-struct-return.)
 
 David

Oct 02 2004
parent David Friedman <d3rdclsmail earthlink.net> writes:
Dave wrote:
 David Friedman wrote:
 
 
Dave wrote:

<posted & mailed>


[snip]
Dave,

-fweb and -fomit-frame-pointer: I'll add these (along with
-frename-registers).
-fgcse-after-reload: does not seem to be in recent GCC versions.
-mtune and -funroll-loops: I need to do some checking on these...

What was the reference for -O turning off bounds checking?  I made a
quick test of bounds checking with -O and I still got an ArrayBoundsError.

Oops, sorry - for DMD, ArrayBoundsChecking is removed with '-release', not '-O'. Since GDC offers -f[no-]bounds-check seperately, I guess I assumed that bounds checking is controlled independently of other switch(es). I don't have a machine available right now to install GDC and give this a shot myself.. If '-release' already implies -fno-bounds-check please disregard.

It does. I implemented -fbounds-check because it is actually defined as a common option across all GCC compilers. It's interesting considering that the most popular languages don't use it! David
 
 Thanks again,
 
 - Dave
 
 
FYI, anyone comparing GCC to DMD is going to see GCC lagging behind a
bit as there are some x86 optimizations that require extra coding.  I
still need to make D linkage functions use the same calling conventions
as DMD (effectively, -mregparm=1 and -freg-struct-return.)

David


Oct 02 2004
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
 David Friedman wrote:

-fweb and -fomit-frame-pointer: I'll add these (along with -frename-registers). -fgcse-after-reload: does not seem to be in recent GCC versions. -mtune and -funroll-loops: I need to do some checking on these...

You were right to question the -mtune=pentium4 and I was a little hasty to suggest it.. Simply issuing this switch by default would have actually stopped the compilation on non-intel/amd (or AMD64 in 64 bit mode) machines. I should have considered that and maybe other potential issues with the switch more carefully.. Would it be feasible/acceptable to allow -mcpu/-mtune as a pass-through type of option in some later release? I see you made the -O3 related changes to the 1g release - Thanks! - Dave
Oct 04 2004
parent reply David Friedman <d3rdclsmail earthlink.net> writes:
Dave wrote:
David Friedman wrote:

Dave, -fweb and -fomit-frame-pointer: I'll add these (along with -frename-registers). -fgcse-after-reload: does not seem to be in recent GCC versions. -mtune and -funroll-loops: I need to do some checking on these...

You were right to question the -mtune=pentium4 and I was a little hasty to suggest it.. Simply issuing this switch by default would have actually stopped the compilation on non-intel/amd (or AMD64 in 64 bit mode) machines. I should have considered that and maybe other potential issues with the switch more carefully.. Would it be feasible/acceptable to allow -mcpu/-mtune as a pass-through type of option in some later release? I see you made the -O3 related changes to the 1g release - Thanks! - Dave

I planned to check for x86 first, but I didn't feel comfortable enabling 'tradeoff' options by default. The -mxxx options should already work (both dmd and gdc commands). David
Oct 04 2004
parent reply some where.com writes:
Is gdb fully functional with the executable generated by GDC?

If not, what works, and what not yet?
Oct 04 2004
parent David Friedman <d3rdclsmail earthlink.net> writes:
some where.com wrote:

 Is gdb fully functional with the executable generated by GDC?
 
 If not, what works, and what not yet?
 
 

I would say gdb is "very much usable" ;-) You can trace through code, inspect global and local variables, set breakpoints on specific lines, etc. What doesn't work: . Name mangling -- this affects global values. Fixing this will probably require a patch to gdb. . Inspection of local variables and arguments in nested functions -- The problems vary depending on the debugging standard used. This might be a problem with gdb itself, however. . Classes and structs don't have their methods defined (so they can't be called easily.) . Local variables appear in scope before they should (actually a code gen issue). David
Oct 04 2004
prev sibling next sibling parent reply Jonathan Leffler <jleffler earthlink.net> writes:
Dave wrote:
 [...]
 I would like to suggest a couple of changes to the default D -> GCC compiler
 option mappings:
 
 (In decending order of importance)
 
 -O implies -fno-bounds-check by default
 -O implies -fomit-frame-pointer
 -O implies -fweb and -fgcse-after-reload
 -O implies -mcpu=pentium4 (>= 3.4.x: -mtune=pentium4)
 Also add the -funroll-loops option.
 
 Rationale (sorry, this gets a bit long):

All the world is not using Pentiums (just as in a previous generation, all the world was not a VAX) -- some people use other CPU chips. Specifically, MacOS X uses PowerPC. I assume that this would have been noted and covered - just double-checking. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler earthlink.net, jleffler us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
Oct 03 2004
parent Benjamin Herr <ben 0x539.de> writes:
Jonathan Leffler wrote:
 All the world is not using Pentiums (just as in a previous generation, 
 all the world was not a VAX) -- some people use other CPU chips. 
 Specifically, MacOS X uses PowerPC.  I assume that this would have been 
 noted and covered - just double-checking.

And that I use amd64 is around the most important reason I am so interested in gdc :) -ben
Oct 03 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Dave schrieb:

 -mtune=pentium4 - Can make a sizeable difference for P4 while not really
 effecting < P4 machines. Of course, the most performance intensive
 applications will be run on P4 class machines.

Really? Call me oldskool, i have learned to prefer Pentium (P5, some people call them i586) tunings on x86. This is a significant boost on the original Pentium because it makes use of 2 pipelines by pairing the instructions, and Pentium Pro (P6, some people call them i686) specific tuning didn't bring much compared to that on P6 machines, but there was a significant adverse effect on P5. Reason is key novelty of P6 architecture: three pipelines are symmetric and execute in parallel and out-of-order without too strict special conditions, while for P5 the opcodes must explicitly "pair". What kind of tuning is done for Pentium 4? Why do you think it doesn't adversely affect performance on P6 and similar machines (Athlons and such)? I'm currently somewhat out-of-date, so i don't even know what kind of new optimizations Pentium 4 can apply or where new bottlenecks are. BTW, the naming "P4" is problematic. You see why above. Is there any other short for it, or should i just get used to calling older systems i586/i686 instead of P5/P6? -eye
Oct 03 2004
parent reply Dave <Dave_member pathlink.com> writes:
Ilya Minkov wrote:

 Dave schrieb:
 
 -mtune=pentium4 - Can make a sizeable difference for P4 while not really
 effecting < P4 machines. Of course, the most performance intensive
 applications will be run on P4 class machines.

Really? Call me oldskool, i have learned to prefer Pentium (P5, some people call them i586) tunings on x86. This is a significant boost on the original Pentium because it makes use of 2 pipelines by pairing the instructions, and Pentium Pro (P6, some people call them i686) specific tuning didn't bring much compared to that on P6 machines, but there was a significant adverse effect on P5. Reason is key novelty of P6 architecture: three pipelines are symmetric and execute in parallel and out-of-order without too strict special conditions, while for P5 the opcodes must explicitly "pair". What kind of tuning is done for Pentium 4? Why do you think it doesn't adversely affect performance on P6 and similar machines (Athlons and such)? I'm currently somewhat out-of-date, so i don't even know what kind of new optimizations Pentium 4 can apply or where new bottlenecks are. BTW, the naming "P4" is problematic. You see why above. Is there any other short for it, or should i just get used to calling older systems i586/i686 instead of P5/P6? -eye

Frankly and on second thought, I could be wrong to suggest this, because I'm basing that suggestion off of tests done with an older-than-current version of GCC and only on a PIII to compare it with. What I've noticed in the benchmarks I've run is that -mcpu=pentium4 does generally make some code a decent amount faster on both P4 and AthlonXP/AMD64 (32 bit mode) chips, while not really effecting the results on the PIII class chips. OTOH though, if you 'tune' an executable or a compiler/runtime/whatever for the higher-end chips, the people who use the lower-end chips scream bloody murder.. I kind of look at it from the other angle - I think the people who have invested (the money, time and effort) to upgrade shouldn't have to default to the lowest common denominator, so maybe those people should be the ones /really/ screaming bloody murder <g> Anyhow, I thought maybe since D won't have all of the legacy code issues to deal with, it may be a good time to 'tune' GDC for the higher-end chips. - Dave
Oct 04 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Dave schrieb:
 Frankly and on second thought, I could be wrong to suggest this, because I'm
 basing that suggestion off of tests done with an older-than-current version
 of GCC and only on a PIII to compare it with.

Not necessarily. However, all the options are alredy there, so i think it just may be up to application author to decide.
 What I've noticed in the benchmarks I've run is that -mcpu=pentium4 does
 generally make some code a decent amount faster on both P4 and
 AthlonXP/AMD64 (32 bit mode) chips, while not really effecting the results
 on the PIII class chips.

Interesting. I had considered Athlon-XP to be rather similar to P6 (Pentium 3), and Pentium 4 somewhat different, but apparently i was wrong. Perhaps some optimizations caused some kind of performance "trap" on both recent AMDs and on Pentium 4, which weren't there in prior architectures. Gotta read something on it.
 OTOH though, if you 'tune' an executable or a compiler/runtime/whatever for
 the higher-end chips, the people who use the lower-end chips scream bloody
 murder.. I kind of look at it from the other angle - I think the people who
 have invested (the money, time and effort) to upgrade shouldn't have to
 default to the lowest common denominator, so maybe those people should be
 the ones /really/ screaming bloody murder <g>

It is only tuning... the command set in use is still as for 386, yes? I think it's a pity and Pentium (but perhaps nothing above) should be mandatory.
 Anyhow, I thought maybe since D won't have all of the legacy code issues to
 deal with, it may be a good time to 'tune' GDC for the higher-end chips.

Legacy *code* issues? There is no effect on code compatibility, the only consern is a compatible hardware. I would argue that D requieres an architecture with pretty much memory anyway, and computers old enough are more or less out of question already for that reason. -eye
Oct 04 2004
parent Dave <Dave_member pathlink.com> writes:
Ilya Minkov wrote:

 Dave schrieb:

 
 It is only tuning... the command set in use is still as for 386, yes? I
 think it's a pity and Pentium (but perhaps nothing above) should be
 mandatory.
 

Yea - it is only tuning, but nonetheless I didn't put enough thought into the original -mcpu=pentium4 suggestion. Especially given this response by the maintainer of GDC: D.gnu/791
 Anyhow, I thought maybe since D won't have all of the legacy code issues
 to deal with, it may be a good time to 'tune' GDC for the higher-end
 chips.

Legacy *code* issues? There is no effect on code compatibility, the only consern is a compatible hardware. I would argue that D requieres an architecture with pretty much memory anyway, and computers old enough are more or less out of question already for that reason. -eye

By "legacy code issues", I should have said something more along the lines of 'all that code running running on older hardware', which is what I intended. Thanks, - Dave
Oct 04 2004