Moritz Klammler | 10 Feb 20:07 2016
Picon

Proof-of-Concept Implementation of D0205

I have implemented my proposal D0205 to allow seeding random number
engines directly with `std::random_device` as in

    std::random_device device {};
    std::mt19937 engine {device};  // note: device passed by-reference
    std::cout << "Here is a very random number: " << engine() << "\n";

for libstdc++.  The paper will be officially submitted to ISO tomorrow
and hopefully be discussed in Jacksonville and ideally accepted for
C++17.  Attached is my patch against libstdc++ SVN revision 233225 and a
quick note how to use it.  You can find the current version of any of
these as well as the final D0205R1 of the paper on my website, too.

    http://klammler.eu/data/computer-science/iso-c++/p0205/

I would be very grateful for a review of my patch.  This is my first
experience with writing standard library code.  By the way, I don't
know how to make the ABI compatibility check pass again, even though
I've read the [ABI Policy and
Guidelines](https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html).

I didn't include a copyright notice in the files because I didn't want
to say that something is by the FSF without being asked to do so.  I
will be happy to fix this once asked for.

Do you have any interest in incorporating this patch into libstdc++?  Is
there a process for merging experimental features that are not
officially standard yet?

Thank you for considering.
(Continue reading)

Jonathan Wakely | 5 Feb 00:49 2016
Picon
Gravatar

[patch] libstdc++/69626 Test for C99 stdlib.h functions with -std=c++98

When r230324 split the GLIBCXX_ENABLE_C99 configure checks to test
everything twice, once with -std=gnu++98 and once with -std=gnu++11,
we failed to check the stdlib.h functions with gnu++98. As a result
_GLIBCXX98_USE_C99_STDLIB was never defined, and so various C99
functions disappeared from namespace std in c++98 mode.

This adds the missing checks back, so those functions are added to
namespace std again.

The new test only runs on *-*-linux-gnu because we can't run it
everywhere, as some targets don't support the functions in C++98 mode
and so correctly don't define _GLIBCXX98_USE_C99_STDLIB. Some other
targets such as freebsd and dragonfly override
_GLIBCXX98_USE_C99_STDLIB in os_defines.h so were unaffected anyway.

Tested powerpc64-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 3217 bytes
Stephan Bergmann | 3 Feb 11:25 2016
Picon

Rationale for cmath's std::abs(short) -> double

I once again wonder why 
<https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=150022> added that

> template<typename _Tp> typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
double>::__type abs(_Tp)

overload to cmath, causing a call to std::abs with an argument of type 
short to return a double, even if cstdlib is also included (which 
declares the int, long, long long overloads).  That commit does not give 
any rationale.

(I apparently wondered about that already a couple of years ago, but all 
I can find now in my notes is "[...] only to discover libstdc++'s 
over-eager interpretation of C++11 cmath requirements causes std::abs 
with a short argument to chose the double overload," which no longer 
rings much of a bell with me.)

This issue happens to crop up again now in the context of the 
LibreOffice code base, see <https://gerrit.libreoffice.org/#/c/22050/> 
"Make abs return int, not double," which reportedly is on Fedora Rawhide.

Andris Pavenis | 26 Jan 05:40 2016
Picon
Picon

[PATCH, libstdc++-v3] Fix import of wide character related symbols in stdlib.h wraper

include/c_compatibility/stdlib.h imports wide character related symbols
into global namespace unconditionaly which causes libstdc++-v3 build
to fail when one or both of _GLIBCXX_USE_WCHAR_T and _GLIBCXX_HAVE_MBSTATE_T
are not defined.

Included patch changes it to import them into global namespace only
when they are defined in cstdlib

Andris

2016-01-26  Andris Pavenis  <andris.pavenis <at> iki.fi>

     * include/c_compatibility/stdlib.h: Include wide character related
     definitions only when they are available in cstdlib.

Jonathan Wakely | 22 Jan 22:15 2016
Picon
Gravatar

[patch] libstdc++/69116 Constrain std::valarray functions and operators

The example in the PR is a sneaky little problem. When <valarray> is
included the following overload is declared:

template<typename _Tp>
_Expr</* here be expression templates */>
operator<<(const _Tp& __t, const valarray<_Tp>& __v);

This is a candidate function for any "a << b" expression with
namespace std as an associated namespace. In order to do overload
resolution valarray<decltype(a)> gets instantiated to see if there is
a conversion from decltype(b). When decltype(a) is an abstract type
valarray<decltype(a)> results in an error outside the immediate
context, and overload resolution stops with an error.

This could happen for any of the overloaded operators and functions
that work with valarray, so my solution is to adjust the __fun<> class
template so that the result type of valarray operations is not defined
for types that cannot be used in valarray.  When the result_type is
missing the valarray operators give a SFINAE deduction failure not a
hard error.

