On 11/09/2015 15:23, Jonathan Wakely wrote:
> On 11/09/15 14:18 +0100, Jonathan Wakely wrote:
>> On 11/09/15 15:11 +0200, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 10 Sep 2015, François Dumont wrote:
>>>
>>>>Here is a patch to offer
On 05/09/2015 23:02, François Dumont wrote:
> On 22/08/2015 14:24, Daniel Krügler wrote:
>> 2015-08-21 23:11 GMT+02:00 François Dumont <frs.dum...@gmail.com>:
>>> I think I found a better way to handle this problem. It is c++locale.cc
>>> that needs to be built w
On 16/09/2015 22:29, Jonathan Wakely wrote:
>
>>>
constexpr bool __move_storage =
_Alloc_traits::_S_propagate_on_move_assign()
|| _Alloc_traits::_S_always_equal();
@@ -778,7 +779,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*/
On 15/09/2015 23:57, Jonathan Wakely wrote:
> On 14/09/15 20:26 +0200, François Dumont wrote:
>> On 08/09/2015 22:47, François Dumont wrote:
>>> On 07/09/2015 13:03, Jonathan Wakely wrote:
>>>> On 05/09/15 22:53 +0200, François Dumont wrote:
>>>>>
On 14/09/2015 21:50, Jonathan Wakely wrote:
> On 14/09/15 20:27 +0200, François Dumont wrote:
>> Hi
>>
>>Here is what I had in mind when talking about moving debug checks to
>> the lightweight debug checks.
>
> Ah yes, I hadn't thought about removing reund
Hi
Here is what I had in mind when talking about moving debug checks to
the lightweight debug checks.
Sometimes the checks have been simply moved resulting in a simpler
debug vector implementation (front, back...). Sometimes I copy the
checks in a simpler form and kept the debug one too
On 08/09/2015 22:47, François Dumont wrote:
> On 07/09/2015 13:03, Jonathan Wakely wrote:
>> On 05/09/15 22:53 +0200, François Dumont wrote:
>>>I remember Paolo saying once that we were not guarantiing any abi
>>> compatibility for debug mode. I haven't found any
On 11/09/2015 15:23, Jonathan Wakely wrote:
> On 11/09/15 14:18 +0100, Jonathan Wakely wrote:
>> On 11/09/15 15:11 +0200, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 10 Sep 2015, François Dumont wrote:
>>>
>>>>Here is a patch to offer
Hi
Here is a patch to offer an alternative hash policy. This one is
using power of 2 number of buckets allowing a faster modulo operation.
This is obvious when running the performance test that I have adapted to
use this alternative policy. Something between current implementation
and the tr1
On 07/09/2015 20:27, Jonathan Wakely wrote:
> This patch adds the "debug mode lite" we've been talking about, by
> changing __glibcxx_assert to be activated by _GLIBCXX_ASSERTIONS
> instead of _GLIBCXX_DEBUG (and making the latter imply the former).
>
> _GLIBCXX_ASSERTIONS is already used in
On 07/09/2015 13:03, Jonathan Wakely wrote:
> On 05/09/15 22:53 +0200, François Dumont wrote:
>>I remember Paolo saying once that we were not guarantiing any abi
>> compatibility for debug mode. I haven't found any section for
>> unversioned symbols in gnu.ver so I simply
Hi
I wanted to enhance line wrapping during rendering of debug messages
and ended up with this patch.
I clean up _Error_formatter of all useless symbols, only _M_message
and _M_error need to be exposed. Additional I got rid of the ugly
mutable fields of _Error_formatter.
On 22/08/2015 14:24, Daniel Krügler wrote:
> 2015-08-21 23:11 GMT+02:00 François Dumont <frs.dum...@gmail.com>:
>> I think I found a better way to handle this problem. It is c++locale.cc
>> that needs to be built with --fimplicit-templates. I even think that the
>>
On 05/08/2015 22:57, Jonathan Wakely wrote:
On 30/07/15 21:57 +0200, François Dumont wrote:
It seems that this patch results in unresolved symbols.
I am quite sure that the code is right but build system should be
adapted.
I noticed that *_cow.cc files are built with -fimplicit-templates. I
On 01/08/2015 02:25, Jonathan Wakely wrote:
On 31 July 2015 at 20:49, François Dumont wrote:
On 30/07/2015 12:30, Jonathan Wakely wrote:
On 29/07/15 22:08 +0200, François Dumont wrote:
Standard algos signatures are such that there is no guaranty that
the operator or predicate to compare
On 30/07/2015 12:30, Jonathan Wakely wrote:
On 29/07/15 22:08 +0200, François Dumont wrote:
Hi
Here is a patch to add irreflexive debug check.
Awesome!
You can add PR libstdc++/60519 to the changelog.
Sure.
Standard algos signatures are such that there is no guaranty
is welcome.
François
On 27/07/2015 22:30, François Dumont wrote:
Hi
This is the patch to get rid of the duplication of the get_catalogs
functions in the .so.
I used c++locale_internal.h that seems to be there for this kind of
purpose.
* config/locale/gnu/messages_members.cc
Hi
Here is a patch to add irreflexive debug check.
Standard algos signatures are such that there is no guaranty that
the operator or predicate to compare the iterator value type will
exist. So I had to check if the call is valid using C++11 features
declval and decltype.
*
Hello
There are at the moment several failures in the libstdc++ testsuite
when run in debug mode (_GLIBCXX_DEBUG). This is so because debug
assertions are not const expressions. Several debug assertions have been
removed because of this issue.
So is there a way to define a function as to
Hi
This is the patch to get rid of the duplication of the get_catalogs
functions in the .so.
I used c++locale_internal.h that seems to be there for this kind of
purpose.
* config/locale/gnu/messages_members.cc (Catalog_info, Catalogs):
Move...
*
.
2015-07-05 François Dumont fdum...@gcc.gnu.org
* include/bits/stl_algobase.h (__miter_base): Move...
* include/bits/cpp_type_traits.h: ...here.
* include/debug/functions.h (__foreign_iterator_aux): Use latter.
* testsuite/23_containers/vector/debug/insert7_neg.cc: New.
Tested
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
Hello
Is this one ok ?
François
On 12/06/2015 19:11, François Dumont wrote:
Hi
This is a patch to:
- Enhance __get_distance to get a better feedback about distance between
iterators so that we can take sharper decision about what is right or
not. This function is now aware about
On 22/06/2015 17:10, Jonathan Wakely wrote:
On 20/06/15 12:59 +0100, Jonathan Wakely wrote:
On 20/06/15 12:03 +0200, François Dumont wrote:
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
On 22/06/2015 17:10, Jonathan Wakely wrote:
On 20/06/15 12:59 +0100, Jonathan Wakely wrote:
On 20/06/15 12:03 +0200, François Dumont wrote:
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
On 16/06/2015 22:45, Jonathan Wakely wrote:
On 16/06/15 22:18 +0200, François Dumont wrote:
On 12/06/2015 01:22, Jonathan Wakely wrote:
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
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
Hi
This is a patch to:
- Enhance __get_distance to get a better feedback about distance between
iterators so that we can take sharper decision about what is right or
not. This function is now aware about safe iterators and leverage on
those a little like std::distance does with C++ 11
On 04/06/2015 14:41, Jonathan Wakely wrote:
On 03/06/15 21:56 +0200, François Dumont wrote:
Hi
Here is a patch to add heterogeneous lookup to alternative modes.
Excellent.
To do so I had to expose __is_transparent as __has_is_transparent to
avoid confilct with existing __is_transparent
Hi
Here is a patch to add heterogeneous lookup to alternative modes.
To do so I had to expose __is_transparent as __has_is_transparent to
avoid confilct with existing __is_transparent. Should I put it in
__detail namespace ?
* include/bits/stl_tree.h (_Rb_tree::__is_transparent):
On 01/06/2015 22:09, Jonathan Wakely wrote:
On 01/06/15 22:04 +0200, François Dumont wrote:
Hi
I can't find how to fix 61347 for alternative modes. I started
with debug mode by providing a forward declaration for safe iterator
type which return to the __distance on normal iterator but gcc
On 25/05/2015 20:41, Jonathan Wakely wrote:
On 25/05/15 15:31 +0200, François Dumont wrote:
Hi
This is a patch to clean the debug mode code.
I have introduced a new debug header, assertions.h, so that
headers that only need _GLIBCXX_DEBUG_ASSERT do not have to include
the big debug.h
?
2015-02-19 François Dumont fdum...@gcc.gnu.org
* include/debug/debug.h ([_GLIBCXX_DEBUG_ASSERT,
_GLIBCXX_DEBUG_PEDASSERT, _GLIBCXX_DEBUG_ONLY]): Move definition...
* include/debug/assertions.h: ...here, new.
* include/debug/formatter.h
(struct _Error_formatter
On 29/04/2015 17:22, Jonathan Wakely wrote:
I think this covers all the places in the library where we do:
++i, ++j
Tested powerpc64le-linux, committed to trunk.
I just committed 2 missing places in debug mode.
2015-05-23 François Dumont fdum...@gcc.gnu.org
PR libstdc++/64657
On 23/05/2015 13:19, François Dumont wrote:
On 29/04/2015 17:22, Jonathan Wakely wrote:
I think this covers all the places in the library where we do:
++i, ++j
Tested powerpc64le-linux, committed to trunk.
I just committed 2 missing places in debug mode.
2015-05-23 François Dumont fdum
On 20/05/2015 12:19, Jonathan Wakely wrote:
On 20/05/15 11:17 +0100, Jonathan Wakely wrote:
On 04/05/15 22:31 +0200, François Dumont wrote:
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message
On 03/05/2015 22:19, François Dumont wrote:
On 30/04/2015 13:18, Jonathan Wakely wrote:
On 30/04/15 10:40 +0200, François Dumont wrote:
On 27/04/2015 13:55, Jonathan Wakely wrote:
(Alternatively, could the same simplification be made for
__miter_base? Do we need _Miter_base or just two
Hello
Is it ok ?
François
On 04/05/2015 22:31, François Dumont wrote:
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3
Ok, I just commit fixing some other lines length except those having a
long hyperlink, I didn't want to break those.
François
On 16/05/2015 21:32, Jonathan Wakely wrote:
On 16/05/15 11:39 +0200, François Dumont wrote:
On 14/05/2015 15:47, Jonathan Wakely wrote:
Reported by Nathan and fixed
On 14/05/2015 15:47, Jonathan Wakely wrote:
Reported by Nathan and fixed by his patch. I added the tests.
Tested powerpc64le-linux, committed to trunk. This should be
backported too.
While backporting to debug and profile mode I noticed that those
constructors were not the only missing ones.
My proposal should be consider out of any context. We don't know
what std::hash is used for in user code, this is why I am proposing this
patch even if for the moment it doesn't make any difference considering
only our usage of it.
Your remark would make more sens if we were talking
On 08/05/2015 10:02, Richard Biener wrote:
On Wed, May 6, 2015 at 10:10 PM, François Dumont frs.dum...@gmail.com wrote:
Hi
Following Marc Glisse comment #4
on:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65641 I would like to
propose this enhancement to the hash functor for pointers
in quality.cc is very basic and just reflect
enhancement following Marc's comment.
2015-05-05 François Dumont fdum...@gcc.gnu.org
* include/bits/functional_hash.h
(std::__detail::_Lowest_power_of_twosize_t): New.
(std::hash_Tp*::operator()): Use latter.
* testsuite/20_util/hash/quality.cc
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/debug/functions.h:213:
error: function requires a valid iterator
On 30/04/2015 13:18, Jonathan Wakely wrote:
On 30/04/15 10:40 +0200, François Dumont wrote:
On 27/04/2015 13:55, Jonathan Wakely wrote:
(Alternatively, could the same simplification be made for
__miter_base? Do we need _Miter_base or just two overloads of
__miter_base()?)
Definitely, I
On 27/04/2015 13:55, Jonathan Wakely wrote:
On 22/04/15 22:10 +0200, François Dumont wrote:
Hello
I don't know if I am missing something but I think __niter_base
could be simplified to remove usage of _Iter_base. Additionally I
overload it to also remove __normal_iterator layer even
Hello
Here is a rather trivial patch, just code cleanup. Since we export
_Prime_rehash_policy we do not need to expose the _S_n_primes anymore.
* include/bits/hashtable_policy.h (_Prime_rehash_policy::_S_n_primes):
Delete.
* src/c++11/hashtable_c++0x.cc
Hello
I don't know if I am missing something but I think __niter_base
could be simplified to remove usage of _Iter_base. Additionally I
overload it to also remove __normal_iterator layer even if behind a
reverse_iterator or move_iterator, might help compiler to optimize code,
no ? If
With the patch this time.
On 22/04/2015 21:39, François Dumont wrote:
Hello
Here is a rather trivial patch, just code cleanup. Since we export
_Prime_rehash_policy we do not need to expose the _S_n_primes anymore.
* include/bits/hashtable_policy.h
(_Prime_rehash_policy
On 18/03/2015 19:16, Jonathan Wakely wrote:
Preparing this patch reminded me that we currently have two copies of
the Catalog_info and Catalogs code in the unnamed namespace in
config/locale/gnu/messages_members.cc, one using the old string and
one using the new. We should really alter the code
On 20/02/2015 14:22, Jonathan Wakely wrote:
On 18/02/15 10:35 +0100, François Dumont wrote:
Hello
I am still studying hashtable performances and especially how to
reduce overhead compared to tr1 implementation. Most of the overhead
is coming from the additional modulo operations required
:
Container:std::unordered_mapint,int Key:int
Insertion: 1099 581 583 584 592 min=581 max=1099
Container:std::tr1::unordered_mapint,int Key:int
Insertion: 889 491 519 492 493 min=491 max=889
I prefer to propose it now because it impacts ABI.
2015-02-19 François Dumont fdum...@gcc.gnu.org
With patch.
On 18/02/2015 10:35, François Dumont wrote:
Hello
I am still studying hashtable performances and especially how to
reduce overhead compared to tr1 implementation. Most of the overhead
is coming from the additional modulo operations required with the new
data model. Having
wanted to make something like in bits/map.h to
not have to replicate the __is_transparent stuff. But I didn't found any
way to do such a thing.
2015-01-22 François Dumont fdum...@gcc.gnu.org
* include/bits/stl_tree.h (_Rb_tree::__is_transparent): Move to
outer
scope and rename
that it is not using enable_if, IMHO it makes
the code clearer. Here is a proposal to use both extended to the debug
mode too.
François
On 22/01/2015 03:07, Jonathan Wakely wrote:
On 21/01/15 23:30 +0100, François Dumont wrote:
+#if __cplusplus 201103L
+ templatetypename _Kt
+std
.
Is it ok then to commit attached patch to do the same for debug mode ?
And also for profile mode later when I have it ready (this WE I think) ?
2015-01-22 François Dumont fdum...@gcc.gnu.org
* include/debug/stl_map.h (map::find,
map::lower_bound, map::upper_bound, map::equal_range): New
with constexpr. Do we keep them this way ?
2014-12-20 François Dumont fdum...@gcc.gnu.org
* include/debug/vector (std::__debug::vector::clear()): Do not reset
guaranteed capacity.
* testsuite/23_containers/vector/bool/allocator/swap.cc: Move
propagating_allocator equality and inequality
::__debug::unordered_mapint, int, std::hashint,
std::equal_toint, std::allocatorstd::pairint const, int ;
}
I just want to make sure it is safe and especially portable to use
__cxa_demangle and that it is ok to do this now.
2014-12-20 François Dumont fdum...@gcc.gnu.org
* include/debug
On 20/12/2014 19:09, Jonathan Wakely wrote:
There are also 2 tests that XPASS:
XPASS: experimental/string_view/element_access/char/2.cc execution test
XPASS: experimental/string_view/element_access/wchar_t/2.cc execution
test
Debug assertions has been commented about because not
Hello
Great news.
However we need the following to make debug/profile modes happy.
Shouldn't we use _GLIBCXX_ABI_TAG_CXX11 to tag the __cxx11 namespace ?
2014-12-20 François Dumont fdum...@gcc.gnu.org
* include/bits/c++config: inline __cxx11 namespace within namespace
On 10/12/2014 00:24, Jonathan Wakely wrote:
I still say the change to if __GLIBC__ 2 || __GLIBC_MINOR__ = 20
is simply wrong. It works for me with 2.18, but if it doesn't work
with 2.19 on Debian then why should it work any better with 2.20?
Yes, it was indeed a wild guess because I
previous values on my system. I even wonder if it has anything to do
with glibc version, it rather depends on the installed locale info, no ?
2014-12-08 François Dumont fdum...@gcc.gnu.org
* testsuite/22_locale/numpunct/members/char/3.cc: Check numpunct
returned
values are consistent
So here is another proposal with all your remarks implemented.
2014-12-02 François Dumont fdum...@gcc.gnu.org
DR libstdc++/13631
* include/bits/codecvt.h (codecvtchar, char, mbstate_t): friend class
std::messageschar.
(codecvtwchar_t, char, mbstate_t): friend class
std
Hi
Here is another proposal that consider all your remarks except one.
I finally prefer to go with std::vector of pointers. Dynamically
allocating Catalog_info allow to avoid numerous copies of locale when we
find this pointer from the catalog info.
On 28/11/2014 11:49, Jonathan Wakely
locales installed. There are
some failures but not coming from this patch, will surely be the subject
of another mail.
2014-11-28 François Dumont fdum...@gcc.gnu.org
DR libstdc++/13631
* include/bits/codecvt.h (__get_c_locale): New.
* config/locale/gnu/messages_member.h
On 24/11/2014 01:23, Jonathan Wakely wrote:
On 24/11/14 00:13 +0100, François Dumont wrote:
Hello
As we are at doing some evolution in the ABI I would like to take
the opportunity to merge branch libstdcxx_so_7-2. The first fix was
I don't think we want to merge everything, but it's
Hello
As we are at doing some evolution in the ABI I would like to take
the opportunity to merge branch libstdcxx_so_7-2. The first fix was
about a messages facet issue. So here is the version for the trunk which
is the one from the branch plus management of the charset part. This way
better ?
If it is the whole usage of random numbers that you don't like I will
simply get rid of the new tests files.
François
On 10/11/2014 22:45, Jonathan Wakely wrote:
On 10/11/14 21:50 +0100, François Dumont wrote:
Any news about this one ?
Here is another version with additional random
, Jonathan Wakely wrote:
On 10/11/14 23:14 +0100, François Dumont wrote:
I introduced the random tests after Christopher Jefferson request
to have more intensive tests on those algos. Is it the whole stuff of
tests using random numbers that you don't like or just the usage of
mt19937 ?
The use
/1.cc: Likewise.
* testsuite/25_algorithms/stable_sort/4.cc: New.
* testsuite/25_algorithms/inplace_merge/2.cc: New.
* testsuite/25_algorithms/stable_partition/2.cc: New.
Ok to commit ?
François
On 17/10/2014 22:46, François Dumont wrote:
Hi
As proposed in the bug report I just
Hi
Here is more or less the patch proposed on the ticket with the test
case also provided in the ticket.
2014-11-04 François Dumont fdum...@gcc.gnu.org
Jonathan Wakely jwak...@redhat.com
PR libstdc++/63698
* include/bits/stl_tree.h (_Reuse_or_alloc_node): Simplify
Then I think we need this patch which also fix other issues.
2014-10-22 François Dumont fdum...@gcc.gnu.org
* testsuite/25_algorithms/make_heap/complexity.cc: Add missing test
variable.
* testsuite/25_algorithms/sort_heap/complexity.cc: Likewise and use
log2.
* testsuite
on new
operator. I wonder if some test using it really have the expected behavior.
I also tests other algos that try to use a buffer and didn't found
any issue. Those algos however can't be simplified like stable_partition.
2014-10-16 François Dumont fdum...@gcc.gnu.org
PR libstdc++/61107
to detect invalid usages even in this context.
2014-10-16 François Dumont fdum...@gcc.gnu.org
PR libstdc++/63500
* include/debug/functions.h (__foreign_iterator_aux2): Do not check for
foreign iterators if input iterators returns rvalue reference.
* testsuite/23_containers/vector
Hi
Here is a proposal to fix the issue with iterators which do not
expose lvalue references when dereferenced. I simply chose to detect
such an issue in c++11 mode thanks to the is_lvalue_reference meta function.
2014-10-15 François Dumont fdum...@gcc.gnu.org
PR libstdc++/63500
On 06/10/2014 23:05, Daniel Krügler wrote:
2014-10-06 23:00 GMT+02:00 François Dumont frs.dum...@gmail.com:
On 05/10/2014 22:54, Marc Glisse wrote:
On Sun, 5 Oct 2014, François Dumont wrote:
I took a look at PR 61217 regarding pop_heap complexity guarantee.
Looks like we have no test
On 05/10/2014 22:54, Marc Glisse wrote:
On Sun, 5 Oct 2014, François Dumont wrote:
I took a look at PR 61217 regarding pop_heap complexity guarantee.
Looks like we have no test to check complexity of our algos so I
start writing some starting with the heap operations. I found no
issue
Hi
I just committed this trivial bug fix.
Shall I go ahead and apply it to 4.9 branch too ?
2014-10-05 François Dumont fdum...@gcc.gnu.org
PR libstdc++/63456
* include/bits/hashtable.h (_M_uses_single_bucket(__bucket_type*)):
Test
the parameter.
* testsuite
On 05/10/2014 21:37, Paolo Carlini wrote:
Hi,
On 10/05/2014 08:50 PM, François Dumont wrote:
+#include testsuite_hooks.h
Seems redundant.
Thanks!
Paolo.
Yes it is and in fact I had remove it before the real commit, I should
have update the patch.
François
On 23/09/2014 13:27, Jonathan Wakely wrote:
Yes, OK for trunk - thanks very much.
Hi
There was in fact one last test failing, ext/profile/mh.cc, a
profile mode specific test. It must have been failing for quite a while
since malloc hooks has been deprecated. It is normally testing the
I forgot to check pretty printer tests indeed, I will.
François
On 30/09/2014 17:32, Jonathan Wakely wrote:
On 26/09/14 11:05 +0100, Jonathan Wakely wrote:
On 26/09/14 00:00 +0200, François Dumont wrote:
Apart from those minor adjustments I think this looks good, but I'd
like to know
on debug iterators ?
François
On 30/09/2014 17:32, Jonathan Wakely wrote:
On 26/09/14 11:05 +0100, Jonathan Wakely wrote:
On 26/09/14 00:00 +0200, François Dumont wrote:
Apart from those minor adjustments I think this looks good, but I'd
like to know that it has been tested with -fsanitize
I added myself as libstdc++ special modes maintainer. Special modes are
debug, profile and parallel modes.
Thanks for your trust.
François
Apart from those minor adjustments I think this looks good, but I'd
like to know that it has been tested with -fsanitize=thread, even if
only lightly tested.
Hi
Dmitry, who reported the bug, confirmed the fix. Can I go ahead and
commit ?
François
On 23/09/2014 13:22, Jonathan Wakely wrote:
On 22/09/14 23:51 +0200, François Dumont wrote:
New patch in a couple of day then.
OK, thanks.
It was faster than I though, here is the fixed patch tested under Linux
x86_64.
2014-09-23 François Dumont fdum...@gcc.gnu.org
PR libstdc
On 22/09/2014 00:04, Jonathan Wakely wrote:
On 10/09/14 22:55 +0200, François Dumont wrote:
Hi
Here is a proposal to fix this data race issue.
I finally generalized bitset approach to fix it by inheriting from
the normal iterator first and then the _Safe_iterator_base type. None
On 23/09/2014 13:27, Jonathan Wakely wrote:
On 21/09/14 23:29 +0200, François Dumont wrote:
With all those modifications I have been able to run all testsuite
in profile mode with success.
I've looked over the patch and it looks fine.
I don't know the details of the Profile Mode, so
On 11/06/2014 14:02, Jonathan Wakely wrote:
@@ -514,11 +651,11 @@
{ return this-_M_impl._M_header._M_right; }
_Link_type
- _M_begin() _GLIBCXX_NOEXCEPT
+ _M_begin() const _GLIBCXX_NOEXCEPT
{ return
static_cast_Link_type(this-_M_impl._M_header._M_parent); }
What's
Hi
Here is the promise major patch for the profile mode. Here are the
most important modifications.
Now instance of profiling structs are kept as pointers in the
containers themselves. It has an impact on the container ABI but it
greatly enhance performances as we do not need to
Still no feedback regarding this proposal ?
On 19/08/2014 22:14, François Dumont wrote:
Any news regarding this proposal ?
Thanks
François
On 30/07/2014 23:39, François Dumont wrote:
Hi
Now that patch on testsuite allocator is in I would like to
reactivate this one. Here
.
Do you see any way to check for this problem in the testsuite ? Is
there a thread sanitizer we could use ?
2014-09-10 François Dumont fdum...@gcc.gnu.org
PR libstdc++/62313
* include/debug/safe_base.h
(_Safe_iterator_base(const _Safe_iterator_base)): Delete declaration
On 09/09/2014 19:29, Jonathan Wakely wrote:
On 14/08/14 21:22 +0200, François Dumont wrote:
I am preparing a patch for profile mode so I will submit modification
for this mode with this big patch.
btw, François, for profile mode I think we should just do something
like this patch.
I feel
document it ourself
next to the code rather than in a distinct file.
François
On 14/08/2014 21:22, François Dumont wrote:
On 13/08/2014 11:50, Jonathan Wakely wrote:
Yes you can, it's conforming to replace a (non-virtual) member function
with default arguments by two or more member functions
Any news regarding this proposal ?
Thanks
François
On 30/07/2014 23:39, François Dumont wrote:
Hi
Now that patch on testsuite allocator is in I would like to
reactivate this one. Here it is again.
See previous answer below regarding modification of
_M_begin/_M_cbegin
a burden. Do
you think we shall do so now ?
2014-08-14 François Dumont fdum...@gcc.gnu.org
* include/bits/hashtable_policy.h (_Prime_rehash_policy): Qualify
constructor
noexcept.
(_Hash_code_base): All specialization default constructible if
possible.
(_Hashtable_base
is the patch again even if a little bit simplified.
Regarding the doc I try to put information in Doxygen comments this way
we do not need to maintain another page for that.
2014-08-12 François Dumont fdum...@gcc.gnu.org
* include/bits/hashtable.h: Make use of the internal single bucket
On 12/08/2014 21:39, Marc Glisse wrote:
On Tue, 12 Aug 2014, François Dumont wrote:
Based on your feedbacks I think we should stay with just targeting
good QoI by not allocating on default construction. As I said the
noexcept qualification would need to not conform strictly
a
big insertion.
The fix is simple. A call to _M_need_rehash rather than
_M_bkt_for_elements/_M_next_bkt automatically initialize the rehash
policy considering the current number of elements and buckets in the
container.
2014-08-07 François Dumont fdum...@gcc.gnu.org
* include/bits
Hi
Now that patch on testsuite allocator is in I would like to
reactivate this one. Here it is again.
See previous answer below regarding modification of
_M_begin/_M_cbegin.
2014-07-30 François Dumont fdum...@gcc.gnu.org
PR libstdc++/29988
* include/bits
Hi
I think I never get feedback regarding this patch proposal. Note
that if accepted the doc will have to be updated regarding the default
hint value.
Thanks
On 03/06/2014 22:44, François Dumont wrote:
Hi
Thanks to the single bucket introduced to make move semantic
noexcept we
801 - 900 of 1038 matches
Mail list logo
