www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GDC2 compilation warnings

reply bearophile <bearophileHUGS lycos.com> writes:
While compiling GDC2 today I have seen hundreds of warnings, usually one of 5
types:


../../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



In file included from ../../gcc/d/d-builtins.c:72:
../../gcc/d/d-bi-attrs-44.h: In function ‘handle_packed_attribute’:
../../gcc/d/d-bi-attrs-44.h:211: warning: unknown conversion type character ‘E’
in format
../../gcc/d/d-bi-attrs-44.h:211: warning: too many arguments for format



../../gcc/d/dmd2/builtin.c: In member function ‘BUILTIN
FuncDeclaration::isBuiltin()’:
../../gcc/d/dmd2/builtin.c:44: warning: unused variable ‘FeZe’
../../gcc/d/dmd2/builtin.c:45: warning: unused variable ‘FeZe2’



../../gcc/d/dmd2/toobj.c: In member function ‘virtual void
ClassDeclaration::toObjFile(int)’:
../../gcc/d/dmd2/toobj.c:691: warning: comparison between signed and unsigned
integer expressions
../../gcc/d/dmd2/toobj.c:693: warning: comparison between signed and unsigned
integer expressions



In file included from ../../gcc/d/dmd2/root.h:29,
                 from ../../gcc/d/dmd2/total.h:24,
                 from ../../gcc/d/d-cppmngl.cc:25:
../../gcc/d/dmd2/dchar.h:155: warning: unused parameter ‘pstart’


Comments:
- Unused variable warning: this is useful to avoid bugs;
- Type-punned pointer warning: so far I have never received an answer to my
questions about this possible problem in D.
- Printing functions wrong argument number warning: this is something D needs
to add, for writef, writefln, printf, sprintf, etc (even if it can't work in
all situations). Having those as run-time errors is silly in a language that
unlike dynamic languages forces you to compile the code. This is an example of
dynamic typing where I don't want it.
- Signed unsigned comparison warning: unless D invents some other very good
solution, this warning is a ugly but necessary patch over one hole of the C
language that D too has.

Bye,
bearophile
Nov 23 2010
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
 - Printing functions wrong argument number warning: this is something D needs
to


add, for writef, writefln, printf, sprintf, etc (even if it can't work in all
situations).

Can you make it work in some situations without breaking the others? If you
have a
compile time string passed in, it could check the argument count, but not all
strings are compile time. I use runtime concatenated strings to format() like
functions where additional data is requested on a branch.

I've actually wondered in the past if doing overloads based on if it is known at
compile time or not is possible. Any ideas?
Nov 23 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 Can you make it work in some situations without breaking the others? If you
have a
 compile time string passed in, it could check the argument count, but not all
 strings are compile time. I use runtime concatenated strings to format() like
 functions where additional data is requested on a branch.


Some format strings are known at compile time and others aren't. In most cases
my format strings are literals in place. GCC tests them if they are literals in
place, otherwise it ignores them. I think this is good enough. DMD may test
them at compile time if the format strings are known at compile time, they are
literals in place or enums or global/static const/immutable.



 I've actually wondered in the past if doing overloads based on if it is known
at
 compile time or not is possible. Any ideas?


The latest ideas regarding writeTo() will allow to use better formatted output
on user defined types. When arguments are user-defined ones the compile-time
test pass may just ignore them and just test if their count matches.

Bye,
bearophile
Nov 23 2010
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 While compiling GDC2 today I have seen hundreds of warnings, usually one of 5
types:


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.


 ../../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 file included from ../../gcc/d/d-builtins.c:72:
 ../../gcc/d/d-bi-attrs-44.h: In function ‘handle_packed_attribute’:
 ../../gcc/d/d-bi-attrs-44.h:211: warning: unknown conversion type character ‘E’


in format

 ../../gcc/d/d-bi-attrs-44.h:211: warning: too many arguments for format


I have (yet) no clue why this happens. It's a direct copy from c-common.c, which
doesn't exhibit this format error when compiled with the same C compiler and
flags.


 ../../gcc/d/dmd2/builtin.c: In member function ‘BUILTIN


