Compiler options


This section is about to explain you all the options available in Dev-C++ when running the compiler. The Compiler options dialog is available by clicking on the Options menu, then on “Compiler options”.

Most of the parameters description have been taken from the GCC help file.



Directories page :


You can add multiple directories to be searched for include files during compilation by checking the appropriate check box, and by typing your directory in the edit field (separate pathnames with a semicolon “;”).


Other compiler-specific parameters can be added by checking the check box “Add the following commands…”, and by typing your commands in the edit field (separate commands by spaces). These commands can be found at Mingw32 web site.


You can also change/add the different directories needed by Dev-C++ (separate folders with a semicolon, but only one Bin directory can be specified).


C/C++ compiler page :


When compiling C programs, you can set the following options :


- Support all ANSI C standard programs (compiler parameter : -ansi):


This turns off certain features of GNU C that are incompatible with ANSI C, such as the asm, inline and typeof keywords, and predefined macros such as unix and vax that identify the type of system you are using. It also enables the undesirable and rarely used ANSI trigraph feature, and it disables recognition of C++ style // comments.


The alternate keywords __asm__, __extension__, __inline__ and __typeof__ continue to work despite -ansi. You would not want to use them in an ANSI C program, of course, but it is useful to put them in header files that might be included in compilations done with -ansi. Alternate predefined macros such as __unix__ and __vax__ are also available, with or without -ansi.


The -ansi option does not cause non-ANSI programs to be rejected gratuitously. For that, -pedantic is required in addition to -ansi. See Warning Options.


The macro __STRICT_ANSI__ is predefined when the -ansi option is used. Some header files may notice this macro and refrain from declaring certain functions or defining certain macros that the ANSI standard doesn't call for; this is to avoid interfering with any programs that might use these names for other things.


The functions alloca, abort, exit, and _exit are not builtin functions when -ansi

is used.


- Try to support some aspects of the traditional C preprocessor (compiler parameter : -traditional)


All extern declarations take effect globally even if they are written inside of a function definition. This includes implicit declarations of functions.


The newer keywords typeof, inline, signed, const and volatile are not recognized. (You can still use the alternative keywords such as __typeof__, __inline__, and so on.)


Comparisons between pointers and integers are always allowed.

Integer types unsigned short and unsigned char promote to unsigned int.

Out-of-range floating point literals are not an error.


Certain constructs which ANSI regards as a single invalid preprocessing number, such as 0xe-0xd, are treated as expressions instead.


String “constants” are not necessarily constant; they are stored in writable space, and identical looking constants are allocated separately. (This is the same as the effect of –fwritable-strings.)


Ordinarily, GNU C follows ANSI C: automatic variables not declared volatile may be clobbered.


The character escape sequences \x and \a evaluate as the literal characters x and a respectively. Without –traditional, \x is a prefix for the hexadecimal representation of a character, and \a produces a bell.


In C++ programs, assignment to this is permitted with –traditional. (The option –fthis-is-variable also has this effect.)


You may wish to use –fno-builtin as well as –traditional if your program uses names that are normally GNU C builtin functions for other purposes of its own.


You cannot use –traditional if you include any header files that rely on ANSI C features. Some vendors are starting to ship systems with ANSI C header files and you cannot use –traditional on such systems to compile files that include any system headers.


- Show all warnings (compiler parameter : -w):


This will tell the compiler to show warnings all the warnings.



For C++ programs, you can set the following options:


- Turn off all access checking (compiler parameter : -fno-accesschecking) :


Turn off all access checking. This switch is mainly useful for working around bugs in the access control code.


- Accept $ in identifiers (compiler parameter : -fdollars-in-identifier) :


Accept $ in identifiers. You can also explicitly prohibit use of $ with the option -fno-dollars-in-identifiers. (GNU C allows $ by default on most target systems, but there are a few exceptions.) Traditional C allowed the character $ to form part of identifiers. However, ANSI C and C++ forbid $ in identifiers.


- Use heuristics to compile faster (compiler parameter : -fsave-memoized) :


Use heuristics to compile faster. These heuristics are not enabled by default, since they are only effective for certain input files. Other input files compile more slowly.


