[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 15:31:02 2017
New Revision: 248232

URL: https://gcc.gnu.org/viewcvs?rev=248232=gcc=rev
Log:
PR69699 document why __GLIBCXX__ macro is useless

Backport from mainline
2017-01-17  Jonathan Wakely  

PR libstdc++/69699
* doc/xml/manual/abi.xml (abi.versioning.history): Explain why the
_GLIBCXX__ macro is not useful. Remove redundant date information
and link to the GCC release timeline.
(abi.versioning.active): Move partial sentence into the previous
paragraph.
* doc/html/*: Regenerate.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/doc/html/manual/abi.html
branches/gcc-5-branch/libstdc++-v3/doc/xml/manual/abi.xml

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 14:35:12 2017
New Revision: 248210

URL: https://gcc.gnu.org/viewcvs?rev=248210=gcc=rev
Log:
PR69699 document why __GLIBCXX__ macro is useless

Backport from mainline
2017-01-17  Jonathan Wakely  

PR libstdc++/69699
* doc/xml/manual/abi.xml (abi.versioning.history): Explain why the
_GLIBCXX__ macro is not useful. Remove redundant date information
and link to the GCC release timeline.
(abi.versioning.active): Move partial sentence into the previous
paragraph.
* doc/html/*: Regenerate.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/doc/html/manual/abi.html
branches/gcc-6-branch/libstdc++-v3/doc/html/manual/bugs.html
branches/gcc-6-branch/libstdc++-v3/doc/html/manual/status.html
branches/gcc-6-branch/libstdc++-v3/doc/html/manual/using_macros.html
branches/gcc-6-branch/libstdc++-v3/doc/xml/manual/abi.xml

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #9 from Jonathan Wakely  ---
Done.

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue Jan 17 15:26:11 2017
New Revision: 244532

URL: https://gcc.gnu.org/viewcvs?rev=244532=gcc=rev
Log:
PR69699 document why __GLIBCXX__ macro is useless

PR libstdc++/69699
* doc/xml/manual/abi.xml (abi.versioning.history): Explain why the
_GLIBCXX__ macro is not useful. Remove redundant date information
and link to the GCC release timeline.
(abi.versioning.active): Move partial sentence into the previous
paragraph.
* doc/html/*: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/html/manual/abi.html
trunk/libstdc++-v3/doc/xml/manual/abi.xml

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-17
 Ever confirmed|0   |1

--- Comment #7 from Jonathan Wakely  ---
You can look at https://gcc.gnu.org/develop.html#timeline for the release dates
which are used for the values for __GLIBCXX__ in GCC 4.1.0 and later.

I'm updating the docs to explain why __GLIBCXX__ is not useful.

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

--- Comment #6 from Jonathan Wakely  ---
There is no such macro.

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[bastian.beisc...@rwth-aachen.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

--- Comment #3 from bastian.beisc...@rwth-aachen.de ---
Jonathan, maybe so but it should be mentioned on the page nevertheless, right?

My issue is that we are using (as an example):

#if (defined(__GLIBCXX__) && __GLIBCXX__ > 20150626) ||
(defined(_LIBCPP_VERSION) && _LIBCPP_VERSION >= 1101)
static_assert(std::is_trivially_constructible::value, "MyClass should
be trivially constructible.");
#endif

since "std_is_trivially_constructible" exists only in libstdc++ shipped with
GCC 5.1.0+, but not in libstdc++ shipped with GCC 4.9.3, for example.

If i understand your comment correctly you are saying that, if GCC 4.9.4 were
released, it would include a version of libstdc++ with __GLIBCXX__ > today, so
it would pass the above check, but still there would't be any
"std_is_trivially_constructible".

But how else can I do the check then?! Using __GNUC__ / __GNUC_MINOR__ is not
going to work because we have people using other compilers (clang, Intel
compiler) which use libstdc++ shipped with GCC but do not define __GNUC__ /
__GNUC_MINOR__.

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[bastian.beisc...@rwth-aachen.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

--- Comment #5 from bastian.beisc...@rwth-aachen.de ---
Thanks for your comments. Does this mean that such a macro does not exist at
the present time?

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

--- Comment #4 from Jonathan Wakely  ---
(In reply to bastian.beischer from comment #3)
> Jonathan, maybe so but it should be mentioned on the page nevertheless,
> right?

Yes, although I plan to deprecate that macro.

> My issue is that we are using (as an example):
> 
> #if (defined(__GLIBCXX__) && __GLIBCXX__ > 20150626) ||
> (defined(_LIBCPP_VERSION) && _LIBCPP_VERSION >= 1101)
> static_assert(std::is_trivially_constructible::value, "MyClass
> should be trivially constructible.");
> #endif
> 
> since "std_is_trivially_constructible" exists only in libstdc++ shipped with
> GCC 5.1.0+, but not in libstdc++ shipped with GCC 4.9.3, for example.
>
> If i understand your comment correctly you are saying that, if GCC 4.9.4
> were released, it would include a version of libstdc++ with __GLIBCXX__ >
> today, so it would pass the above check, but still there would't be any
> "std_is_trivially_constructible".

Exactly. GCC 4.9.4 definitely will be released, and when it is your check will
not work. Someone could even use a version of GCC 4.9.3 built from the
gcc-4_9-branch in subversion, and your check would fail today.

> But how else can I do the check then?! Using __GNUC__ / __GNUC_MINOR__ is
> not going to work because we have people using other compilers (clang, Intel
> compiler) which use libstdc++ shipped with GCC but do not define __GNUC__ /
> __GNUC_MINOR__.

We need a macro that actually reflects the version of the library, not one that
refers to the almost meaningless release date.

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

--- Comment #2 from Jonathan Wakely  ---
That macro is fairly useless.

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[bastian.beisc...@rwth-aachen.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699

--- Comment #1 from bastian.beisc...@rwth-aachen.de ---
This is a list of all the missing values of the __GLIBCXX__ macro

4.7.3 20130411
4.7.4 20140612
4.8.0 20130322
4.8.1 20130531
4.8.2 20131016
4.8.3 20140522
4.8.4 20141219
4.8.5 20150623
4.9.0 20140422
4.9.1 20140716
4.9.2 20141030
4.9.3 20150626
5.1.0 20150422
5.2.0 20150716
5.3.0 20151204

obtained with the following zsh script:

#!/usr/bin/env zsh

VERSIONS=( 4.7.3
   4.7.4
   4.8.0
   4.8.1
   4.8.2
   4.8.3
   4.8.4
   4.8.5
   4.9.0
   4.9.1
   4.9.2
   4.9.3
   5.1.0
   5.2.0
   5.3.0 )

rm -f allversions.txt
for v in ${VERSIONS}; do
  wget
ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-${v}/gcc-${v}.tar.bz2
  tar xjvf gcc-${v}.tar.bz2 --wildcards "gcc-${v}/gcc/DATESTAMP"
  version=$(cat gcc-${v}/gcc/DATESTAMP)
  echo ${v} ${version} >> allversions.txt
  rm -fr gcc-${v}*
done