Bug #5196


The cw wrapper restricts gcc to -O2

Added by Gary Mills over 7 years ago. Updated over 7 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


I'm using Illumos gcc-4.4.4-il-3 as the primary compiler and Sun C 5.9 as the shadow compiler. Even though the default optimization level is specified as -xO3 in Makefile.master, the gcc compiler only optimizes at level 2. This code in usr/src/tools/cw/cw.c is the cause:

if (level >= 2) {
/* * For gcc-3.4.x at -O2 we * need to disable optimizations * that break ON.
optim_disable(ctx->i_ae, level);/
* limit xO3 to -O2 as well.
level = 2;
(void) snprintf(s, len, "-O%d", level);
>i_ae, s);

Note that it does not actually check the gcc compiler version. The cw wrapper needs to be fixed.

By modifying this code, I was able to get gcc to run with optimization level 3. In order to get a clean build, I had to suppress warnings by adding -Wno-uninitialized and to eliminate some optimizations by adding -fno-strict-aliasing -fno-tree-vrp .

Is anybody building illumos by running gcc without the cw wrapper? I'd like to know what -W and -f options you had to add, not counting the ones already specified in the Makefiles.

Actions #1

Updated by Andrew Stormont over 7 years ago

I'm building illumos with -O3. Didn't need to disable any specific optimisations but I did need to add -Wno-array-bounds to usr/src/uts/Makefile.uts. Seems like there are real errors in the illumos code that need fixing.

Actions #2

Updated by Rich Lowe over 7 years ago

-Warray-bounds is, sadly, not necessarily an indication of real problems.

The reason I disabled it (I actually tried to disable it globally, but missed, as you noticed...) is that it can misfire in ways that render code impossible to fix. I think it's going to be 99% real problems, but at least one of them is both unreal and impossible to phrase in a way GCC likes.

This does demonstrate why you have to test such a change to the optimizer as if you'd changed everything though, it has potentially very far reaching effects on the code GCC generates and we have code that is very sensitive even to correct changes in optimization1.

If you're were going to do it, doing it when you were changing the compiler would be both a good and a bad time, good in that you're doing all that testing anyway, and bad, in that you'd have to work out which change introduced any bugs you found.

[1] Yes, that's a polite way of saying "some of our code is bloody awful"

Actions #3

Updated by Gary Mills over 7 years ago

That's why the proper way to introduce this change is to remove the restriction from the cw wrapper but compensate by changing the Makefiles. That way, the build command lines will be unchanged, and the files built will also be unchanged.

Once that is done, optimization of testable sections of the whole illumos product can be changed individually and safely.


Also available in: Atom PDF