GDC2 [Re: GDC2 compilation warnings]

[bearophile]

Iain Buclaw:

> I'm rather thankful that you didn't try compiling a month or two ago then. :~)
> I've cut down the amount of warnings emitted by a *lot*, and I can't even begin to
> stress that fact.

Thank you for your work, then :-)


> > ../../gcc/d/d-gcc-real.h: In member function ‘const real_value& real_t::rv() const’:
> > ../../gcc/d/d-gcc-real.h:54: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> 
> If you have a great idea to fix this warning, please send a patch.

In GCC there is a switch that disables strict aliasing optimization. I think if you use it the compiler gets a bit slower, but you will also avoid bugs caused by this optimization, and maybe the warnings too. Otherwise there are other ways to solve it, maybe using an union to perform the pointer cast.


> We don't use that function for anything at the moment. Though I think the idea may
> have been to make GCC builtins known to the Frontend parser.

That's just an example. There are tens of other cases of unused variables spread here and there.

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

I have done some tests on the 32 bit gdc D2, compiled today on Ubuntu. Some comments:

The compilation and the compiler works! This is great considering that it's a card castle about 2 lighyears high that uses no glue.


To compile it I have had to use, this, suggested by bernardh on IRC:
sudo apt-get install libgmp3-dev
sudo apt-get install libmpfr-dev
You may add that to the compilation recipe. Several alternatives have failed.


I have used gcc-4.4.5 as suggested. I have tried to use gcc-4.4.5.tar.bz2, but it has failed, hundreds of undefined symbols. I have then used gcc-core-4.4.5.tar.bz2 and it was OK.


Using the latest LDC 1, the stripped binary of a little raytracer-like program that mostly uses the C standard library is about 174_960 bytes, similar code compiled with GDC2 is 458_052 bytes stripped, and over 2 MB unstripped, this is not good.


The compilation of templates (the Nqueens program I've shown recently) was dead-slow and I was unable to compile the program for N higher than 5 (DMD works up to 6 or 7, I think, G++ reaches higher values).


The std.c.stdlib.RAND_MAX value is wrong. It's short.max, but it needs to be int.max. I have seen this problem other times in Tango and LDC1. Maybe this is a problem of Phobos itself, that maybe uses a hardcoded value. So if some of you confirms this, then I will file a bug report for Phobos.


Performance for FP-heavy code is not so good :-( It's faster than DMD, but for the raytracer-like program it's almost two times slower than LDC1-compiled code. I will need more benchmarks and asm-reading to confirm this and to understand why.


I don't like the need to write:
gdc foo.d -o foo
I appreciate that dmd just needs:
dmd foo.d
Or even:
dmd foo
(and "a.out" is bad).


This page doesn't list the command line arguments of GDC:
http://bitbucket.org/goshawk/gdc/wiki/Home
I have had to find them here, but I am not sure they are correct still:
http://dgcc.sourceforge.net/gdc/manual.html
And I don't know/remember the version identifier for GDC, I think this page doesn't list it:
http://www.digitalmars.com/d/2.0/version.html

Bye,
bearophile