FuncDeclaration::isBuiltin()’:

 ../../gcc/d/dmd2/builtin.c:44: warning: unused variable ‘FeZe’
 ../../gcc/d/dmd2/builtin.c:45: warning: unused variable ‘FeZe2’


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.


 ../../gcc/d/dmd2/toobj.c: In member function ‘virtual void


ClassDeclaration::toObjFile(int)’:

 ../../gcc/d/dmd2/toobj.c:691: warning: comparison between signed and unsigned


integer expressions

 ../../gcc/d/dmd2/toobj.c:693: warning: comparison between signed and unsigned


integer expressions

Meh. This is what you get when you compile DMD with:

WARNINGS=-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wcast-qual

I think it would be a good target to get the frontend compiling with the above
and
-Werror. :)



 In file included from ../../gcc/d/dmd2/root.h:29,
                  from ../../gcc/d/dmd2/total.h:24,
                  from ../../gcc/d/d-cppmngl.cc:25:
 ../../gcc/d/dmd2/dchar.h:155: warning: unused parameter ‘pstart’
 Comments:
 - Unused variable warning: this is useful to avoid bugs;
 - Type-punned pointer warning: so far I have never received an answer to my


questions about this possible problem in D.

 - Printing functions wrong argument number warning: this is something D needs
to


add, for writef, writefln, printf, sprintf, etc (even if it can't work in all
situations). Having those as run-time errors is silly in a language that unlike
dynamic languages forces you to compile the code. This is an example of dynamic
typing where I don't want it.

 - Signed unsigned comparison warning: unless D invents some other very good


solution, this warning is a ugly but necessary patch over one hole of the C
language that D too has.

 Bye,
 bearophile


I've always been in favour of more warnings for trivial things which can produce
undefined behaviour.
Nov 23 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Nov 23 2010
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 ------------------
 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.


Will add that to the dependencies later. If I were to build gdc on a new Debian
installation, the first packages I'd grab are:
g++-multilib, libgmp-dev, libmpfr-dev, patch

On 64bit platforms, this allows the build to make 32bit libraries for
installation
too.


 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.

If you compare GDC1 and GDC2, you'll see the same thing. The problem is likely
because Phobos2 is heavily templated in comparison to Phobos1, so you're pulling
in a lot more functions than you bargain for.



 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).

Not sure what you are talking about. I'll be sure to have a look at it later
though. :~)



 I don't like the need to write:
 gdc foo.d -o foo


There is a Perl script included - gdmd - script that essentially mimics this dmd
functionality.


 I appreciate that dmd just needs:
 dmd foo.d
 Or even:
 dmd foo
 (and "a.out" is bad).


File a bug against GCC then.



 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


man gdc


 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


version (GNU){}
Nov 24 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
If you compare GDC1 and GDC2, you'll see the same thing. The problem is likely
because Phobos2 is heavily templated in comparison to Phobos1, so you're
pulling in a lot more functions than you bargain for.<


That little path tracer uses mostly the C std lib (or just it). And DMD2
produces a twice smaller program (unstripped), so I think the problem is
elsewhere.



Not sure what you are talking about. I'll be sure to have a look at it later
though. :~)<


Recently I have shown here a benchmark for D/C++ templates, that computes the
number a well known problem (N queens problem):
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=122677



There is a Perl script included - gdmd - script that essentially mimics this
dmd functionality.<


I see.



File a bug against GCC then.<


I don't think they will change GCC about this. If this usability problem is to
be solved, then it needs to be solved by GDC (or by the gdmd script that
probably doesn't have this problem).



 man gdc


OK.



 version (GNU){}


I see. I think it has to be present in this page too:
http://www.digitalmars.com/d/2.0/version.html


Is someone able to tell me if RAND_MAX is hard-coded in Phobos?

Bye,
bearophile
Nov 24 2010
next sibling parent reply Graham Fawcett <fawcett uwindsor.ca> writes:
On Wed, 24 Nov 2010 12:45:52 -0500, bearophile wrote:


If you compare GDC1 and GDC2, you'll see the same thing. The problem is
likely because Phobos2 is heavily templated in comparison to Phobos1, so
you're pulling in a lot more functions than you bargain for.<


 
 That little path tracer uses mostly the C std lib (or just it). And DMD2
 produces a twice smaller program (unstripped), so I think the problem is
 elsewhere.
 
 

Not sure what you are talking about. I'll be sure to have a look at it
later though. :~)<


 
 Recently I have shown here a benchmark for D/C++ templates, that
 computes the number a well known problem (N queens problem):
 http://www.digitalmars.com/webnews/newsgroups.php?


