Given that the gcc documentation (https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc.pdf) specifies that -O1 is -O0 plus a specific list of options, why is it when I time compiling my code with -O1 it takes 2 times longer to compile than using -O0 + all the options listed as being enabled when -O1 is turned on? Are there other options that are being enabled that are not specified in the documentation (my suspicion), or is there something else, more sinister, happening in the background?
If the documentation is just out of date, that would be something I'd be interested in knowing about, if only to better understand the optimization options available for GCC and my code.
If the documentation is just out of date ...
It is a fair assumption that the documentation is inaccurate. Stuff like that happens.
Another possibility is that you have misread the documentation. My reading of the document you linked to (page 111) is that -O and -O1 are supposed to mean the same thing. If that is correct, then what you are apparently trying to do doesn't make much sense.
I suggest that you look at the GCC source code to figure out exactly how -O1 is implemented. That should tell you whether the behavior you are seeing can be explained by inaccurate documentation1, or whether there is something else going on here.
1 - If the problem is inaccurate documentation, you can help the GCC folks and ultimately other GCC users by submitting a bug report with corrections.
Related
I've found Clang's documentation to be quite poor. I haven't been able to find much of a list of available Clang warning flags. I'm interested particularly in C/C++ warnings, but this is a bit of a general issue.
GCC lists and describes warnings here, and also lists what is included in -Wall and -Wextra:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options
What warning flags are included with Clang's -Wall and -Wextra?
I can scour the Clang release notes for each version to see what new warning flags are introduced each time (e.g. http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html), but is there an easier list and/or description of Clang's warnings? This would be extremely useful. I need to know what is included in -Wall and what is not, so I can consider turning on those that are not.
(I know that -Weverything exists for Clang - might I have to resort to using that and just explicitly disabling the ones I don't like? More documentation would make this much more ideal.)
You can check the source code:
For example,
def : DiagGroup<"all", [Most, Parentheses, Switch]>;
// Warnings enabled by -pedantic. This is magically filled in by TableGen.
def Pedantic : DiagGroup<"pedantic">;
// Aliases.
def : DiagGroup<"", [Extra]>; // -W = -Wextra
For -Wall look at the Most, Parentheses, Switch. You can find:
def Most : DiagGroup<"most", [
....
further down the file. Similarly, for extra:
def Extra : DiagGroup<"extra", [
MissingFieldInitializers,
IgnoredQualifiers,
InitializerOverrides,
SemiBeforeMethodBody,
MissingMethodReturnType,
SignCompare,
UnusedParameter
]>;
Clang used to be very bad at documenting what was available.
Though from release 4.0.0 on, they have fixed it. For older releases one can try or consult the source code. At the compiler-warnings page on Github you can find an extract of the warnings based upon the source code.
So you can find the documentation over the latest flags at the documentation pages, as well as the matching documentation for a specific release at their release pages (4.0.0).
Clang-cl has its own warning flags, of which the mapping can be found on its documentation
Is it possible to 'tell' compiler that if total number of warnings (while compiling a C++ program) are more than say 10 then stop compiling further, and emit an error?
Or is it possible to hack a compiler like clang to provide this functionality.
GCC has two options together would achieve this, from gnu online docs:
-Werror
Make all warnings into errors.
-fmax-errors=n
Limits the maximum number of error messages to n, at which point GCC bails out rather than attempting to continue processing the source
code.
This would make a build with any warnings fail though, the options just define when to stop parsing.
I haven't seen this kind of feature in gcc or clang. You can certainly try to patch it into either of them, both are open source. There is also -Werror (accepted by both compilers) which simply treats warnings as errors.
How about using -Werror to make warnings into errors and -fmax-errors=n to set the limit.
(Also, perhaps making your code completely warning free would be a good thing).
I am reading:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
It first suggests:
In combination with -flto using this option (-fwhole-program) should not be used. Instead relying on a linker plugin should provide safer and more precise information.
And then, it suggests:
If the program does not require any symbols to be exported, it is possible to combine -flto and -fwhole-program to allow the interprocedural optimizers to use more aggressive assumptions which may lead to improved optimization opportunities. Use of -fwhole-program is not needed when linker plugin is active (see -fuse-linker-plugin).
Does it mean that in theory, using -fuse-linker-plugin with -flto always gets a better optimized executable than using -fwhole-program with -flto?
I tried to use ld to link with -fuse-linker-plugin and -fwhole-program separately, and the executables' sizes at least are different.
P.S. I am using gcc 4.6.2, and ld 2.21.53.0.1 on CentOS 6.
UPDATE: See #PeterCordes comment below. Essentially, -fuse-linker-plugin is no longer necessary.
These differences are subtle. First, understand what -flto actually does. It essentially creates an output that can be optimized later (at "link-time").
What -fwhole-program does is assumes "that the current compilation unit represents the whole program being compiled" whether or not that is actually the case. Therefore, GCC will assume that it knows all of the places that call a particular function. As it says, it might use more aggressive inter-procedural optimizers. I'll explain that in a bit.
Lastly, what -fuse-linker-plugin does is actually perform the optimizations at link time that would normally be done as each compilation unit is performed. So, this one is designed to pair with -flto because -flto means save enough information to do optimizations later and -fuse-linker-plugin means actually do those optimizations.
So, where do they differ? Well, as GCC doc suggests, there is no advantage in principle of using -fwhole-program because that option assumes something that you then have to ensure is true. To break it, simply define a function in one .cpp file and use it in another. You will get a linker error.
Is there any advantage to -fwhole-program? Well, if you only have one compilation unit then you can use it, but honestly, it won't be any better. I was able to get different sized executables by using equivalent programs, but when checking the actual generated machine code, they were identical. In fact, the only differences that I saw were that line numbers with debugging information were different.
I want to find out what code causes slow compilation times in gcc. I previously had a code being compiled slowly and someone told me the command-line switch that makes gcc to print each step that it compiles, including each function/variable/symbol and so on. That helped a lot (I could literally see in console where gcc chokes), but I forgot what was the switch.
I found it (from the gcc man page):
-Q
Makes the compiler print out each function name as it is compiled, and print some statistics about each pass when it finishes.
See also this answer to a quite similar question.
You very probably want to invoke GCC with -time or more probably -ftime-report which gives you the time spent by cc1 or cc1plus ... (the compiler proper started by the gcc or g++command) which shows the time spent in each internal phases or passes of the GCC compiler. Don't forget also optimizations, debugging, and warnings flags (e.g. -Wall -O -g); they all slow down the compilation.
You'll learn that for C programs, parsing is a small fraction of the compilation time, as soon as you ask for some optimization, e.g. -O1 or -O2. (This is less true for C++, when parsing can take half of the time, notably since template expansion is considered as parsing).
Empirically, what slows down GCC are very long function bodies. Better have 50 functions of 1000 lines each than one single function of 50000 lines (and this could happen in programs generating some of their C++ code, e.g. RefPerSys or perhaps -in spring 2021- Bismon).
Try the -v (verbose) compilation.
See this link:
http://www.network-theory.co.uk/docs/gccintro/gccintro_75.html
edit:
I understand. Maybe this will help:
gcc -fdump-tree-all -fdump-rtl-all
and the like (-fdump-passes). See here: http://fizz.phys.dal.ca/~jordan/gcc-4.0.1/gcc/Debugging-Options.html
Is there a way to find out what gcc flags a particular binary was compiled with?
A quick look at the GCC documentation doesn't turn anything up.
The Boost guys are some of the smartest C++ developers out there, and they resort to naming conventions because this is generally not possible any other way (the executable could have been created in any number of languages, by any number of compiler versions, after all).
(Added much later): Turns out GCC has this feature in 4.3 if asked for when you compile the code:
A new command-line switch -frecord-gcc-switches ... causes the command line that was used to invoke the compiler to be recorded into the object file that is being created. The exact format of this recording is target and binary file format dependent, but it usually takes the form of a note section containing ASCII text.
Experimental proof:
diciu$ gcc -O2 /tmp/tt.c -o /tmp/a.out.o2
diciu$ gcc -O3 /tmp/tt.c -o /tmp/a.out.o3
diciu$ diff /tmp/a.out.o3 /tmp/a.out.o2
diciu$
I take that as a no as the binaries are identical.
I'm the one who asked Brian to post this originally. My question had to do with the samba binary. I found out that you can run smb -b to get information on how it was built.
I don't think so.
You can see if it has debug symbols, which means -g was used ;) But I can't think of any way how you could find out which directories have been used to search for include headers for example.
Maybe a better answer is possible if you only target for a specific flag; e.g. if you only want to know if the flag "..." was set when this binary was compiled or not. In that case, what flag would this be?