optimized -O3 crashes app

[rogster001]

what exactly happens when a build is requested using the O3 switch or other optimisations? my release build crashes, like totally dissapears, on some operations that work when built without the setting. it should be noted this is an fltk app, using codeblocks latest release and gcc

[GReaper]

When your "release" crashes, you know that there's a bug hidden somewhere. Optimizing operates on code a little different than usual.

[tabstop]

You can still do -g (and gdb) with -O3, assuming its a reproducible bug.

[rogster001]

on reading i found that the o3 option is pretty risky and can indeed cause errors, it also seems overkill for app of 2mb so i am leaving well alone, i am convinced no bug this serious exists in code itself, have been testing for weeks, and the fltk uses lots of inline and static function stuff which i read is potential problem with the option. leaving well alone and keep bug hunting!

[kmdv]

on reading i found that the o3 option is pretty risky and can indeed cause errors, it also seems overkill for app of 2mb so i am leaving well alone, i am convinced no bug this serious exists in code itself, have been testing for weeks, and the fltk uses lots of inline and static function stuff which i read is potential problem with the option. leaving well alone and keep bug hunting!

I'd keep tracking this bug. I've encountered this several times and everytime, soon or later, it turned out to be MY fault, even in the code, which I was sure about and have been using for a very long time. I'm sure you have a bug in your code, especially if you follow the standards.
Moreover, if it's your fault, it IS a serious bug. It may disappear after changing some code, and then, appear again. If you can't see this error with debugging symbols... you should try to debug it without them.

EDIT:

I've just recalled, that one of such problems was an uninitialized variable (I disabled warning because G++ was giving false warnings even in its own STL implementation). Everything worked fine for a very long time, I tried various compiler options including CPU tuning, and it had always been crashing with -o3.
I think it's a good idea to try different compiler options to find potential bugs.

[rogster001]

ok thanks for the advice, i am in personally in mode CFLAG bury head in sand at this present moment, cans of worms have been opened! bloody filepaths now too with the installed versions, its just so tedious sometimes haha!

[brewbuck]

Finding a compiler bug is like winning the lottery. It makes you feel awesome, and it also essentially never happens.

[grumpy]

I'm with kmdv - keep tracking this bug.

While the -O3 optimisation (I'm assuming g++) is less mature than other optimisation settings, it isn't actually too bad. Some of the optimisations it does actually increase likelihood of coding bugs (most notably pointer molestations) having a visible effect. In other words, -O3 is more likely to break dodgy code than other optimisation settings.

[rogster001]

right its nailed and i feel like i just won that lottery mentioned! thanks 4 advising to stick with it, i will never discount something like this again! found that bug only occurd with my own filetype, .wgn, drove me nuts as still worked on other machine, i was then cleaning registry and all kinds.. problem? simple buffer overflow in sprintf as i had not allowed enough storage for occasions where i loaded additional data found in my native filetype, !

[Elysia]

Why are you using sprintf in the first place? Get rid of those dangerous C functions!
You can use Boost for a safe alternative.