Useful GCC flags for C

Question

Beyond setting -Wall, and setting -std=XXX, what other really useful, but less known compiler flags are there for use in C?

I'm particularly interested in any additional warnings, and/or and turning warnings into errors in some cases to absolutely minimize any accidental type mismatches.

Answer 1

man gcc

The manual is full of interesting flags with good descriptions. However, -Wall will probably make gcc as verbose as possible. If you want more interesting data, you should take a look at valgrind or some other tool for checking for errors.

Answer 2

There is -Werror, which treats all warnings as errors and stops the compilation. The gcc manual page explains every command line switch for your compiler.

Answer 3

I'm particularly interested in any additional warnings,

In addition to -Wall, the -W or -Wextra option (-W works with older versions of gcc as well as newer ones; more recent versions support the alternative name -Wextra, which means the same thing, but is more descriptive) enables various additional warnings.

There are also even more warnings which are not enabled by either of those, generally for things that are more questionably bad. The set of available options is dependent on which gcc version you are using - consult man gcc or info gcc for details, or see the online documentation for the particular gcc version you're interested in. And -pedantic issues all warnings required by the particular standard being used (which depends on other options such as -std=xxx or -ansi) and complains about use of gcc extensions.

and/or and turning warnings into errors in some cases to absolutely minimize any accidental type mismatches.

-Werror turns all warnings into errors. I don't think gcc lets you do that selectively for particular warnings, though.

You'll probably find that you have to be selective about which warnings are enabled on a per-project basis (especially if you use -Werror), as header files from external libraries can trip some of them. (-pedantic in particular tends to be unhelpful in this respect, in my experience.)

Answer 4

Well, -Wextra should be standard, too. -Werror turns warnings into errors (which can be very annoying, especially if you compile without -Wno-unused-result). -pedantic in combination with std=c89 gives you additional warnings if you use C99 features.

But that's about it. You cannot tune a C compiler into something more type-save than C itself.

Answer 5

