[PATCH] RFC: PR78905 define _GLIBCXX_RELEASE macro

[Jonathan Wakely]

On 17/01/17 17:16 -0500, Ed Smith-Rowland wrote:
>On 01/17/2017 04:55 PM, Ed Smith-Rowland wrote:
>>On 01/17/2017 12:25 PM, Jonathan Wakely wrote:
>>>As I said in https://gcc.gnu.org/ml/libstdc++/2017-01/msg00109.html
>>>the __GLIBCXX__ macro is useless, but is the closest thing we have to
>>>a version macro for libstdc++. This matters when using libstdc++ with
>>>Clang or Intel icc or other compilers, because you can't check the
>>>__GNUC__ macro. I've seen several requests for a way to check the
>>>libstdc++ version, or complaints that there is no way to do it.
>>>
>>>This patch adds a new _GLIBCXX_RELEASE macro that contains the same
>>>value as __GNUC__ i.e. the major release number.
>>>
>>>- Yes, it only contains the major number. We could in theory have
>>> _GLIBCXX_MAJOR and _GLIBCXX_MINOR instead, but between
>>> _GLIBCXX_RELEASE and __GLIBCXX__ you can identify the release branch
>>> and a date within that branch.
>>>
>>>- The name is "RELEASE" because we used to define _GLIBCXX_VERSION
>>> many years ago, but it was a string literal and this is an integer.
>>> To avoid problems for any old code checking for _GLIBCXX_VERSION I
>>> chose a different name.
>>>
>>>Thoughts?
>>>
>>>
>>>    PR libstdc++/78905
>>>    * include/Makefile.am (_GLIBCXX_RELEASE): Set value.
>>>    * include/Makefile.in: Regenerate.
>>>    * include/bits/c++config (_GLIBCXX_RELEASE): Add #define.
>>>    * testsuite/ext/profile/mutex_extensions_neg.cc: Use lineno of 0 in
>>>    dg-error.
>>>
>>This might stop people from complaining about stub implementations.

Yes, that's one way it could be helpful.

>>It would also help with ABI breaks and as a coarse-grained feature-macro.

Yes, the PR mentioned in the ChangeLog entry above is basically a
request for a feature-test macro for <regex>, but SD-6 doesn't define
macros for C++11 features (because it was written long after 2011 and
most implementations have full C++11 support now anyway).

>>It seems like we'd want to backport this of course.

I'm undecided. Would it still be useful to define _GLIBCXX_RELEASE=6
for the 6.4.0 release, even though it wasn't defined for 6.3.0? Maybe
it would be simpler to only define it from GCC 7 onwards. Or maybe
doing it for 5.5 and 6.4 would still be useful in some cases, even if
not in all cases.

>>Of course you want more feedback from packagers.
>>
>>Ed
>>
>>
>I'm assuming this is really directed at folks who borrow only the 
>library and not the rest of gcc.
>
>Otherwise we could just use the main macro.

Yes, exactly. It's only useful when using libstdc++ with a non-GCC
compiler. That's fairly common, and if we remove this obstacle then
it's slightly easier to do, and there will be a good answer to
questions like:
http://stackoverflow.com/questions/21622561/how-to-detect-the-libstdc-version-in-clang

And Boost wouldn't need to do this for future releases:
https://github.com/boostorg/config/blob/develop/include/boost/config/stdlib/libstdcpp3.hpp#L116
If we backported it then Boost.Config could look for _GLIBCXX_RELEASE
first, and if it finds it use it, otherwise try that __has_include
dance.