GCC optimisation issues.

Post by **pixel** » Mon Sep 20, 2004 5:12 pm

Hello,

I wasn't that much aware that the compiler's -O option was so buggy. That is true that I usually do not test my softwares using that option. Now, please, people, do NOT use -O at all :)

Even better: developp your softwares without any -O, and then, when it seems to be stable enough, retry with various -O settings (3 will most likely hit the 128-bits alignment bug, beware), and please report strange behaviors caused by optimisation option.

Thanks ;)

Post by **Drakonite** » Mon Sep 20, 2004 10:30 pm

On a project I'm working on right now...

-O2 works fine
-O1 works fine
-O0 TLB exception
no -O at all (is this same as -O0? I can't remember) TLB exception

Post by **pixel** » Mon Sep 20, 2004 10:46 pm

From gcc's manual:

Code: Select all

       -O1    Optimize.   Optimizing  compilation takes somewhat more time, and a lot more memory for a large func
              tion.

              Without `-O', the compiler's goal is to reduce the cost of compilation and to make debugging  produce
              the  expected results.  Statements are independent&#58; if you stop the program with a breakpoint between
              statements, you can then assign a new value to any variable or change the program counter to any oth
              er statement in the function and get exactly the results you would expect from the source code.

              Without  `-O',  only  variables declared register are allocated in registers.  The resulting compiled
              code is a little worse than produced by PCC without `-O'.

              With `-O', the compiler tries to reduce code size and execution time.

              When you specify `-O', the two options `-fthread-jumps' and `-fdefer-pop' are turned on.  On machines
              that  have delay slots, the `-fdelayed-branch' option is turned on.  For those machines that can sup
              port debugging even without a frame pointer, the `-fomit-frame-pointer' option is turned on.  On some
              machines other flags may also be turned on.

       -O2    Optimize  even  more.   Nearly all supported optimizations that do not involve a space-speed tradeoff
              are performed.  Loop unrolling and function inlining are not done, for example.  As compared  to  -O,
              this option increases both compilation time and the performance of the generated code.

       -O3    Optimize  yet more. This turns on everything -O2 does, along with also turning on -finline-functions.

       -O0    Do not optimize.

So, please, can you try compiling your software without stripping and without -O, and, run it until it fails, then, ee-objdump -dx on your elf file to read at the specified location by ps2link what is the faulty instruction. Bug me here or on IRC if you can't understand the asm code ;)

tjd · Post by **tjd** » Wed Sep 22, 2004 5:03 am

On the IOP, with GCC3.2.2 I've encountered [recently-- like last week] a set of strangeness related to -O2. When I backed off to -O0, the code worked as expected. -O1 didn't work either. Basically, the address of variables seemed to get lost. I'm suspecting a register allocation problem (or perhaps somebody in the call chain is not saving/restoring registers). When I have a chance, I'll dig into it more...

I know, I know. Don't use GCC3.2.2 for the IO. It's broken... it'll never work... it'll eat your children... Well, up until now, it's been pretty good and does support C++ which gives me good compatibility with the EE. Sigh.

Post by **pixel** » Wed Sep 22, 2004 5:10 am

Can you provide some code snipplet?