C++ Optimization with g++

[lrtaylor@micron.com]

Have you tried looking at a stack trace?  If your program is SEGV'ing,
it should be producing a core file (I guess unless you're on Windows).
You can inspect that core file using GDB, including the full stack
(including variable values, etc.) at the time of the crash.  That's
usually the first place I look when a program crashes.

Good luck,
Lyle

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of David.Carter-Hitchin
Sent: Thursday, February 19, 2004 7:13 AM
To: gcc-help@gcc.gnu.org
Subject: C++ Optimization with g++

Hi,

I haven't done a great deal of optimization, so apologies in advance for
any
dumb or mis-directed questions.

I've got this nice little ~5,000 line c++ program at home which plots
the
positions of planets and the Yale Bright Star Catalogue.

So far so good.

Scrolling an zooming are fine, but when I swtich the option on to
display
dates (which involves rotating the bitmaps for the textstrings through
90
degrees) it runs "like a dog" and I'm not talking greyhound, more like a
three-legged dachshund.

So I tried putting -O[0123] on and ploop, the program is just warming up
and
then it SEGV's.  It seems to be happening at the end of one function
call
(which appears to run fine) or at the very start of another.  Compiling
with
-g and running in gdb shows the point, which is just at the final } from
the
last function that works successfully.

Ultimately I can reprogram the date stuff so I don't have to rotate the
dates on the fly (which is the way I should have done it originally),
but
now I'm curious.

How can I find out why -O[0123] fails?  Is there a strategy I can follow
or doc I should read?  Is there a "simple" way of debugging my way out
of
this situation, or is there no alternative to inspecting the assembly?

gcc version 2.9.something (not threaded).

All help and clues appreciated.

Many thanks,

David Carter-Hitchin,
GSD-Risk-IT, UBS Investment Bank