Re: [lmi] libstdc++ anomaly? [was: MinGW-w64 anomaly?]

[Vadim Zeitlin]

On Sun, 18 Dec 2016 22:18:07 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-12-18 20:54, Vadim Zeitlin wrote:
... my analysis of the problem ...
GC> Then the anomaly really is upstream, in libstdc++.

 Sorry, it seems my analysis wasn't 100% correct. I was told in the bug
report[*] that gcc is smart enough to use a more efficient version of
__builtin_powl(), which is always used in C++11 mode because the overloads
for int exponent are disabled, when the exponent is a _literal_ integer.
However it's not smart enough to do it for an integer variable. So the
explanation for what happens in our case is still the same, but "our case"
is even more narrow than I thought, which explains why gcc people are not
really interested in spending resources on fixing it.

 BTW, another thing that I thought about while discussing this: the -flto
option also came up and I wrote that it indeed allowed the compiler to
compute the result at compile-time in this simple example, but that this
wouldn't work in the real program. However now I'm not so sure: if you're
using pow() just to build the cache of the powers of 10 for not too many
exponents, wouldn't gcc be indeed smart enough to precompute all of them at
compile-time? Of course, lmi doesn't use LTO currently, but perhaps it
could be worth testing turning it on and checking how it affects the
performance? We can clearly see that it allows for impressive optimizations
in simple examples and while nothing guarantees that it would be also the
case in real code, it might be worth trying it out.

 Regards,
VZ

[*] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851