What are the useful GCC flags for C?

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.

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.

Several of the -f code generation options are interesting:

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

• --coverage instruments the branches and calls in the program and creates a coverage notes file, so that when the program is run coverage data is produced that can be formatted by the gcov program to help analysing test coverage.

• -fsanitize={address,thread,undefined} enables the AddressSanitizer, ThreadSanitizer and UndefinedBehaviorSanitizer code sanitizers respectively. These instrument the program to check for various sorts of errors at runtime.

Previously this answer also mentioned -ftrapv, however this functionality has been superseded by -fsanitize=signed-integer-overflow which is one of the sanitizers enabled by -fsanitize=undefined.

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.

-save-temps

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

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.

-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

Not really related to C/C++, but useful anyways :

@file

Put all the above good flags (which you all have specified) in a 'file', and use this above flag to use all the flags in that file together.

eg:

File : compilerFlags

> -Wall > > -std=c99 > > -Wextra

Then compile :

gcc yourSourceFile @compilerFlags

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

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

echo | gcc -E -dM -

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.

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.

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

-Wstrict-prototypes -Wmissing-prototypes

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.

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.

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.

-M* family of options.

These let you write make files that automatically figure out what header files your c or c++ source files should depend on. GCC will generate make files with this dependency information, and then you -include them from your primary make file.

Here's an example of an extremely generic makefile using -MD and -MP that will compile a directory full of c++ source and header files, and figure out all the dependencies automatically:

CPPFLAGS += -MD -MP                                         
SRC = $(wildcard *.cpp)                                                       

my_executable: $(SRC:%.cpp=%.o)                                                        
        g++ $(LDFLAGS) -o $@ $^                                               

-include $(SRC:%.cpp=%.d)

Here's a blog post that discusses it in more depth: http://www.microhowto.info/howto/automatically_generate_makefile_dependencies.html

I found this thread looking for a flag to fix a specific issue, I don't see it on here so I'll add one that was just stumping me on https://stackoverflow.com/questions/13068619/inverted-arguments-in-scanf/13068825#13068825">my post:

The -Wformat=2 flag

> -Wformat => Check calls to printf and scanf, etc., to make sure that the arguments supplied have types appropriate to the format string specified...

And the really important part about it (according to the GCC manual):

> -Wformat is included in -Wall. For more control over some aspects of format checking, the options -Wformat-y2k, -Wno-format-extra-args, -Wno-format-zero-length, -Wformat-nonliteral, -Wformat-security, and -Wformat=2 are available, but are not included in -Wall.`

So, just because you have -Wall doesn't mean you have it all. ;)

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

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

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.

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

• -Wmissing-prototypes: If a global function is defined without a previous prototype declaration.
• -Wformat-security: Warns about uses of format functions that represent possible security problems. At present, this warns about calls to printf and scanf functions where the format string is not a string literal and there are no format arguments

• -Werror=return-type: Enforce error when function has no return in gcc. It is /we4716 in Visual Studio.

• -Werror=implicit-function-declaration: Enforce error when function is used without defined / not included. It is /we4013 in Visual Studio.

• -Werror=incompatible-pointer-types: Enfore error when a pointer's type mismatched with expected pointer type. It is /we4133 in Visual Studio.

Actually, I'd like to keep my C code cross-platform, and I use CMake, and I put the provided cflags into CMakeLists.txt like:

if (CMAKE_SYSTEM_NAME MATCHES "Windows")
    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /we4013 /we4133 /we4716")
elseif (CMAKE_SYSTEM_NAME MATCHES "Linux" OR CMAKE_SYSTEM_NAME MATCHES "Darwin")
    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -Werror=return-type")
endif()