François Dumont | 30 Jun 22:25 2015
Picon

max_load_factor constant complexity

Hi

    During a recent discussion on Reflector about max_load_factor some
pointed that libstdc++ has not the constant complexity as imposed by the
Standard in Table 103 because we try to respect the new factor by
potentially rehashing the container. This patch fix this problem by
adopting VS Standard Library behavior of retaining the targeted
max_load_factor and comply to it as soon as possible on insertion.

    * include/bits/hashtable.h (_Hashtable<>::__rehash_policy): Remove
    container rehash.
    * testsuite/23_containers/unordered_set/max_load_factor/robustness.cc:
    Adapt.

Tested under linux x86_64.

Ok to commit ?

François

Jonathan Wakely | 30 Jun 15:36 2015
Picon

[patch] Use template<typename> not template<class> in std::pair

An unimportant change to meet our usual convention.

Tested powerpc64le-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 8 KiB
Jonathan Wakely | 26 Jun 22:38 2015
Picon

time_get<>::get_year() reading fewer than four digits

Our get_year() function parses two digits as 19NN, which might be
reasonable if you believe that no sane person uses two-digit years
nowadays, so two-digit years must come from ye olde data files from
last millennium. An alternative would be to follow POSIX (as Visual
C++ and libc++ do) and treat [00,68] as 20NN and [69,99] as 19NN.
Another alternative would be to simply assume the current century, so
20NN.

It parses three digits as a two-digit year that overflows the maximum
value of 99, so the result is 1999 and failbit is set. That's arguably
not very useful, and makes it impossible to parse years such as 325
AD, although maybe only the Vatican would notice that problem.

At the very least we need to document our implementation-defined
semantics for two-digit years. We might also want to change how we
handle fewer than four digits. I think there's an LWG issue on the
way, so we can wait and see what LWG decides is the right behaviour.

Jonathan Wakely | 26 Jun 12:33 2015
Picon

RFC: Add _GLIBCXX_NOEXCEPT_C macro for conditional noexcept

I keep considering making this change:

--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
 <at>  <at>  -117,10 +117,12  <at>  <at> 
 #  define _GLIBCXX_NOEXCEPT noexcept
 #  define _GLIBCXX_USE_NOEXCEPT noexcept
 #  define _GLIBCXX_THROW(_EXC)
+#  define _GLIBCXX_NOEXCEPT_C(_CONSTANT) noexcept(_CONSTANT)
 # else
 #  define _GLIBCXX_NOEXCEPT
 #  define _GLIBCXX_USE_NOEXCEPT throw()
 #  define _GLIBCXX_THROW(_EXC) throw(_EXC)
+#  define _GLIBCXX_NOEXCEPT_C(_CONSTANT)
 # endif
 #endif

It would allow code like this:

    basic_string()
  #if __cplusplus >= 201103L
    noexcept(is_nothrow_default_constructible<_Alloc>::value)
  #endif

to be replaced with this:

    basic_string()
    _GLIBCXX_NOEXCEPT_C(is_nothrow_default_constructible<_Alloc>::value)

But I can't decide if that's really an improvement.
(Continue reading)

François Dumont | 20 Jun 12:03 2015
Picon

Do not take address of empty string front

Hi

    2 experimental tests are failing in debug mode because
__do_str_codecvt is sometimes taking address of string front() and
back() even if empty. It wasn't use so not a big issue but it still
seems better to avoid. I propose to rather use string begin() to get
buffer address. I kept operator& as it is what was used, do you think we
should use addressof ?

    At the same time I improve string debug mode cause with front()
implemented as operator[](0) it is ok even if string is empty while
back() implemented as operator[](size()-1) is not which is quite
inconsistent. So I added a number of !empty() checks in several methods
to detect more easily all those invalid usages.

    * include/bits/basic_string.h (basic_string<>::front()): Add !empty
    debug check.
    (basic_string<>::back()): Likewise.
    (basic_string<>::pop_back()): Likewise.
    * include/bits/locale_env.h (__do_std_codecvt): Do not take address of
    string::front() when string is empty.
    * include/debug/macros.h
    (__glibcxx_check_string, __glibcxx_check_string_len): Implement using
    _GLIBCXX_DEBUG_PEDASSERT.

Tested under Linux x86_64 debug mode.

Ok to commit ?

François
(Continue reading)

Jonathan Wakely | 19 Jun 15:07 2015
Picon

What is GLIBCXX_ENABLE_PARALLEL for?

acinclude.m4 has:

