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@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On Behalf Of David.Carter-Hitchin Sent: Thursday, February 19, 2004 7:13 AM To: gcc-help@xxxxxxxxxxx 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
