Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

It's said that compiling GNU tools and Linux kernel with -O3 gcc optimization option will produce weird and funky bugs. Is it true? Has anyone tried it or is it just a hoax?

share|improve this question
add comment

5 Answers

up vote 6 down vote accepted

It's used in Gentoo, and I didn't notice anything unusual.

share|improve this answer
4  
However please note that -O3 is often filtered out by ebuilds. –  Maciej Piechotka Sep 5 '10 at 12:19
add comment

-O3 has several disadvantages:

  1. First of all it often produces slower code than -O2 or -Os. Sometimes it produces longer code due to loop unrolling which may be in fact slower due to worse cache performance of code.
  2. As it was said it sometimes produces wrong code. It may be either due to error in optimalization or error in code (like ignoring strict aliasing). As kernel code sometimes is and sometimes have to be 'smart' I'd say it is possible that some kernel developer made some error. I experienced various strange problems, like crashing of userspace utilities, when I compiled kernel with gcc 4.5 which at that point was stable. I still use gcc 4.4 for kernel and several selected userspace utilities due to various bugs. The same may apply for -O3.
  3. I don't think it offers much benefit for the Linux kernel. The kernel does not do heavy computations and in places it does, it is optimized with assembly. -O3 flag will not change the cost of context switching or speed of I/O. I don't think something like <0.1% speedup of overall performance is worth it.
share|improve this answer
3  
Linux is compiled with -fno-strict-aliasing since Linus thinks gcc is being stupid and overly restrictive since it does stupid things like treat values as different even though they blatantly obviously are not (ie the aliasing was introduced inside one function and the compiler can see it). see mail-archive.com/linux-btrfs@vger.kernel.org/msg01647.html –  Spudd86 Oct 31 '10 at 16:56
    
@Spudd86: Did he mean that they are obviously not for human being reading code or for compiler? As I said - Kernel sometimes need to do smart things that userspace programs should not do. What makes sense for userspace (heavy optimization in some areas) may make no sense for kernel (larger amount of smart code + bottleneck in different places). –  Maciej Piechotka Oct 31 '10 at 17:14
    
No what he said applies to userspace too. –  Spudd86 Feb 9 '11 at 2:44
    
@Spudd86: I disagree with it then. Making compiler 'smart enough' to spot such 'obvious' things is not trivial. So the only possible way is a) produce only slow(er) code (which is unacceptable for some use cases in, say, HPC) and/or force programmers to manually optimize the code b) make the rules stricter to allow 'dumber' compiler to make optimalization - route taken by C standard. –  Maciej Piechotka Jul 24 '13 at 22:07
add comment

Note that large chunks of the toolchain (glibc in particular) flat out don't compile if you change optimization levels. The build system is setup to ignore your -O preferences for these sections on most sane distros.

Simply put, certain fundamental library and OS features depend on the code actually doing what it says, not what would be faster in many cases. -fgcse-after-reload in particular (enabled by -O3) can cause odd issues.

share|improve this answer
add comment

-O3 uses some aggressive optimisations that are only safe if certain assumptions about register use, how stack frames are interacted with, and function reentrancy are true, and these assumptions are not guaranteed to be true in some code like the kernel especially when inline assembly is used (as it is in some very low level parts of the kernel and its driver modules).

share|improve this answer
    
Not to mention it's not always faster, you have to actually come up with benchmarks and test it vs -O2 to know weather or not it hurts or helps –  Spudd86 Oct 31 '10 at 16:58
add comment

While you can get away with using -O3 and other optimizations knobs on most applications (and it can result in speed improvements), I would hesitate to use such tweaks the kernel itself or on the tool chain required for building it (compiler, binutils, etc.).

Think about it: Is a 5% performance gain of the raid and ext3 subsystems worth system crashes or potential data loss and/or corruption?

Tweak all the knobs to want for that Quake port you're playing or the audio/video codecs you use for ripping your DVD collection to divx files. You'll likely see an improvement. Just don't mess w/ the kernel unless you have time to waste and data you can bear to lose.

share|improve this answer
2  
I'am not asking if it is worth or not, safe or not, or why we shouldn't do this, what I'am asking is the fact, does it really produce bugs in real application?, does it ever occurred?, does it proved so.. –  uray Sep 5 '10 at 1:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.