Re:The most useful GCC options and extensions
by tedunangst on Monday July 11, 2011 @02:23PM
(#2751847)
I was definitely not expecting an article about useful GCC options to mention -trigraphs. The -ansi option isn't particularly useful either, imo, since just about every interesting program is going to do something crazy like open a network socket or list the files in a directory.
By far the most useful gcc extension wasn't mentioned at all. typeof().
Re:The most useful GCC options and extensions
by antoarts on Monday July 11, 2011 @02:30PM
(#2751871)
I mentioned trigraphs as an example of a C standard feature disabled by default in GCC, and then I just mentioned how to enable just that feature. It wasn't supposed to be included among the most important options, it just got there ;-).
Re:The most useful GCC options and extensions
by pdovy on Tuesday July 12, 2011 @08:36AM
(#2754486)
Has anybody used the __builtin_expect feature to good effect? We had been using this extensively in our codebase in places where there is an obvious common "fast path".
I tried an experiment where I did a comparison of the __builtin_expect version against a version with our likely/unlikely macros defined to the identity, and I actually saw no difference, which was disappointing. When I did some digging I found this blog post: http://bitsup.blogspot.com/2008/04/measuring-performance-of-... which suggests the same result for the Linux kernel.
FWIW GCC also has a reasonable set of PGO options (not mentioned in this article), and those actually can (anecdotally) make a noticeable difference, although you're subject to the overtraining problem if you're not careful.
Re:The most useful GCC options and extensions
by matthavener on Monday July 11, 2011 @02:17PM
(#2751825)
A few others I use are -Wsign-compare and -Wformat-nonliteral. Sign compare warns on possible bugs/vulnerabilities due to comparing signed and unsigned values. Using nonliteral formats can lead to vulnerabilities (such as the famous attacks on FTP servers http://seclists.org/bugtraq/1999/Sep/328)
Re:The most useful GCC options and extensions
by 1amzave on Monday July 11, 2011 @07:42PM
(#2752942)
You must be a C++ user -- I (a C guy) immediately thought "what? No, that's in -Wextra, not -Wall", checked the man page to confirm, and sure enough, it differs (-Wall includes sign-compare when compiling C++, but not C).
Re:The most useful GCC options and extensions
by afhof on Monday July 11, 2011 @02:57PM
(#2751993)
Sometimes when compiling and trying to use system calls gcc will complain about the functions not existing. This is usually because of some preprocessor guard not being defined. An easy way to see what macros have been defined is to run gcc with the "-E -dM" flags.
Re:The most useful GCC options and extensions
by DarkShikari on Monday July 11, 2011 @07:56PM
(#2752973)
My favorite would be "pure" -- it's perfect for saying "this function pointer, which calls an assembly function, doesn't muck with any of your data structures, so you don't have to reload every single pointer after it returns".
But unfortunately, since it was basically written only for libc purposes, it doesn't work on function pointers, so it's useless for this purpose.
Nice ;-)
By far the most useful gcc extension wasn't mentioned at all. typeof().
I tried an experiment where I did a comparison of the __builtin_expect version against a version with our likely/unlikely macros defined to the identity, and I actually saw no difference, which was disappointing. When I did some digging I found this blog post: http://bitsup.blogspot.com/2008/04/measuring-performance-of-... which suggests the same result for the Linux kernel.
FWIW GCC also has a reasonable set of PGO options (not mentioned in this article), and those actually can (anecdotally) make a noticeable difference, although you're subject to the overtraining problem if you're not careful.
#define max(a,b) ({ typeof (a) _a = (a); typeof (b) _b = (b); _a > _b ? _a : _b; })
Makes separate compilation for languages that compile to C much easier.
But unfortunately, since it was basically written only for libc purposes, it doesn't work on function pointers, so it's useless for this purpose.
"All warnings can be enabled with -w."
man g++ says:
"-w Inhibit all warning messages."
Inhibit means to prevent (not to enable).