Page 1 of 1
GCC optimisation issues.
Posted: Mon Sep 20, 2004 5:12 pm
by pixel
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 ;)
Posted: Mon Sep 20, 2004 10:30 pm
by Drakonite
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
Posted: Mon Sep 20, 2004 10:46 pm
by pixel
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: 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 ;)
Posted: Wed Sep 22, 2004 5:03 am
by tjd
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.
Posted: Wed Sep 22, 2004 5:10 am
by pixel
Can you provide some code snipplet?