RE: C++ Optimization with g++

[lrtaylor at micron dot com]

Hi David,

UBS?  Is that the one in Geneva?

Anyway, if you compiled with -g and you don't get any more info than
that in GDB, I'm not sure what to tell you.  That's what I'd expect if
you stripped the binary, but not just after a debug build...  Are you
starting GDB like this: gdb /path/to/app core?  Are you running GDB
using the installed application, or just a debug version in your build
directory?  If using an installed version, is it getting stripped during
the install process?  If so, you might try disabling the stripping so
that you don't lose all of your symbol information.  

Otherwise, I think I've used up my usefulness.  :-)

Good luck,
Lyle

-----Original Message-----
From: David.Carter-Hitchin [mailto:carterda@ubs.com] 
Sent: Friday, February 20, 2004 11:05 AM
To: lrtaylor
Cc: gcc-help@gcc.gnu.org
Subject: RE: C++ Optimization with g++

Hi Lyle,

Thanks for the interest you've taken in this little problem.

I have tried looking at the core file with gdb, but I didn't get
anything
meaningful from it.  I typed "where" and merely got something like this:

# 00000000? at () ??

(That's from memory, so it might be not 100% correct - but it's faily
close).  That was after compilining with -g (I also tried -g3).

Apart from that I don't really know what else to do with a core file.
If
you've got any good "magic commands" that would be ace if you could
share
them with me.

Some other helpful folk, have offered reams of advice concerning my
programming style (or lack thereof), so I'll try their suggestions and
post
back to this thread when I solve the problem.

Many thanks,

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

On Thu, 19 Feb 2004 lrtaylor@micron.com wrote:

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