Compiling for "Release Version"

[Tomás Ó hÉilidhe]

When I'm writing my own code, compiling it and testing it out as I go
along, I usually compile as follows:

gcc *.c -ansi -pedantic -Wall -o executable

If I'm using 3rd-party libraries, I'll usually do the following:

gcc *.c -Wall -o executable

When I've already tested my code and I'm distributing it to other
people to use, I tend to tell them to compile as follows:

gcc *.c -o executable

If my code has been well-tested and I'm certain it works perfectly, I
compile as follows:

gcc *.c -O3 -D NDEBUG -s -o executable

I can understand why we don't use "-D NDEBUG" or "-s" when testing
because we want to catch asserts that go off, but I'm curious as to
whether there's any reason to shy away from using "-O3" (or any
optimisations for any compiler for that matter) in debugging version?

 

[Joachim Schmitz]

When I'm writing my own code, compiling it and testing it out as I go
along, I usually compile as follows:

gcc *.c -ansi -pedantic -Wall -o executable

If I'm using 3rd-party libraries, I'll usually do the following:

gcc *.c -Wall -o executable

When I've already tested my code and I'm distributing it to other
people to use, I tend to tell them to compile as follows:

gcc *.c -o executable

If my code has been well-tested and I'm certain it works perfectly, I
compile as follows:

gcc *.c -O3 -D NDEBUG -s -o executable

I can understand why we don't use "-D NDEBUG" or "-s" when testing
because we want to catch asserts that go off, but I'm curious as to
whether there's any reason to shy away from using "-O3" (or any
optimisations for any compiler for that matter) in debugging version?

Because optimized code can be very hard to debug. Depending on the compiler
and debugger you don't end up where you think you should, you can't inspect
variables as they might have been optimized away, you may not be able to see
the arguments to functions etc. As sone form of optimization usually is the
default, for debugging versions I tend to switch it off explicitly, eg.
with -O0.
Also the -g (for symbols in the executable) or whatever the compiler uses
for this, usually is not part of the default settings, so I'd switch it on
for the debug versions. For gcc even -g3.

Bye, Jojo

 

[Richard Tobin]

I can understand why we don't use "-D NDEBUG" or "-s" when testing
because we want to catch asserts that go off, but I'm curious as to
whether there's any reason to shy away from using "-O3" (or any
optimisations for any compiler for that matter) in debugging version?

I strongly recommend using some optimisation when compiling new code,
because gcc (and other compilers) can often give better warnings when
they optimise. For example. optimisation may result in more analysis
of variable use, allowing the compiler to warn about an uninitialised
variable that it would not otherwise detect.

On the other hand, optimisation can make debuggers work less well,
often because a variable has no real existence in the optimised
version.

Generally I compile with -O and recompile without it if it causes
debugging problems.

-- Richard

 

[s0suk3]

When I'm writing my own code, compiling it and testing it out as I go
along, I usually compile as follows:

    gcc *.c -ansi -pedantic -Wall -o executable

That's too restrictive; it turns off a LOT of useful gcc features,
such as compound literals, 64-bit integers (long long), variable-
length arrays, boolean variables, variadic macros, inline functions,
etc. It doesn't even allow // comments or mixing of statements and
declarations!

If you want standard C, at least specify std=c99, like

gcc *.c -std=c99 -Wall -o executable

which at least gives you the C99 features.

If I'm using 3rd-party libraries, I'll usually do the following:

    gcc *.c -Wall -o executable

That's good too.

Sebastian

 

[Nick Keighley]

That's too restrictive; it turns off a LOT of useful gcc features,
such as compound literals, 64-bit integers (long long), variable-
length arrays, boolean variables, variadic macros, inline functions,
etc. It doesn't even allow // comments or mixing of statements and
declarations!

none of which are portable to C89 (old standard) compilers.
You can go a long way without any of the features you
mention above. Using them may restrict the portability
of your code. C99 compilers are not yet universal.

 

[James Kuyper]

That's too restrictive; it turns off a LOT of useful gcc features,
such as compound literals, 64-bit integers (long long), variable-
length arrays, boolean variables, variadic macros, inline functions,
etc. It doesn't even allow // comments or mixing of statements and
declarations!