art_group=digitalmars.D&article_id=122677

 
 

There is a Perl script included - gdmd - script that essentially mimics
this dmd functionality.<


 
 I see.
 
 

File a bug against GCC then.<


 
 I don't think they will change GCC about this. If this usability problem
 is to be solved, then it needs to be solved by GDC (or by the gdmd
 script that probably doesn't have this problem).
 
 

 man gdc


 
 OK.
 
 

 version (GNU){}


 
 I see. I think it has to be present in this page too:
 http://www.digitalmars.com/d/2.0/version.html
 
 
 Is someone able to tell me if RAND_MAX is hard-coded in Phobos?


$ find /usr/include/d/dmd/ | xargs grep "RAND_MAX.*="
/usr/include/d/dmd/druntime/import/core/stdc/stdlib.di:    enum RAND_MAX 
= 32767;
/usr/include/d/dmd/druntime/import/core/stdc/stdlib.d:enum RAND_MAX     = 
32767;
Nov 24 2010
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Graham Fawcett (fawcett uwindsor.ca)'s article

 $ find /usr/include/d/dmd/ | xargs grep "RAND_MAX.*="
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.di:    enum RAND_MAX
 = 32767;
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.d:enum RAND_MAX     =
 32767;


Why the ugly pipe to xargs?

grep -R "RAND_MAX.*=" /usr/include/d/dmd
Nov 24 2010
parent reply Graham Fawcett <fawcett uwindsor.ca> writes:
On Wed, 24 Nov 2010 18:49:23 +0000, Iain Buclaw wrote:


 == Quote from Graham Fawcett (fawcett uwindsor.ca)'s article

 $ find /usr/include/d/dmd/ | xargs grep "RAND_MAX.*="
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.di:    enum
 RAND_MAX = 32767;
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.d:enum RAND_MAX    
 = 32767;


 
 Why the ugly pipe to xargs?
 
 grep -R "RAND_MAX.*=" /usr/include/d/dmd


I knew someone was going to call me on that. :)

I spend some time on Linux, and some on Solaris. While Solaris has
"ggrep" which supports -R, the Solaris "grep" does not. By force of
habit, I spell it "find/grep" to make scripts more portable.

But it's a kludge. Kids, don't try this at home, "grep -R" is
definitely your friend. :)

I hear that "ack" is also nice, though I don't know if it supports D 
sources out of the box. (ack: http://betterthangrep.com/)

Best,
Graham
Nov 24 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/24/10 12:56 PM, Graham Fawcett wrote:

 On Wed, 24 Nov 2010 18:49:23 +0000, Iain Buclaw wrote:


 == Quote from Graham Fawcett (fawcett uwindsor.ca)'s article

 $ find /usr/include/d/dmd/ | xargs grep "RAND_MAX.*="
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.di:    enum
 RAND_MAX = 32767;
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.d:enum RAND_MAX
 = 32767;


 Why the ugly pipe to xargs?

 grep -R "RAND_MAX.*=" /usr/include/d/dmd


 I knew someone was going to call me on that. :)

 I spend some time on Linux, and some on Solaris. While Solaris has
 "ggrep" which supports -R, the Solaris "grep" does not. By force of
 habit, I spell it "find/grep" to make scripts more portable.

 But it's a kludge. Kids, don't try this at home, "grep -R" is
 definitely your friend. :)

 I hear that "ack" is also nice, though I don't know if it supports D
 sources out of the box. (ack: http://betterthangrep.com/)

 Best,
 Graham


You guys should use zsh.

grep "RAND_MAX.*=" /usr/include/d/dmd/**/*


Andrei
Nov 24 2010
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 On 11/24/10 12:56 PM, Graham Fawcett wrote:

 On Wed, 24 Nov 2010 18:49:23 +0000, Iain Buclaw wrote:


 == Quote from Graham Fawcett (fawcett uwindsor.ca)'s article

 $ find /usr/include/d/dmd/ | xargs grep "RAND_MAX.*="
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.di:    enum
 RAND_MAX = 32767;
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.d:enum RAND_MAX
 = 32767;


 Why the ugly pipe to xargs?

 grep -R "RAND_MAX.*=" /usr/include/d/dmd


 I knew someone was going to call me on that. :)

 I spend some time on Linux, and some on Solaris. While Solaris has
 "ggrep" which supports -R, the Solaris "grep" does not. By force of
 habit, I spell it "find/grep" to make scripts more portable.

 But it's a kludge. Kids, don't try this at home, "grep -R" is
 definitely your friend. :)

 I hear that "ack" is also nice, though I don't know if it supports D
 sources out of the box. (ack: http://betterthangrep.com/)

 Best,
 Graham


 You guys should use csh.


There, fixed that for you. :~)

