gcc flags for developers

[Lubos Lunak]

Dne pá 9. prosince 2005 13:08 David Faure napsal(a):
> On Friday 09 December 2005 12:10, Dirk Mueller wrote:
> > - Also, full is a VERY bad option, as it disables important WARNINGS.

 Care to elaborate slightly more on this? After checking the gcc manpage, the 
only thing I could find was -Wuninitialized, so I guess the manpage is 
missing all those important WARNINGS. Not that -Wuninitialized would be that 
bad, it can certainly find some problems, but the description is also rather 
clear on the fact that it cannot catch many of them, so Valgrind may be in 
order in many cases anyway, and this warning alone doesn't look to me like 
the reason to enable optimizations by default.

> To update my proposal:
> --enable-debug              would now set -O2 -g -fno-reorder-blocks
> -fno-schedule-insns -fno-inline
> --enable-debug=full      would still set -O0 -g3 for the worse case of a
> hard-to-debug problem (e.g. macros etc.), 
>
> In addition we could have
> --enable-debug=noopt for -O1 -g
> for faster compilation if anyone wants it, but nowadays with icecream I
> wait for ld/libtool much more than I wait for gcc so I guess -O2 is fine.

 I do too. At work. But at home I have only one computer and thus no icecream. 
And while I probably could buy a couple more just for the fun of it if I saw 
the point in it, which I don't, I think there are many people who just can't 
and are stuck with whatever they have. I still remember the times when my own 
computer was so slow for development that I ssh-ed to a faster university 
machine and did almost all KDE development remotely (boy, that sucked, even 
though I didn't do that much development at that time). I'm quite sure I 
tried to reduce the compile times in any possible way including trying 
--disable-debug --disable-warnings.

 I just randomly tried to compile kparts/part.cpp and 
kio/kfile/kfiledialog.cpp and adding -O1 increases the compile time by 15% 
and 30% respectively for these two cases. Now, please remind me, how much 
time is saved by using the old crappy gcc-2.95 compared to something more 
recent? And how many people stayed with it anyway (and still do AFAIK)? I 
don't doubt that if we include -O1 in the flags some people instead of 
gaining one[*] more warning will instead go for --disable-debug and loose 
them all. I've seen already many times code that made gcc spew warnings like 
if the respective developer had never heard of them at all and I don't think 
we should try to increase the number of such people in any way.

 I'd also like to point out that I simply consider it to be a gcc lameness 
that -Wuninitialized can't work without -O. It should simply turn on only the 
needed flow analysis (there's even no separate switch for that) and not 
require full -O.

 Also, WRT debugging not being affected by the change, let me quote a part 
from the manpage talking about -g :
===
The shortcuts taken by optimized code may occasionally produce surprising 
results: some variables you declared may not exist at all; flow of control 
may briefly move where you did not expect it; some statements may not be 
executed because they compute constant results or their values were already 
at hand; some statements may execute in different places because they were 
moved out of loops.
===
I don't think just -O2 -g -fno-reorder-blocks -fno-schedule-insns -fno-inline 
will prevent this. E.g. some of this seems to be turned on by -floop-optimize 
which is already included in -O1. Moreover, "some variables you declared may 
not exist at all" does not only affect debugging itself but also backtraces 
and I failed to find the option to turn this off with -O.

 IMHO not really worth -Wuninitialized. If that's the only thing that'd need 
-O, it might be simpler if somebody does daily builds with -O -Wuninitialized 
and makes the logs available.

 That said, I'm not ultimately against, it's just that I currently don't find 
it worth it. Since Dirk is one of the people here who knows the most about 
gcc, maybe he could just better explain the reasoning for the change.

[*] Or more, if Dirk can list them.

-- 
 Lubos Lunak
 KDE Developer
 l.lunak at kde.org     l.lunak at suse.cz