[LCP]Rounding questions
Greg Black
gjb at gbch.net
Mon Sep 9 22:26:05 UTC 2002
Chuck Martin wrote:
| On Sat, Sep 07, 2002 at 06:10:37PM +1000, Greg Black wrote:
| > The next step would be to try turning them off selectively. If
| > there are a dozen .o files, it may be only one that has a bug
| > introduced by the optimiser. Try each one separately with the
| > optimiser and see how it goes.
|
| Unless the problem is in an unrelated part of the code, there is
| only one file where I've had any problems, as far as I can tell.
| However, the flag for optimizing is in a variable called CFLAGS in
| the Makefile. This would have to be moved to the rules for each
| of the source files, instead. Are C compilers command line options
| standardized enough that this would be portable (There are different
| sections in the Makefile for different O/S's and compilers that can
| be commented/uncommented, and each might have its own CFLAGS).
The question is too vague for me to give a precise answer. But,
if you know how to use make, it's a no-brainer to solve. If you
don't know how to use make, this would be a good time to learn.
Here's one trivial approach. Use OFLAGS for the optimiser flags
and CFLAGS for other compiler flags. Then the rule for most .o
files uses ${CFLAGS} and ${OFLAGS}, while the rule for the case
which gives the optimiser a headache drops the ${OFLAGS}.
People often use variants of this to selectively turn on or off
debugging and profiling as well as controlling optimisation.
| > Certainly, unless it's absolutely huge, don't even think about
| > the size of the executable -- modern disk is almost free and
| > it's not worth accepting bugs to save a few bytes of disk.
|
| I've always liked Forth and Assembler, and I probably obsess too
| much on keeping things small, but I'll try not to let it bother
| me. :)
I like small; and I like fast; but most of all I like correct.
The rest is fluff.
Greg
More information about the linuxCprogramming
mailing list