[PATCH] RFC: PR78905 define _GLIBCXX_RELEASE macro

[Jonathan Wakely]

On 17/01/17 23:17 +0000, Jonathan Wakely wrote:
>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.

Here's what I'm committing, which also documents the new macro, and
updates the docs for the __GLIBCXX__ and _GLIBCXX_VERSION macros.

Tested powerpc64le-linux, committed to trunk.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 16117 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20170119/256497d5/attachment.bin>