I'm surprised nobody has said this yet - the most useful flag as far as I'm concerned is -g which puts debugging information into the executable such that you can debug it and step through the source (unless you're proficient and reading assembly and like the stepi command) of a program whilst it's executing.

Answer 6

Always use -O or above (-O1, -O2, -Os, etc.). At the default optimization level, gcc goes for compilation speed and doesn't do enough analysis to warn about things like unitialized variables.

Consider making -Werror policy, as warnings that don't stop the compilation tend to be ignored.

-Wall pretty much turns on the warnings that are very likely to be errors.

Warnings included in -Wextra tend to flag common, legitimate code. They may be useful for code reviews (though lint-style programs find a lot more pitfalls are more flexible), but I wouldn't turn them on for normal development.

-Wfloat-equal is a good idea if the developers on the project are unfamiliar with floating point, and a bad idea if they are.

-Winit-self is useful; I wonder why it's not included in -Wuninitialized.

-Wpointer-arith is useful if you have mostly-portable code that doesn't work with -pedantic.

Answer 7

-Wstrict-prototypes -Wmissing-prototypes

Answer 8

I sometimes use -s for a much smaller executable:

-s
    Remove all symbol table and relocation information from the executable.

Source: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options

Answer 9

Several of the -f code generation options are interesting:

• The -ftrapv function will cause the program to abort on signed integer overflow (formally "undefined behaviour" in C).

• -fverbose-asm is useful if you're compiling with -S to examine the assembly output - it adds some informative comments.

• -finstrument-functions adds code to call user-supplied profiling functions at every function entry and exit point.

Answer 10

Here are mine:

• -Wextra, -Wall: essential.
• -Wfloat-equal: useful because usually testing floating-point numbers for equality is bad.
• -Wundef: warn if an uninitialized identifier is evaluated in an #if directive.
• -Wshadow: warn whenever a local variable shadows another local variable, parameter or global variable or whenever a built-in function is shadowed.
• -Wpointer-arith: warn if anything depends upon the size of a function or of void.
• -Wcast-align: warn whenever a pointer is cast such that the required alignment of the target is increased. For example, warn if a char * is cast to an int * on machines where integers can only be accessed at two- or four-byte boundaries.
• -Wstrict-prototypes: warn if a function is declared or defined without specifying the argument types.
• -Wstrict-overflow=5: warns about cases where the compiler optimizes based on the assumption that signed overflow does not occur. (The value 5 may be too strict, see the manual page.)
• -Wwrite-strings: give string constants the type const char[length] so that copying the address of one into a non-const char * pointer will get a warning.
• -Waggregate-return: warn if any functions that return structures or unions are defined or called.
• -Wcast-qual: warn whenever a pointer is cast to remove a type qualifier from the target type^*.
• -Wswitch-default: warn whenever a switch statement does not have a default case^*.
• -Wswitch-enum: warn whenever a switch statement has an index of enumerated type and lacks a case for one or more of the named codes of that enumeration^*.
• -Wconversion: warn for implicit conversions that may alter a value^*.
• -Wunreachable-code: warn if the compiler detects that code will never be executed^*.

Those marked ^* sometimes give too many spurious warnings, so I use them on as-needed basis.

Answer 11

-march=native to produce optimized code for the platform (=chip) on which you are compiling

Answer 12

-Wfloat-equal

From: http://mces.blogspot.com/2005/07/char-const-argv.html

One of the other new warnings that I like is the -Wfloat-equal. That one warns whenever you [have] a floating-point number in an equality condition. That's briliant! If you have every programmed a computer graphics or (worse:) computational geometry algorithm, you know that no two floats ever match with equality...

Answer 13

If you need to know the preprocessor flags that are predefined by the compiler:

echo | gcc -E -dM -

Answer 14

-fmudflap -- adds runtime checks to all risky pointer operations to catch UB. This effectively immunizes your program again buffer overflows and helps to catch all kinds of dangling pointers.

• http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging

Here's a demo:

$ cat mf.c 
int main()
{
 int a[10];
 a[10]=1; // <-- o noes, line 4
}

$ gcc -fmudflap mf.c -lmudflap
$ ./a.out 
*******
mudflap violation 1 (check/write): time=1280862302.170759 ptr=0x7fff96eb3d00 size=44
pc=0x7f3a575503c1 location=`mf.c:4:2 (main)'
      /usr/lib/libmudflap.so.0(__mf_check+0x41) [0x7f3a575503c1]
      ./a.out(main+0x90) [0x400a54]
      /lib/libc.so.6(__libc_start_main+0xfd) [0x7f3a571e2c4d]
Nearby object 1: checked region begins 0B into and ends 4B after
mudflap object 0xf9c560: name=`mf.c:3:6 (main) a'
bounds=[0x7fff96eb3d00,0x7fff96eb3d27] size=40 area=stack check=0r/3w liveness=3
alloc time=1280862302.170749 pc=0x7f3a57550cb1
number of nearby objects: 1

Answer 15

-save-temps

This will leaves behind the results of the preprocessor, and the assembly.

The preprocessed source is useful for debugging macros.

The assembly is useful for determining what optimizations went into effect. For instance, you may want to verify that GCC is doing tail call optimization on some recursive functions, as without it you can potentially overflow the stack.

Answer 16

I occasionally have needed -fno-remove-null-pointer-checks.

Answer 17

It's not really helpful for detecting errors, but the rarely mentioned -masm=intel option makes using -S to inspect the assembly output much, much nicer.

AT&T assembly syntax hurts my head far too much.

Answer 18

While this answer may be slightly off-topic and the question is a worthy +1 from me, since

I'm particularly interested in any additional warnings, and/or and turning warnings into errors in some cases to absolutely minimize any accidental type mismatches.

there is a tool that should catch out ALL errors and potential errors that may not be obvious, there's splint which IMHO does a way better job in catching out errors compared to gcc or any other compiler for that matter. That is a worthy tool to have in your tool-chest.

Static checking via a lint-type of tool such as splint, should have been part of a compiler toolchain.

Answer 19

My makefile typically contains

  CFLAGS= -Wall -Wextra -Weffc++ -Os -ggdb
  ...
  g++ $(CFLAGS) -o junk $<
  gcc $(CFLAGS) -o $@ $<
  rm -f junk

The most important of these options have been discussed before, so I'll point out the two features that have not been pointed out yet:

Even though I'm working on a codebase that needs to be plain C for portability to some platform that still has no decent C++ compiler, I do an "extra" compile with the C++ compiler (in addition to the C compiler). That has 3 benefits:

1. the C++ compiler occasionally gives me better warning messages than the C compiler.
2. The C++ compiler accepts the -Weffc++ option, which occasionally gives me some useful tips, which I would miss out on if I only compiled it in plain C.
3. I can keep the code relatively easy to port to C++, avoiding a few boundary conditions where plain C code is invalid C++ code (such as defining a variable named "bool").

Yes, I'm a hopelessly optimistic Pollyanna that keeps thinking that surely any month now that one platform will either be declared obsolete, or gain a decent C++ compiler, and we can finally switch to C++. In my mind, it is inevitable -- the only question is whether that happens before or after management finally issues everyone a pony. :-)

Answer 20

Here's a great flag that hasn't been mentioned:

-Werror-implicit-function-declaration

Give a error whenever a function is used before being declared.