[Bug libstdc++/81950] _GLIBCXX17_INLINE macro not used consistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81950 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #2 from TC --- Unless I'm mistaken, the practice is to use _GLIBCXX17_INLINE on things in C++ <= 14 that are newly made inline in C++17. in_place is new in C++17.
[Bug libstdc++/81950] _GLIBCXX17_INLINE macro not used consistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81950 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #3 from Daniel Krügler --- (In reply to Judy Ward from comment #1) > In the comment above I meant to say the line should be changed to: > > _GLIBCXX17_INLINE constexpr in_place_t in_place{}; TC's guess is correct. The omission is intentionally, because the macro is designed to be used in contexts which are unaware of the actual C++ version and in_place_t was introduced with C++17, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0504r0.html and some papers related to std::optional in-place construction. The surrounding #ifdef block of the variable definition you are complaining about is only available since C++17.
[Bug libstdc++/81950] _GLIBCXX17_INLINE macro not used consistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81950 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- The explanations above are correct. We could do something here dependent on __cpp_inline_variables >= 201606, if that helps other compilers, but using _GLIBCXX17_INLINE isn't the right fix (that should always be defined when __cplusplus > 201402L, so if the Intel compiler is undefining it you should stop doing that, and work with us to support your copiler properly). I'd entertain patches to do that, but am unlikely top find time to do so myself.