Re: Need some clarification about optimization flags, what "exactly" does -O1 do?

[Andrew Haley <aph at redhat dot com>]

Andrzej Giniewicz wrote:
> Hi - it's my first time on that list, I hope I choose good one as gcc
> have really quite number of different mailing lists :)
> 
> lately I hit very strange behaviour, i.e. the app I wanted to build
> works when I build it with -O0 but crash at -O1, I wanted to eliminate
> flags that work as I usually do, by doing -O0 and adding all flags
> that are on -O1 and aren't on -O0, I got their list using standard
> recommended by manual way:
> 
> g++ -c -Q -O0 --help=optimize > 0.flags
> g++ -c -Q -O1 --help=optimize > 1.flags
> diff 0.flags 1.flags | grep enabled
> 
> the problem is that I was able to add all flags returned by above
> commands! Is there some secret things that -O1 do instead of only
> lighting those -f*** flags listened by above commands? If above
> returned me:
> 
> -fcprop-registers -fdefer-pop -fguess-branch-probability
> -fif-conversion -fif-conversion2 -fipa-pure-const -fipa-reference
> -fmerge-constants -fomit-frame-pointer -fsplit-wide-types -ftree-ccp
> -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-dce
> -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-salias -ftree-sink
> -ftree-sra -ftree-ter -funit-at-a-time
> 
> is there any difference / reason why in my case:
> 
> -O1
> 
> fails but:
> 
> -O0 -fcprop-registers -fdefer-pop -fguess-branch-probability
> -fif-conversion -fif-conversion2 -fipa-pure-const -fipa-reference
> -fmerge-constants -fomit-frame-pointer -fsplit-wide-types -ftree-ccp
> -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-dce
> -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-salias -ftree-sink
> -ftree-sra -ftree-ter -funit-at-a-time
> 
> works?... 

With -O0 you get no optimization, regardless of the other options.

> I build with athlon-xp architecture but same happens when I
> do i686 (with tune=generic)... it's of course Linux, and I use GCC
> 4.3.2

> btw, the problem I have is during run of OGRE3D engine so quite huge
> app, I managed to track the problem up to this place:
> 
>             HardwareIndexBuffer::IndexType indexType =
> mCurrentSection->get32BitIndices()? HardwareIndexBuffer::IT_32BIT :
> HardwareIndexBuffer::IT_16BIT;
> 
> there IndexType is enum for only those two values that in any other
> context are 0/1, and get32BitIndices is function returning bool, this
> makes it kind of:
> 
>             int x = boolValue ? 0:1;

What does the declaration of IndexType look like?

> the problem is that any diagnostic, stwich/case/if for that value
> equal HardwareIndexBuffer::IT_32BIT or HardwareIndexBuffer::IT_16BIT
> fail, simple cout on it says it's 104... always, every run - every
> build with anything more than -O0... it's working on -O0 thought and
> -O0 with above flags... anyway for now question is rather about what
> more than flags returned by those 3 mentioned lines of shell does -O1
> do because I can just go on with disabling one feature and leaving
> rest in place

The bug is probably in your app, not in gcc.
I think you'd be much better off fixing the bug than trying to
discover which optimization pass it breaks.

Andrew.