What if he needs his code to be compilable by compilers that don't
support all of those features? Compilers that support all features of
C99 are rare, compilers that support only C90 are not unheard of, and
compilers that support C99 incompletely don't all support the same C99
features. Even gcc, by it's own admission, doesn't fully support
variable length arrays (though I've yet to see a clear statement about
which aspects of VLAs they don't support correctly).

 

[Ben Bacarisse]

That's too restrictive; it turns off a LOT of useful gcc features,
such as compound literals, 64-bit integers (long long), variable-
length arrays, boolean variables, variadic macros, inline functions,
etc. It doesn't even allow // comments or mixing of statements and
declarations!

It has already been pointed out, but the OP might want that
restriction to be sure of compilation "almost everywhere".

If you want standard C, at least specify std=c99, like

gcc *.c -std=c99 -Wall -o executable

My view is that this is too permissive. It does not turn off gcc
extensions so your code is still not being checked for compliance. I
would add -pedantic to get only C99 and no extras.

 

[s0suk3]

What if he needs his code to be compilable by compilers that don't
support all of those features?

I doubt it. He has pointed out in other threads that he's primarily
interested in Windows and Linux, so he may have access to compilers
such as gcc, Intel, lcc-win32, and Comeau, to name a few.

Sebastian

 

[jameskuyper]

I doubt it. He has pointed out in other threads that he's primarily
interested in Windows and Linux, so he may have access to compilers
such as gcc, Intel, lcc-win32, and Comeau, to name a few.

Just because he has access to them doesn't mean he's willing to
restrict the portability of his code to such compilers; for instance,
I have access to gcc on all the platforms my code needs to work, but
I'm working to a contractual requirement that our delivered code must
"conform" to C90 (the people who wrote that requirement clearly did
not know how meaningless the term "conforming code" is in C - I try to
obey the spirit of that requirement, and not just the letter of it).

Only Thom�s can tell us what his actual needs are. The fact that he
can compile his code with the options listed implies that he's not
currently taking advantage of any of those C99 features.

 

[s0suk3]

Just because he has access to them doesn't mean he's willing to
restrict the portability of his code to such compilers;

The portability of the code is always restricted, either with C89 or
with C99. While there are more C89 compilers, the currently available
C99 compilers already allow code to be portable among most relevant
platforms, and even some obscure ones.

for instance,
I have access to gcc on all the platforms my code needs to work, but
I'm working to a contractual requirement that our delivered code must
"conform" to C90 (the people who wrote that requirement clearly did
not know how meaningless the term "conforming code" is in C - I try to
obey the spirit of that requirement, and not just the letter of it).

Only Thom s can tell us what his actual needs are. The fact that he
can compile his code with the options listed implies that he's not
currently taking advantage of any of those C99 features.

Yes, but the interesting question is: why? Is it because he needs the
code to port to a coffee machine where there isn't a C99 compiler
available? Or is it because people in this group have suggested him
not to use the C99 features simply because it's not their version of
choice?

But, as you said, only Tomás can tell us what his requirements are,
so,

Tomás: are you planing to port to a platform where there isn't a
compiler that supports the features in question?

Sebastian

 

[James Kuyper]

The portability of the code is always restricted, either with C89 or
with C99. While there are more C89 compilers, the currently available
C99 compilers already allow code to be portable among most relevant
platforms, and even some obscure ones.

If code is writtem to make use only of the common subset of C90 and C99,
it will still be portable to all of those compilers, and also to a great
many others. Making use of features specific to C89 restricts
portability, but there's little or no reason to do that except in legacy
software - most of those features were removed for a good reason.

Making use of features specific to C99 is more of a tradeoff - each of
those features were added because a significant number of people
actually wanted them to be added. However, every such feature you use
reduces the number of compilers which can compile your code correctly
(and makes it harder to identify which compilers those are). Because of
those trade-offs, it's perfectly reasonable to choose either strict C90,
strict C99, or any place in between those extremes, depending upon
circumstances. I prefer the extremes; choosing the right point somewhere
in the middle requires a judgment call, and I'm lousy at judgment calls
- YMMV.

 

[Michael]

When I'm writing my own code, compiling it and testing it out as I go
along, I usually compile as follows:

gcc *.c -ansi -pedantic -Wall -o executable

If I'm using 3rd-party libraries, I'll usually do the following:

gcc *.c -Wall -o executable

When I've already tested my code and I'm distributing it to other
people to use, I tend to tell them to compile as follows:

gcc *.c -o executable

If my code has been well-tested and I'm certain it works perfectly, I
compile as follows:

gcc *.c -O3 -D NDEBUG -s -o executable

I can understand why we don't use "-D NDEBUG" or "-s" when testing
because we want to catch asserts that go off, but I'm curious as to
whether there's any reason to shy away from using "-O3" (or any
optimisations for any compiler for that matter) in debugging version?

Normally I use CXXFLAGS="-ggdb3 -Wall -Wextra" when debugging,
CXXFLAGS="-O3" for release (using g++ as my compiler)

 

[Flash Gordon]

The portability of the code is always restricted, either with C89 or
with C99. While there are more C89 compilers, the currently available
C99 compilers already allow code to be portable among most relevant
platforms, and even some obscure ones.

However, his customers may not be prepared to use them.

Yes, but the interesting question is: why? Is it because he needs the

<snip>

He stated that he was shipping code to people. That means he won't have
complete control over what compilers they choose to use. For example,
one customer might have spent a lot of money on an MSDN subscription and
get rather pissed off when told that they cannot use the compiler in it.
Another might be stuck on SCO 5.0.5 due to support for other SW and not
be able to get a modern version of gcc running on it (I know it was
giving me a lot of grief).