The first time the compiler must build a call to a member function (or reference to a data member), it must (1) determine whether the class implements member functions of that name; (2) resolve which member function to call (which involves figuring out what sorts of type conversions need to be made); and (3) check the visibility of the member function to the caller. All of this adds up to slower compilation. Normally, the second time a call is made to that member function (or reference to that data member), it must go through the same lengthy process again. This means that code like this:


cout << "This " << p << " has " << n << " legs.\n";


makes six passes through all three steps. By using a software cache, a "hit" significantly reduces this cost. Unfortunately, using the cache introduces another layer of mechanisms which must be implemented, and so incurs its own overhead. -fmemoize-lookups enables the software cache.


Because access privileges (visibility) to members and member functions may differ from one function context to the next, G++ may need to flush the cache. With the -fmemoize-lookups flag, the cache is flushed after every function that is compiled. The -fsave-memoized flag enables the same software cache, but when the compiler determines that the context of the last function compiled would yield the same access privileges of the next function to compile, it preserves the cache. This is most helpful when defining many member functions for the same class: with the exception of member functions which are friends of other classes, each member function has exactly the same access privileges as every other, and the cache need not be flushed.


The code that implements these flags has rotted; you should probably avoid using them.


Code generation/Optimization page :


Code generation :

- Enable exception handling (compiler parameter: -fexceptions) :

Enable exception handling, and generate extra code needed to propagate exceptions. If you do not specify this option, GNU CC enables it by default for languages like C++ that normally require exception handling, and disabled for languages like C that do not normally require it. However, when compiling C code that needs to interoperate properly with exception handlers written in C++, you may need to enable this option. You may also wish to disable this option if you are compiling older C++ programs that don't use exception handling.


- Use the same size as double as for float (compiler parameter: -fshortdouble)


- Put extra information in generated assembly code (compiler parameter: -fverbose-asm) :


Put extra commentary information in the generated assembly code to make it more readable. This option is generally only of use to those who actually need to read the generated assembly code (perhaps while debugging the compiler itself).


-fno-verbose-asm, the default, causes the extra information to be omitted and is useful when comparing two assembler files.


Optimization :


- Optimize (compiler parameter: -O) :


Optimize. Optimizing compilation takes somewhat more time, and a lot more memory for a large function.


Without -O, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you would expect from the source code.


Without -O, the compiler only allocates variables declared register in registers. The resulting compiled code is a little worse than produced by PCC without -O.


With -O, the compiler tries to reduce code size and execution time.


When you specify -O, the compiler turns on -fthread-jumps and -fdefer-pop on all machines. The compiler turns on -fdelayed-branch on machines that have delay slots, and -fomit-frame-pointer on machines that can support debugging even without a frame pointer. On some machines the compiler also turns on other flags.


- Best optimization (compiler parameter: -O3) :


Optimize even more. GNU CC performs nearly all supported optimizations that do not involve a space-speed tradeoff. As compared to -O, this option increases both compilation time and the performance of the generated code.

-O3 turns on all optional optimizations like for loop unrolling and function inlining. It also turns on the -fforce-mem option on all machines and frame pointer elimination on machines where doing so does not interfere with debugging.

and also turns on the inline-functions option.


- Perform a number of minor optimizations (compiler parameter: -fexpensive-optimizations) :


Perform a number of minor optimizations that are relatively expensive.


Linker page :

- Link an objective C program (compiler parameter: -lobjc):


You need this special case of the -l option in order to link an Objective C program.


- Generate debugging information (compiler parameter: -ggdb) :


Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.


- Do not use standard system files or libraries


Do not use the standard system startup files or libraries when linking. No startup files and only the libraries you specify will be passed to the linker.


One of the standard libraries bypassed by -nostdlib and -nodefaultlibs is libgcc.a, a library of internal subroutines that GNU CC uses to overcome shortcomings of particular machines, or special needs for some languages. In most cases, you need libgcc.a even when you want to avoid other standard libraries. In other words, when you specify -nostdlib or -nodefaultlibs you should usually specify -lgcc as well. This ensures that you have no unresolved references to internal GNU CC library subroutines. (For example, __main, used to ensure C++ constructors will be called; see collect2.)