dnl
dnl Check for parallel mode pre-requisites, including OpenMP support.
dnl
dnl  +  Usage:  GLIBCXX_ENABLE_PARALLEL
dnl
AC_DEFUN([GLIBCXX_ENABLE_PARALLEL], [

  enable_parallel=no;

  # See if configured libgomp/omp.h exists. (libgomp may be in
  # noconfigdirs but not explicitly disabled.)
  if echo " ${TARGET_CONFIGDIRS} " | grep " libgomp " > /dev/null 2>&1 ; then
    enable_parallel=yes;
  else
    AC_MSG_NOTICE([target-libgomp not built])
  fi

  AC_MSG_CHECKING([for parallel mode support])
  AC_MSG_RESULT([$enable_parallel])
])

Which is called from configure.ac (with an unused argument):

GLIBCXX_ENABLE_PARALLEL([yes])

What's the point?

It doesn't seem to have any side effects except printing some messages
(Continue reading)

Jonathan Wakely | 16 Jun 23:05 2015
Picon

[patch] Make std::list safe against overloaded operator&

This fixes some unsafe uses of operator& in std::list, and also in
Debug Mode found running the new test with -D_GLIBCXX_DEBUG.

Tested powerpc64le-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 10 KiB
Fan You | 15 Jun 04:22 2015
Picon

Fwd: [PATCH][GSoC] Extend shared_ptr to support arrays

---------- Forwarded message ----------
From: Fan You <youfan.noey <at> gmail.com>
Date: 2015-06-14 23:45 GMT+08:00
Subject: Re: [PATCH][GSoC] Extend shared_ptr to support arrays
To: Jonathan Wakely <jwakely <at> redhat.com>
Cc: Tim Shen <timshen <at> google.com>, gcc-patches
<gcc-patches <at> gcc.gnu.org>, libstdc++ <libstdc++ <at> gcc.gnu.org>

This is the revised patch.

Bootstrapped and Tested on Darwin 10.9.4. with testsuite 20_util/*

Alternatively:

__shared_ptr<libfund<_Tp>> : private __shared_ptr<std::remove_extent<_Tp>>

to prevent changing everything once __shared_ptr<_Tp> has changed.

Any advice?

2015-06-12 17:04 GMT+08:00 Jonathan Wakely <jwakely <at> redhat.com>:
>
> On 11/06/15 23:43 -0700, Tim Shen wrote:
>>
>> +      using element_type = _Tp[N];
>>
>> using element_type = typename std::remove_extent_t<_Tp>; ?
>
>
> Well at that point in the file we're inside the
(Continue reading)

Jonathan Wakely | 12 Jun 14:27 2015
Picon

[patch] Add missing C++11 and C++14 headers to bits/stdc++.h

<codecvt> and <shared_mutex> were not included in the precompiled
headers.

Tested powerpc64le-linux, committed to trunk.
Attachment (patch.txt): text/x-patch, 746 bytes
Jonathan Wakely | 12 Jun 01:22 2015
Picon

[patch] Fix two libstdc++ test failures with -std=gnu++14

This fixes two test failures when the default compiler mode is
-std=gnu++14

FAIL: 25_algorithms/headers/algorithm/synopsis.cc (test for excess errors)
FAIL: ext/profile/mutex_extensions_neg.cc (test for excess errors)

I don't really like the change to the synopsis.cc test, but I don't
think reproducing the SFINAE constraints in the test is ideal either.

The mutex_extensions_neg.cc test works now, but I think we're missing
specializations of __is_tuple_like_impl for __gnu_debug::array and
__gnu_profile::array.

Tested powerpc64le-linux, committed to trunk.

Attachment (patch.txt): text/x-patch, 1737 bytes
Jonathan Wakely | 11 Jun 18:15 2015
Picon

Re: [PATCH][GSoC] Extend shared_ptr to support arrays

On 11/06/15 23:32 +0800, Fan You wrote:
>Hi,
>
>This is my first patch for GSoC project: extend shared_ptr to support
>arrays.
>
>Changes are made in these files:
>
>* libstdc++-v3/include/bits/shared_ptr_base.h : Renamed _Sp_counted_deleter
>to _Sp_counted_array, changed _shared_count construct from _Sp_counted_ptr
>to _Sp_counted_array.

Why?

As far as I can see it has nothing to do with arrays.

>* libstdc++-v3/include/experimental/memory : add shared_ptr into
>fundamentals_v1
>
>Is it too long for reviewing? Should I detach them into different patches?
>Any comments?

General comments:

Please fix the lines that consist of nothing but whitespace, they
should just be empty lines.

You're going to need tests!

Comments on changes to include/bits/shared_ptr_base.h:
(Continue reading)


Gmane