gcc optimisation issues

8 posts
by paulcpaulc » Thu Jun 14, 2012 1:49 pm

Is anyone else seeing issues when coding in C and using gcc optimisation levels? If I compile my code with no optimisation settings then all is oka, but if I apply -O1 or -O2 or -O3 then I get really weird behaviour in my executable.

Of course I suspect there must be something in my code that's my fauilt, but as the tool-chain is I guess fairly new on the Pi I thought I'd ask in case others. Code is too large to post a meaningful frag I'm afraid.

For now to get the performance I need I'm now manually unrolling my loops but this makes code look ugly. It will do until I get to the bottom of the gcc optimisation issues I'm seeing.

- Paul
Posts: 15
Joined: Sun May 27, 2012 12:06 pm
by jamesh » Thu Jun 14, 2012 2:04 pm
Do you know which bit of the code starts to fail at higher opt levels? The toolchain supplied is a completely standard gcc Arm compiler, so although there may be corner cases where -O3 gives problems I would not expect any issues for the vast majority of code.

There are notably differences in debug vs release builds also, for example, allocated memory is not cleared on release builds but might be on debug builds. Do you have uninitialised data somewhere? That a common culprit.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17116
Joined: Sat Jul 30, 2011 7:41 pm
by paulcpaulc » Thu Jun 14, 2012 2:34 pm
Thanks for your thoughts - much appreciated.

I always suspect a bug my end first, and your response around standard toolchain reinforces that it's the right view.

I'm at a conference till the weekend but will try to investigate further then.

Posts: 15
Joined: Sun May 27, 2012 12:06 pm
by Timo » Thu Jun 14, 2012 2:56 pm
You may try to run your program with valgrind (if available: sudo apt-get install valgrind).
Code: Select all
valgrind ./myprog myparameters
There are several parameters for valgrind, but even without them, it should warn about using uninitialized data. To see better output add -ggdb3 to your gcc options.
Posts: 8
Joined: Sat Aug 27, 2011 9:04 am
by plugwash » Sun Jun 17, 2012 10:57 pm
When asking questions about compiler issues please tell us

1: what distribution you are running
2: what toolchain you are using (gcc version, native or cross, from the distro you are running or elsewhere and so-on).

Also try and come up with a small testcase that is behaving differently from the way you expect it to.
Forum Moderator
Forum Moderator
Posts: 3211
Joined: Wed Dec 28, 2011 11:45 pm
by paulcpaulc » Sat Jun 30, 2012 11:06 am
Found the problem

As I suspected, my fault - local variable array overflow, with different consequences depending on optimisation - not surprising really.

Thanks all - glad there is confidence in toolchain so I was right to suspect my code.

Posts: 15
Joined: Sun May 27, 2012 12:06 pm
by jdbennet » Wed Jul 25, 2012 5:42 pm
You often see this if you are using threading, and have race conditions, they may not become apparent till it is run at a different speed (i.e. bug appears on x86 but not armel)
Posts: 96
Joined: Sun Jul 22, 2012 2:25 pm
by paulcpaulc » Wed Jul 25, 2012 5:57 pm
I must have written a million lines of C (literally), including published games, but I haven't coded in C for more than 10 years so I made some silly errors. Still that was a month or so ago and now things are going very well now thanks. Loop unrolling my blit code to get required performance including run-time generated run-length alpha map has got me back in my stride :-) I haven't had to optimise like this since I coded games on Philips CD-i player in the 90's!
Posts: 15
Joined: Sun May 27, 2012 12:06 pm