selective/fine grained optimizations control

We have a project which Clang miscompiles in release builds (in short "the GUI shows up empty"). "It all worked fine" up until and including Xcode 4.2, with all later versions (of Xcode and consequently of Clang shipped with it) this bug manifests itself. As we officially switched to Xcode 4.6.3 I have to find a way to workaround or fix this problem.

The bug manifests already with -O1 while it does not with -O0 so I need a way to selectively enable or disable optimizations turned on at O1. GCC nicely documents which optimizations are turned on by individual -O levels and offers the various -fno-* options for fine grained control but unfortunately Clang does not actually support GCC's command line options other than the basic ones.

I did find this
http://stackoverflow.com/questions/15548023/clang-optimization-levels
but it didn't help: I tried -O0 -mllvm -sroa and got:
clang (LLVM option parsing): Unknown command line argument '-sroa'. Try: 'clang (LLVM option parsing) -help'
clang (LLVM option parsing): Did you mean '-help'?

Is there any other way to achieve fine grained optimizations control?

passes.

It's probably a better idea to figure out which file is getting incorrectly
compiled, and change the optimization level for that file,instead of
messing with the optimization levels for the whole project. Also, this
sort of issue is almost always caused by code that has undefined behavior,
not by a bug in the compiler.

-Eli

I beg to differ: We still have to compile the affected project with -O1 to ensure that the destructors properly fire. - ½

I know the compiler has lots of bugs; I work on them every day. :slight_smile: It's
still not the first explanation to look for.

-Eli

And for that I salute you. I wish I had more time to investigate that one particular issue. The trappings of modern life, and all that :slight_smile: That said, I do tend to look in the direction of the LLVM optimizer when gcc debug/optimized & clang debug all give the same answer, but clang optimized disagrees. When faced with an optimizer bug, it would be great to be able to quickly narrow down a particular function (or set of) with an attribute, rather than extract potential culprits into their own source with its own optimization level. This is especially true in the presence of large code bases with hairy build systems, helper classes internal to compile-units, and myriad static helper functions. I do this sometimes with gcc, especially because we build our product for multiple gcc versions. That way we can just disable specific optimizations for a given gcc version with a known optimizer bug. It’s not ideal but it gets the job done. I know this feature is already being discussed, I’m just throwing my vote in that direction. - ½

    We have a project which Clang miscompiles in release builds (in short "the
    GUI shows up empty"). "It all worked fine" up until and including Xcode 4.2,
    with all later versions (of Xcode and consequently of Clang shipped with it)
    this bug manifests itself. As we officially switched to Xcode 4.6.3 I have
    to find a way to workaround or fix this problem.

    The bug manifests already with -O1 while it does not with -O0 so I need a
    way to selectively enable or disable optimizations turned on at O1. GCC
    nicely documents which optimizations are turned on by individual -O levels
    and offers the various -fno-* options for fine grained control but
    unfortunately Clang does not actually support GCC's command line options
    other than the basic ones.

    I did find this
    http://stackoverflow.com/__questions/15548023/clang-__optimization-levels
    <http://stackoverflow.com/questions/15548023/clang-optimization-levels>
    but it didn't help: I tried -O0 -mllvm -sroa and got:
    clang (LLVM option parsing): Unknown command line argument '-sroa'. Try:
    'clang (LLVM option parsing) -help'
    clang (LLVM option parsing): Did you mean '-help'?

    Is there any other way to achieve fine grained optimizations control?

clang intentionally doesn't expose fine-grained control over optimization passes.

Can I ask for the rationale behind the intention?

It's probably a better idea to figure out which file is getting incorrectly
compiled, and change the optimization level for that file,instead of messing
with the optimization levels for the whole project. Also, this sort of issue is
almost always caused by code that has undefined behavior, not by a bug in the
compiler.

I exactly did that immediately after sending the original email just didn't find the time until now to report...

The issue was caused by

template <int ID>
__attribute__(( const ))
SomeClass const & someFunction()
{
     static SomeClass const someObject( ID );
     return someObject;
}

removing the const function attribute the bug disappeared...so who's bug is it? ;-D