The problem seems to be the combination of -fgnu-tm and any -O flag. It doesn't compile for -O1 or -O2, as well. -O0 works. Can you confirm that? Has anybody ever experienced this before and knows a workaround? Maybe I should open a bug report. On 07/15/2014 11:47 PM, Angelo Mondaini wrote:

I also use Archlinux, I have tested your code. Indeed, with all the flags you are trying, gcc can't compile. To me, the problem is the flag "-O3", removing it gcc can compile the code, no problem. Note that "-O3" are very wild optimizations, it can makes the code slower some times and it can even break the code. Careful when using it.

HTH, Angelo

2014-07-15 12:09 GMT-03:00 Philipp Schoppe mailto:philipp.schoppe@cern.ch>:

Hello,

I try to benchmark different queue implementations. I have a test program which includes the boost lockfree queue and some custom implementations where one is using gcc's STM. In order to compile it, I need to add the -fgnu-tm flag. I am using an up-to-date arch linux system with gcc 4.9.0 and boost 1.55.0 When adding this flag, I get a compilation error. This is a small example that illustrates the problem:

errtest.cpp:

#include

int main () {

boost::lockfree::queue<int> lfqueue; lfqueue.push(234);

return 0; }

Compiling it using

g++ -std=c++11 -lboost_system -g -O3 -Wall -Werror -Wswitch-enum -fgnu-tm errtest.cpp -o test

leads to an error.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org mailto:Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

On Wednesday, July 16, 2014 09:37 PM, Angelo Mondaini wrote:

Yes, same here! As far as I know, "-O3" or "-O2" tries to optimize the memory usage and binary size. However, "-fgnu-tm" also deals with the memory, so, this seems like compatibility problem with both flags. Note that gcc manual for "-fgnu-tm" says: "This is an experimental feature ...". And "-O3" flag includes very aggressive optimizations, sometimes it can fail by it own. I think a bug report would be a good option...

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. Ben

On Thursday, July 17, 2014 11:08 PM, Angelo Mondaini wrote:

2014-07-16 12:46 GMT-03:00 Ben Pope mailto:benpope81@gmail.com>:

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