compared to C++03 with gcc 5.x or 6.x.

May be related: About a year ago I wrote a constexpr-string library for myself. The idea was to provide string manipulation functions like search, replace, etc at compile time. This would then allow me to build and express SQL queries in type-safe code and tie them to program logic (i.e. the queries could be expressed as chains of constexpr functions). I was testing on apple clang. Initially all went well. Intermediate strings where never produced in the assembler output and when the compiler needed the address of the resulting string, it would place the parts of the resulting string in data sections. Perfect. Then I tested with gcc. This was a disaster. Whenever a constexpr string was used, the compiler would build it on the stack, explicitly initialising it. I actually found that gcc produced better code when string literals were static const and not constexpr. What I took away from this was either, 1. I was pushing beyond the intended boundaries of constexpr and clang was just happy to oblige, or 2. gcc's code generation involving constexpr objects is a little suspect. On 2 January 2018 at 09:24, Hans Dembinski via Boost wrote:

Hi John,

...

On 31. Dec 2017, at 20:50, John Maddock via Boost wrote:

Folks I have a very strange issue that I need help with understanding, it comes from https://github.com/boostorg/multiprecision/issues/32 but in summary:

...

There is a 20-30% slowdown when compiled in C++11 or later compared to C++03 with gcc 5.x or 6.x.

I am not able to answer you, I just also want to say it is weird. I thought that making things constexpr should not change run-time code emitted by the compiler at all.

Best regards, Hans

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost