By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,484 Members | 1,553 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,484 IT Pros & Developers. It's quick & easy.

Compiling for "Release Version"

P: n/a

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?
Nov 12 '08 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Tomás Ó hÉilidhe wrote:
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
Nov 12 '08 #2

P: n/a
On 12 Nov, 07:27, Tomás Ó hÉilidhe <t...@lavabit.comwrote:
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?

Generally, it is a good idea to run your testsuite multiple
times with optimizations of different levels. If you use a debugger,
it can be painful when optimizations are on and that is
typically why they get turned off for testing. But it is
a bad idea not to test with the optimization on as well.

IOW, run both:

configure CFLAGS="-g" && make check
** and **
configure CFLAGS="-g -O3" && make check

(or, in your case, compile by hand and run your test suite
with both levels of optimization. Pray you don't need
to use a debugger on the optimized version.)
Nov 12 '08 #3

P: n/a
In article <97**********************************@c22g2000prc. googlegroups.com>,
Tomás Ó hÉilidhe <to*@lavabit.comwrote:
>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
--
Please remember to mention me / in tapes you leave behind.
Nov 12 '08 #4

P: n/a
On Nov 12, 2:27*am, Tomás Ó hÉilidhe <to*@lavabit.comwrote:
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

Nov 12 '08 #5

P: n/a
On 12 Nov, 11:17, s0s...@gmail.com wrote:
On Nov 12, 2:27*am, Tomás Ó hÉilidhe <t...@lavabit.comwrote:
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!
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.

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.

--
Nick Keighley
Nov 12 '08 #6

P: n/a
s0****@gmail.com wrote:
On Nov 12, 2:27 am, Tomás Ó hÉilidhe <to*@lavabit.comwrote:
>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!
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).
Nov 12 '08 #7

P: n/a
s0****@gmail.com writes:
On Nov 12, 2:27Â*am, Tomás Ó hÉilidhe <to*@lavabit.comwrote:
>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!
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.

--
Ben.
Nov 12 '08 #8

P: n/a
On Nov 12, 6:35*am, James Kuyper <ja*********@verizon.netwrote:
s0****@gmail.com wrote:
On Nov 12, 2:27 am, Tomás Ó hÉilidhe <to*@lavabit.comwrote:
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!

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

Nov 12 '08 #9

P: n/a


s0s...@gmail.com wrote:
On Nov 12, 6:35�am, James Kuyper <ja*********@verizon.netwrote:
s0****@gmail.com wrote:
On Nov 12, 2:27 am, Tom�s � h�ilidhe <to*@lavabit.comwrote:
>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!
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.
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.
Nov 12 '08 #10

P: n/a
On Nov 12, 3:41*pm, jameskuyper <ja*********@verizon.netwrote:
s0s...@gmail.com wrote:
On Nov 12, 6:35 am, James Kuyper <ja*********@verizon.netwrote:
s0****@gmail.com wrote:
On Nov 12, 2:27 am, Tom s h ilidhe <to*@lavabit.comwrote:
When I'm writing my own code, compiling it and testing it out as Igo
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!
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.

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

Nov 12 '08 #11

P: n/a
s0****@gmail.com wrote:
....
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.
Nov 13 '08 #12

P: n/a
� wrote:
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)
Nov 13 '08 #13

P: n/a
s0****@gmail.com wrote, On 12/11/08 23:29:
On Nov 12, 3:41 pm, jameskuyper <ja*********@verizon.netwrote:
>s0s...@gmail.com wrote:
<snip whether or not to use C99 features>
>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.
However, his customers may not be prepared to use them.

<snip>
>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
<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).
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
Nov 13 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.