Iain
Nov 24 2010
prev sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Andrei Alexandrescu, el 24 de noviembre a las 13:09 me escribiste:

 On 11/24/10 12:56 PM, Graham Fawcett wrote:

On Wed, 24 Nov 2010 18:49:23 +0000, Iain Buclaw wrote:


== Quote from Graham Fawcett (fawcett uwindsor.ca)'s article

$ find /usr/include/d/dmd/ | xargs grep "RAND_MAX.*="
/usr/include/d/dmd/druntime/import/core/stdc/stdlib.di:    enum
RAND_MAX = 32767;
/usr/include/d/dmd/druntime/import/core/stdc/stdlib.d:enum RAND_MAX
= 32767;


Why the ugly pipe to xargs?

grep -R "RAND_MAX.*=" /usr/include/d/dmd


I knew someone was going to call me on that. :)

I spend some time on Linux, and some on Solaris. While Solaris has
"ggrep" which supports -R, the Solaris "grep" does not. By force of
habit, I spell it "find/grep" to make scripts more portable.

But it's a kludge. Kids, don't try this at home, "grep -R" is
definitely your friend. :)

I hear that "ack" is also nice, though I don't know if it supports D
sources out of the box. (ack: http://betterthangrep.com/)

Best,
Graham


 
 You guys should use zsh.
 
 grep "RAND_MAX.*=" /usr/include/d/dmd/**/*


Bash (4) does that too :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Vaporeso, al verse enfundado por la depresión, decide dar fin a su vida
tomando Chinato Garda mezclado con kerosene al 50%. Ante el duro trance
pierde la movilidad en sus miembros derechos: inferior y superior. En
ese momento es considerado como el hombre líder del movimiento de
izquierda de Occidente.
Nov 24 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Graham Fawcett:


 $ find /usr/include/d/dmd/ | xargs grep "RAND_MAX.*="
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.di:    enum RAND_MAX 
 = 32767;
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.d:enum RAND_MAX     = 
 32767;


Sorry for not looking at it by myself.
I have filed it:
http://d.puremagic.com/issues/show_bug.cgi?id=5271

Bye,
bearophile
Nov 24 2010
parent Graham Fawcett <fawcett uwindsor.ca> writes:
On Wed, 24 Nov 2010 14:45:02 -0500, bearophile wrote:


 Graham Fawcett:
 

 $ find /usr/include/d/dmd/ | xargs grep "RAND_MAX.*="
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.di:    enum
 RAND_MAX = 32767;
 /usr/include/d/dmd/druntime/import/core/stdc/stdlib.d:enum RAND_MAX    
 = 32767;


 
 Sorry for not looking at it by myself. 


No worries, it gave me an opportunity to display my bad shell habits in 
public. :)

Cheers,
Graham


 I have filed it:
 http://d.puremagic.com/issues/show_bug.cgi?id=5271
 
 Bye,
 bearophile
Nov 24 2010
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

If you compare GDC1 and GDC2, you'll see the same thing. The problem is likely




because Phobos2 is heavily templated in comparison to Phobos1, so you're pulling
in a lot more functions than you bargain for.<

 That little path tracer uses mostly the C std lib (or just it). And DMD2


