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

Subject: Re: [Boost-users] boost::lockfree::queue not working with -fgnu-tm
From: Angelo Mondaini (oangelo_at_[hidden])
Date: 2014-07-17 11:08:06

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_at_[hidden]>:

> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>