Currently the check is !__is_abstract(_Tp) but it could be tweaked to
also check other conditions that cause a problem.

The new test uses -std=gnu++98 because if it uses a later standard
then it fails due to similar unconstrained operators in <complex>, and
std::complex<T> also fails if is_abstract<T>, so I'll have to fix that
next.

Tested powerpc64-linux, comimtted to trunk.
(Continue reading)

John David Anglin | 17 Jan 19:23 2016
Picon

[committed] Update hppa-linux baseline symbols for gcc-6

The attached change updates the hppa-linux baseline symbols.  Tested on hppa-unknown-linux-gnu.
Committed to trunk.

Dave
--
John David Anglin	dave.anglin <at> bell.net

2016-01-17  John David Anglin  <danglin <at> gcc.gnu.org>

	PR libstdc++/68734
	* config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Update.

Index: config/abi/post/hppa-linux-gnu/baseline_symbols.txt
===================================================================
--- config/abi/post/hppa-linux-gnu/baseline_symbols.txt	(revision 232398)
+++ config/abi/post/hppa-linux-gnu/baseline_symbols.txt	(working copy)
 <at>  <at>  -64,10 +64,13  <at>  <at> 
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE8overflowEi <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE9pbackfailEi <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE9underflowEv <at>  <at> GLIBCXX_3.4.10
+FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC1EOS3_ <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC1EP8_IO_FILE <at>  <at> GLIBCXX_3.4.10
+FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC2EOS3_ <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC2EP8_IO_FILE <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED0Ev <at>  <at> GLIBCXX_3.4.10
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED1Ev <at>  <at> GLIBCXX_3.4.10
+FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEaSEOS3_ <at>  <at> GLIBCXX_3.4.21
 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE4fileEv <at>  <at> GLIBCXX_3.4.2
(Continue reading)

Torvald Riegel | 16 Jan 23:47 2016
Picon

[PATCH] libstdc++: Fix static_assert.

This adds a missing string argument to a call to static_assert, thus not
making it depend on c++1z extensions.  This fixes the build breakage on
mingw introduced in 232454.

Tested on x86_64-linux.  OK?
David Edelsohn | 16 Jan 13:16 2016
Picon
Gravatar

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

This patch broke bootstrap on AIX.  Not all targets support TM.  This
patch makes libstdc++ unconditionally refer to TM symbols.

Please fix.

- David

Jonathan Wakely | 16 Jan 00:12 2016
Picon
Gravatar

[patch] libstdc++/69293 Use static assertion for uses-allocator construction

The PR is actually due to a defect in the standard, which I reported
today. The reporter said we're missing a check for is_constructible<T,
Args..., inner_allocator_type> that would ensure we go to bullet (9.4)
and make the example in the PR ill-formed. I didn't add that check
because it's redundant, we don't need to check is_constructible we can
just try the construction and if it fails the program is ill-formed
anyway.

However, due to the  defect in the standard the example in the PR
*should* be ill-formed, but isn't.  This patch adds a static assertion
making it ill-formed. It would be ill-formed anyway once the defect is
resolved and we implement the resolution, but with the static
assertion we give a better diagnostic, both for
scoped_allocator_adaptor and for ill-formed uses of allocators with
std::tuple.

Tested powerpc64le-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 5555 bytes
Ed Smith-Rowland | 7 Jan 17:50 2016
Picon
Picon
Gravatar

Adding C++ TR29124.

This patch is a clean up of the patch submitted by Jonathan in stage 1.
I am much less ambitious here than I was in previous patches.
I added many new test cases to the Bessel functions to look at the 
uncovered region near.
For TR29124 I moved the hypergeometric functions to __gnu_cxx namespace 
so they are not yanked away
from users.

We don't want to give anyone an excuse to use both TR1 and TR29124 at 
the same time ;-)

Hermite polynomials finally have value tests.
I also test the std:: TR29124
I replicated even the value tests even though currently, tr1 and tr29124 
point to the same implementation.
This will change as soon as stage 1 reopens.

Also, with TR29124 I think we could actually deprecate the tr1 namespace.

This builds and tests clean on x86_64-linux.

OK for stage 3?

On another note, I've staged new TR29124 implementation on a branch:
branches/emsr/gcc_tr29124 or some such.
I am staging new implementations and functions here.

Regards,
Ed

(Continue reading)

Jonathan Wakely | 7 Jan 16:01 2016
Picon
Gravatar

[patch] libstdc++/69105, 69106, 69114 use std::addressof

A bumper crop of addressof bugs where I was using & but should have
used std::addressof.

Tested powerpc64le-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 8 KiB

Gmane