No. This has been mentioned often on this list: -O<x> is more than just combinations of -f<thing>(s). Details will need to come from someone more knowledgeable (or search the archives), but I know this much is true. -a Sent from my iPhone On Feb 2, 2011, at 12:01 PM, kevin diggs <diggskevin38@xxxxxxxxx> wrote: > Hi, > > What if you try looking at the output of '-S -fverbose-asm'? Doesn't > that include all of the -f<thing> optimizery flags that are actually > passed to cc1? Maybe one of those will suggest something helpful? > > Do the -O<x> flags only select sets of -f<thing>(s)? Or do they also > enable some things on their own? In other words if I did -O1 and then > did -fno-<thing> for everything that -O1 turned on would I effectively > disable -O1? > > kevin > > On Wed, Feb 2, 2011 at 12:39 PM, Stefan Schulze Frielinghaus > <stefan@xxxxxxxxxxxx> wrote: >> On Mi, 2011-02-02 at 19:05 +0100, Drasko DRASKOVIC wrote: >>> On Wed, Feb 2, 2011 at 6:55 PM, Stefan Schulze Frielinghaus >>> <stefan@xxxxxxxxxxxx> wrote: >>>>> But have you tried comparing the outputs of what -O0 outputs to say -O2 ? >>>> >>>> The problem with using anything else then -O0 is that it enables other >>>> optimization techniques, e.g. constant propagation (the example of the >>>> first mail would be scaled down to a simple "return 0;") which I do not >>>> want. Therefore, I would like to compile my code without any >>>> optimizations except register allocation. >>> >>> Hi Stefan, >>> keep in mind that "register" keyword is only a **hint** given to >>> compiler to do register optimization. Compiler is not obliged to >>> listen to your hints, and it probably does not do so without >>> optimization turned on (I am not sure if it can be forced). >> >> Yes that's true. I only used it in my examples to demonstrate what >> result I actually wanted. >> >>> BTW, you should also keep in mind that ANSI C does not allow for >>> taking the address of a register object; this restriction does not >>> apply to C++. However, if the address-of operator (&) is used on an >>> object, the compiler must put the object in a location for which an >>> address can be represented. In practice, this means in memory instead >>> of in a register. Because of this restriction GCC will ignore the >>> register keyword on variables whos address is taken at any point in >>> the program. So, ensure that somewhere in your code you are not using >>> the addresses operator on these variables. >> >> This wouldn't be a problem for me because in ANSI C, as you already >> mentioned, the address-of operator is not allowed for variables which >> reside in a register, ergo the variable cannot stay in a register and >> needs to be spilled on the stack. That is perfectly fine for me. I'm >> more interested in all other variables. >> >> Kind regards, >> Stefan >> >>
