See this link, the "Known problems" section may help:
http://pmarlier.free.fr/gcc-tm-tut.html

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.

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

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

HTH,
Angelo


2014-07-16 12:46 GMT-03:00 Ben Pope <benpope81@gmail.com>:
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


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