On 4 November 2014 13:13, Paolo Carlini <paolo.carl...@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.carl...@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.