produces a twice smaller program (unstripped), so I think the problem is
elsewhere.

Oh, just remembered. Stripping the installed libraries helps just a wee bit:

Really bad example to prove :)
---
import std.stdio;

void main()
{
    writeln("Hello World");
}

Output program size on my system:
DMD - with debugged libphobos2.a: 2.5M (unstripped)
DMD - with stripped libphobos2.a: 532K (unstripped)
DMD - with stripped libphobos2.a: 296K (stripped)
GDC - with debugged libgphobos2.a: 1.9M* (unstripped)
GDC - with stripped libgphobos2.a: 688K* (unstripped)
GDC - with stripped libgphobos2.a: 424K* (stripped)

*Includes debugged/stripped libgdruntime.a too.

The extra few hundred kilobytes I can imagine being because of linking in
libgcc_s.a, which is used for the DWARF exception handling routines. If someone
finds this may not be the case, I'd like to hear of your replies.




File a bug against GCC then.<


 I don't think they will change GCC about this.


Then I won't change GCC about this either.


Regards
Iain
Nov 24 2010
prev sibling parent reply Smurfette <smürf vill.age> writes:
bearophile Wrote:


 ../../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.


I'm sure that after so many years (30+) of professional experience with
C/C++/D/Java compilers, Walter knows much much better than you or GCC when this
optimization can be done in unsafe manner. It's an error in the compiler
heuristics.


 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.


They're not really unused. The GDC team probably made the mistakes.


 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.


Yes, it's amazing they managed to make it work. Worth a few beers.


 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.


This must be an error in your test. You see, D is very suitable for kernel
development. The executable for the N queens problem or a raytracer is actually
smaller than 2 kB. How otherwise you program a kernel for an embedded platform
with 16 kB of ROM? "458_052 bytes stripped, and over 2 MB unstripped" is this
loser talk Walter is talking about.
Nov 24 2010
parent Leandro Lucarella <luca llucax.com.ar> writes:
Smurfette, el 24 de noviembre a las 11:30 me escribiste:

 bearophile Wrote:
 

 ../../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.


 
 I'm sure that after so many years (30+) of professional experience
 with C/C++/D/Java compilers, Walter knows much much better than you or
 GCC when this optimization can be done in unsafe manner. It's an error
 in the compiler heuristics.


No, it isn't. There are no "heuristics" in there. Type punning became
a "problem" in the GCC world just recently, because the compiler started
doing some optimizations assuming strict-aliasing rules. And strict
aliasing rules are specified in C99, so if the code is written for older
standards (or for C++98 like in this case, which I think it doesn't say
anything about strict-aliasing rules), is completely valid to use
type-punned pointers.

So, there are 2 possible paths, tell GCC not to be so harsh on non-C99
code and avoid using optimizations that assume no type-punned pointers
are dereferenced, or "fix" (quoted because is not really *broken*,
strictly speaking) the code so GCC can optimize it a little better.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Se ha dicho tanto que las apariencias engañan
Por supuesto que engañarán a quien sea tan vulgar como para creerlo
Nov 24 2010
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Iain Buclaw, el 24 de noviembre a las 01:29 me escribiste:

 == Quote from bearophile (bearophileHUGS lycos.com)'s article

 While compiling GDC2 today I have seen hundreds of warnings, usually one of 5
types:


 
 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.
 

 ../../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 file included from ../../gcc/d/dmd2/root.h:29,
                  from ../../gcc/d/dmd2/total.h:24,
                  from ../../gcc/d/d-cppmngl.cc:25:
 ../../gcc/d/dmd2/dchar.h:155: warning: unused parameter ?pstart?
 Comments:
 - Unused variable warning: this is useful to avoid bugs;
 - Type-punned pointer warning: so far I have never received an answer to my


 questions about this possible problem in D.


These are important issues. This can heavily break the code when
compiling with optimizations (-O2, -O3, -Os). Basically, you can't
access an object with a type using a pointer to an incompatible type
(except through an union). If is too hard to fix, use
-fno-strict-aliasing when compiling with -O2, -O3 or -Os to inhibit that
optimization.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hey you, don't tell me there's no hope at all
Together we stand, divided we fall.
Nov 24 2010
next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Leandro Lucarella, el 24 de noviembre a las 10:46 me escribiste:

 Iain Buclaw, el 24 de noviembre a las 01:29 me escribiste:

 == Quote from bearophile (bearophileHUGS lycos.com)'s article

 While compiling GDC2 today I have seen hundreds of warnings, usually one of 5
