Re: [Boost-users] boost::lockfree::queue not working with -fgnu-tm

Subject: Re: [Boost-users] boost::lockfree::queue not working with -fgnu-tm
From: Ben Pope (benpope81_at_[hidden])
Date: 2014-07-17 21:37:28

On Thursday, July 17, 2014 11:08 PM, Angelo Mondaini wrote:
> 2014-07-16 12:46 GMT-03:00 Ben Pope <benpope81_at_[hidden]
> <mailto:benpope81_at_[hidden]>>:
>
>     According to the docs:
>
>     -O2 is "full optimisation"
>     -O3 is "full optimisation with more aggressive inlining and
>     vectorisation"
>
>     That's a strange description that's possibly no longer true.
>
>     I don't think either of them optimise for memory or binary size,
>     more for speed (specifically at the expense of binary and memory size).
>
>     I also don't think either of them "fail by its own", modulo compiler
>     bugs.
>
>     This idea that high optimisation levels produce incorrect code is
>     strange to me.  From what I've seen, aggressive optimisations are
>     more likely to highlight undefined behaviour, but code that relies
>     on undefined behaviour is broken code.  The compiler doesn't break
>     correct code, it trusts what you tell it.
>
>     So please, can we stop the FUD and just get on with a fix; either in
>     the library or the compiler, for technical or practical reasons.
>
>
> See this link, the "Known problems" section may help:
> 	

I only took a quick look, that article is around 2 years old, does 
gcc-4.9 suffer the same problem?

> The thing about "aggressive optimisations are more likely to highlight
> undefined behaviour" is true if your compiler is perfect, and this may
> be almost true for well established compiler features, I don't believe
> this is the case of "-fgnu-tm", "-O3" or even "-std=c++11".
> That is why this is not enabled by default.

Well, I did say modulo bugs. Of course, there might be bugs in the C++03 
code or unoptimised code generation paths of a particular compiler.

> Look what Gentoo's wiki says about "-O3":
> "-O3: This is the highest level of optimization possible. It enables
> optimizations that are expensive in terms of compile time and memory
> usage. Compiling with -O3 is not a guaranteed way to improve
> performance, and in fact in many cases can slow down a system due to
> larger binaries and increased memory usage. -O3 is also known to break
> several packages. Therefore, using -O3 is not recommended."

Breaking a package probably means the package invokes UB.  Given that 
those packages haven't been fixed, -O3 is unwise for a system-wide 
compile flag, but that shouldn't scare you into not using it for code 
that doesn't invoke UB or assuming the compiler just generates garbage.

> Because of this, I am not sure the code is the problem or the only problem.

Right, so a technical fix of the code, or a practical workaround of a 
popular but broken compiler are useful.

Ben