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