types:


 
 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.
 

 ../../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 file included from ../../gcc/d/dmd2/root.h:29,
                  from ../../gcc/d/dmd2/total.h:24,
                  from ../../gcc/d/d-cppmngl.cc:25:
 ../../gcc/d/dmd2/dchar.h:155: warning: unused parameter ?pstart?
 Comments:
 - Unused variable warning: this is useful to avoid bugs;
 - Type-punned pointer warning: so far I have never received an answer to my


 questions about this possible problem in D.


 
 These are important issues. This can heavily break the code when
 compiling with optimizations (-O2, -O3, -Os). Basically, you can't
 access an object with a type using a pointer to an incompatible type
 (except through an union). If is too hard to fix, use
 -fno-strict-aliasing when compiling with -O2, -O3 or -Os to inhibit that
 optimization.


I forgot the useful link:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fstrict_002daliasing-818

:)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
En la calle me crucé con un señor muy correcto, que habitualmente anda en
Falcon; iba corriendo con dos valijas en la mano y dijo: "Voy para Miami,
tiene algún mensaje o ..." y le dije: "No, no, no..."
	-- Extra Tato (1983, Triunfo de Alfonsín)
Nov 24 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:


 These are important issues. This can heavily break the code when
 compiling with optimizations (-O2, -O3, -Os). Basically, you can't
 access an object with a type using a pointer to an incompatible type


I agree.



 (except through an union).


I am not sure the C standard says something about this. I think this is more
like a convention for C compilers.

Bye,
bearophile
Nov 24 2010
parent Leandro Lucarella <luca llucax.com.ar> writes:
bearophile, el 24 de noviembre a las 12:37 me escribiste:

 Leandro Lucarella:
 

 These are important issues. This can heavily break the code when
 compiling with optimizations (-O2, -O3, -Os). Basically, you can't
 access an object with a type using a pointer to an incompatible type


 
 I agree.
 
 

 (except through an union).


 
 I am not sure the C standard says something about this. I think this
 is more like a convention for C compilers.


According to Wikipedia, C99 does[1], I don't think C++98 say anything
about it though, and DMD FE is written in C++, so strictly speaking,
I don't think is a *bug* in the FE per se, but I think is not a bad idea
to avoid dereferencing type-punned pointers to help GCC produce better
programs if possible :)

[1] http://en.wikipedia.org/wiki/Aliasing_%28computing%29#Conflicts_with_optimization

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
O.K.
Just a little pinprick.
There'll be no more aaaaaaaaah!
But you may feel a little sick.
Nov 24 2010
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 - Signed unsigned comparison warning: unless D invents some other very good
solution, this warning is a ugly but necessary patch over one hole of the C
language that D too has.


This is bug 259, one of the first issues ever reported in bugzilla.
Can you please stop reporting obvious issues as if you were the first 
person who ever noticed them?

Note that the spec has always said that the compiler generates a 
warning. It's just a bug that it doesn't at present.
Note also that range propagation for integer types should fix this in 
the most common cases, so warnings will be much less frequent than in C. 
At present, the implementation of range propagation is very incomplete.
Nov 24 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Don:


 This is bug 259, one of the first issues ever reported in bugzilla.
 Can you please stop reporting obvious issues as if you were the first 
 person who ever noticed them?


In this very newsgroup I have learnt that sometimes saying obvious things is
useful.



 It's just a bug that it doesn't at present.


I don't believe this. I think it's more probably not desired.

Bye,
bearophile
Nov 24 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
bearophile:


 Don:

 It's just a bug that it doesn't at present.


 
 I don't believe this. I think it's more probably not desired.


Seeing the spring cleaning that the good Andrei is doing in Bugzilla, and how
he has assigned bug 259, I have to say that you are right, as usual :-)

Sorry,
bearophile
Nov 26 2010