On 16/01/17 11:24 +, Jonathan Wakely wrote:
OK for trunk with the additional changes to use better magic numbers
in the tests.
Oh, and for the branches too.
On 15/01/17 19:07 +0200, Ville Voutilainen wrote:
PR libstdc++/78389
Fix backwards size adjustments.
I don't think repeating this text here and ...
* include/bits/list.tcc (merge(list&&)):
Fix backwards size adjustments.
... here is useful.
More useful would be a good Git-style
On 15 January 2017 at 19:22, Ville Voutilainen
wrote:
> Hmm, and yeah, your test uses a different throw-after number, so I
> should change the tests to do the same. :)
In other words, like in the attached patch.
diff --git a/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc
b/libstdc
On 15 January 2017 at 19:07, Ville Voutilainen
wrote:
> On 15 January 2017 at 19:01, Ville Voutilainen
> wrote:
>> On 15 January 2017 at 18:42, Tim Song wrote:
>>> On rereading the patch today, the size calculation for merge() appears
>>> to be backwards. [__first2, __last2) consists of the node
On 15 January 2017 at 19:01, Ville Voutilainen
wrote:
> On 15 January 2017 at 18:42, Tim Song wrote:
>> On rereading the patch today, the size calculation for merge() appears
>> to be backwards. [__first2, __last2) consists of the nodes not
>> transferred into *this, so the new size of __x should
On 15 January 2017 at 18:42, Tim Song wrote:
> On rereading the patch today, the size calculation for merge() appears
> to be backwards. [__first2, __last2) consists of the nodes not
> transferred into *this, so the new size of __x should be __dist while
> this->size() should be incremented by (__
On Fri, Jan 13, 2017 at 9:26 AM, Ville Voutilainen
wrote:
> Update patch with splices for __carry added. Hopefully this resolves
> the remaining concerns that we had.
On rereading the patch today, the size calculation for merge() appears
to be backwards. [__first2, __last2) consists of the nodes
On 13/01/17 14:41 +, Jonathan Wakely wrote:
On 13/01/17 16:26 +0200, Ville Voutilainen wrote:
Update patch with splices for __carry added. Hopefully this resolves
the remaining concerns that we had.
OK for trunk after fixing the ADL issue noted below.
As discussed on IRC, the list::merge
On 13/01/17 16:26 +0200, Ville Voutilainen wrote:
Update patch with splices for __carry added. Hopefully this resolves
the remaining concerns that we had.
OK for trunk after fixing the ADL issue noted below.
There are also two stylistic comments ...
diff --git a/libstdc++-v3/include/bits/lis
Update patch with splices for __carry added. Hopefully this resolves
the remaining concerns that we had.
diff --git a/libstdc++-v3/include/bits/list.tcc
b/libstdc++-v3/include/bits/list.tcc
index c4f397f..9ba403c 100644
--- a/libstdc++-v3/include/bits/list.tcc
+++ b/libstdc++-v3/include/bits/list.
On Fri, Jan 13, 2017 at 3:27 AM, Ville Voutilainen
wrote:
> On 13 January 2017 at 10:09, Ville Voutilainen
> wrote:
Ah, I think I see what you're saying. Just splice them back in any
order. Ok, I'll give that a spin.
>>>
>>> Right, list::sort doesn't promise strong exception safety, so
On 13 January 2017 at 10:29, Ville Voutilainen
wrote:
> ..and yes, sigh, that patch has whitespace damage in it. I have
> already fixed that, so that'll be corrected before
> committing.
..as well as replacing those asserts with VERIFY.
On 13 January 2017 at 10:27, Ville Voutilainen
wrote:
> On 13 January 2017 at 10:09, Ville Voutilainen
> wrote:
Ah, I think I see what you're saying. Just splice them back in any
order. Ok, I'll give that a spin.
>>>
>>> Right, list::sort doesn't promise strong exception safety, so
>>>
On 13 January 2017 at 10:09, Ville Voutilainen
wrote:
>>> Ah, I think I see what you're saying. Just splice them back in any
>>> order. Ok, I'll give that a spin.
>>
>> Right, list::sort doesn't promise strong exception safety, so
>> "unsorting" is not needed.
>>
>> Also, shouldn't merge() rethrow
On 13 January 2017 at 10:02, Tim Song wrote:
> On Fri, Jan 13, 2017 at 3:00 AM, Ville Voutilainen
> wrote:
>> On 13 January 2017 at 09:56, Ville Voutilainen
>> wrote:
problem with just going through all of them and splicing the contents
(if any) back to *this?
>>>
>>> Well, in addition
On Fri, Jan 13, 2017 at 3:00 AM, Ville Voutilainen
wrote:
> On 13 January 2017 at 09:56, Ville Voutilainen
> wrote:
>>> problem with just going through all of them and splicing the contents
>>> (if any) back to *this?
>>
>> Well, in addition to the computational complexity of it, not knowing
>> w
On 13 January 2017 at 09:56, Ville Voutilainen
wrote:
>> problem with just going through all of them and splicing the contents
>> (if any) back to *this?
>
> Well, in addition to the computational complexity of it, not knowing
> which elements should be spliced
> back where. If a comparator given
On 13 January 2017 at 09:51, Tim Song wrote:
>>> Wait, what throwing move? list::sort should be all splicing and no
>>> moving, unless I missed something.
>>
>> It operates based on merge, which moves elements from one list to
>> another using a throwing
>> comparator. Undoing that operation is fa
On Fri, Jan 13, 2017 at 1:39 AM, Ville Voutilainen
wrote:
> On 13 January 2017 at 08:01, Tim Song wrote:
>> On Thu, Jan 12, 2017 at 8:11 PM, Ville Voutilainen
>> wrote:
>>> This patch doesn't try to fix the reported sort() issue, because
>>> a) it would require undoing a throwing move operation,
On 13 January 2017 at 08:01, Tim Song wrote:
> On Thu, Jan 12, 2017 at 8:11 PM, Ville Voutilainen
> wrote:
>> This patch doesn't try to fix the reported sort() issue, because
>> a) it would require undoing a throwing move operation, which
>> is impossible.
>> b) in order to avoid the throwing mov
On Thu, Jan 12, 2017 at 8:11 PM, Ville Voutilainen
wrote:
> This patch doesn't try to fix the reported sort() issue, because
> a) it would require undoing a throwing move operation, which
> is impossible.
> b) in order to avoid the throwing move, we would need to add a
> level of indirection and t
Tested on Linux-x64.
This patch doesn't try to fix the reported sort() issue, because
a) it would require undoing a throwing move operation, which
is impossible.
b) in order to avoid the throwing move, we would need to add a
level of indirection and the scratch space for the indirect data
would ne
22 matches
Mail list logo
