[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