Compiling for "Release Version"

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

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]

Re: Compiling for "Releas e Version"

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

[William Pursell]

Re: Compiling for "Releas e Version"

On 12 Nov, 07:27, Tomás Ó hÉilidhe <t...@lavabit.c omwrote:

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

[Richard Tobin]

Re: Compiling for &quot;Releas e Version&quot;

In article <9773980c-ff44-400d-a159-277cf6bad1f0@c2 2g2000prc.googl egroups.com>,
Tomás Ó hÉilidhe <toe@lavabit.co mwrote:

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

[s0suk3@gmail.com]

Re: Compiling for &quot;Releas e Version&quot;

On Nov 12, 2:27 am, Tomás Ó hÉilidhe <toe@lavabit.co mwrote:

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]

Re: Compiling for &quot;Releas e Version&quot;

On 12 Nov, 11:17, s0s...@gmail.co m wrote:

On Nov 12, 2:27 am, Tomás Ó hÉilidhe <t...@lavabit.c omwrote:
>

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

[James Kuyper]

Re: Compiling for &quot;Releas e Version&quot;

s0suk3@gmail.co m wrote:

On Nov 12, 2:27 am, Tomás Ó hÉilidhe <toe@lavabit.co mwrote:

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

[Ben Bacarisse]

Re: Compiling for &quot;Releas e Version&quot;

s0suk3@gmail.co m writes:

On Nov 12, 2:27 am, Tomás Ó hÉilidhe <toe@lavabit.co mwrote:

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

[s0suk3@gmail.com]

Re: Compiling for &quot;Releas e Version&quot;

On Nov 12, 6:35 am, James Kuyper <jameskuyper@ve rizon.netwrote:

s0suk3@gmail.co m wrote:

On Nov 12, 2:27 am, Tomás Ó hÉilidhe <toe@lavabit.co mwrote:

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

[jameskuyper]

Re: Compiling for &quot;Releas e Version&quot;



s0s...@gmail.co m wrote:

On Nov 12, 6:35�am, James Kuyper <jameskuyper@ve rizon.netwrote:

s0suk3@gmail.co m wrote:

On Nov 12, 2:27 am, Tom�s � h�ilidhe <toe@lavabit.co mwrote:
>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.

[s0suk3@gmail.com]

Re: Compiling for &quot;Releas e Version&quot;

On Nov 12, 3:41 pm, jameskuyper <jameskuyper@ve rizon.netwrote:

s0s...@gmail.co m wrote:

On Nov 12, 6:35 am, James Kuyper <jameskuyper@ve rizon.netwrote:

s0suk3@gmail.co m wrote:
On Nov 12, 2:27 am, Tom s h ilidhe <toe@lavabit.co mwrote:
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

[James Kuyper]

Re: Compiling for &quot;Releas e Version&quot;

s0suk3@gmail.co m 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.

[Michael]

Re: Compiling for &quot;Releas e Version&quot;

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

[Flash Gordon]

Re: Compiling for &quot;Releas e Version&quot;

s0suk3@gmail.co m wrote, On 12/11/08 23:29:

On Nov 12, 3:41 pm, jameskuyper <jameskuyper@ve rizon.netwrote:

>s0s...@gmail.c om 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 smap@spam.cause way.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/