This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: Jonathan Wakely <jwakely at redhat dot com>, "libstdc++" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Rainer Emrich <rainer at emrich-ebersheim dot de>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 4 Nov 2014 15:32:56 +0000
- Subject: Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore
- Authentication-results: sourceware.org; auth=none
- References: <54579773 dot 60601 at emrich-ebersheim dot de> <5457AAF8 dot 5060403 at oracle dot com> <5457C09A dot 60303 at oracle dot com> <CAH6eHdTxzxQoc+6Ti+6GfgU8X-Mq8xztzFosft2gH96eyCi_aA at mail dot gmail dot com> <20141104034118 dot GG3961 at redhat dot com> <20141104043400 dot GJ3961 at redhat dot com> <5458D0F5 dot 5070809 at oracle dot com>
On 4 November 2014 13:13, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi again,
>
>
> On 11/04/2014 05:34 AM, Jonathan Wakely wrote:
>>
>> On 04/11/14 03:41 +0000, Jonathan Wakely wrote:
>>>
>>> On 03/11/14 22:07 +0000, Jonathan Wakely wrote:
>>>>
>>>> On 3 November 2014 17:51, Paolo Carlini <paolo.carlini@oracle.com>
>>>> wrote:
>>>>>
>>>>> .. other than the above issue, I see a segmentation fault for:
>>>>>
>>>>> performance/ext/pb_ds/multimap_text_insert_mem_large.cc
>
> Not a big deal of course, but unfortunately today I'm seeing *two* segfaults
> for pb_ds:
>
> performance/ext/pb_ds/multimap_text_insert_mem_large.cc
> .../libstdc++-v3/scripts/check_performance: line 41: 16173 Segmentation
> fault ./$EXE_NAME &>tmp.$FILE_NAME
> performance/ext/pb_ds/multimap_text_insert_mem_small.cc
> .../libstdc++-v3/scripts/check_performance: line 41: 16217 Segmentation
> fault ./$EXE_NAME &>tmp.$FILE_NAME
They were both caused by the infinite recursion in the operator== for
tracker_allocator, which should be fixed.
However, my change to std::deque's move constructor introduced some
new failures, mostly due to dg-error line numbers that need to change,
but one real failure in 23_containers/deque/allocator/move_assign.cc
I'm not sure whether the right approach is to violate the requirement
that deque's move constructor move constructs the allocator, (which I
changed to copy construction, to meet the exception safety guarantee
that the RHS of the move construction maintains its invariants) or to
change the invariant so that a deque doesn't always have a map
allocated.
I'll fix it asap.