[Bug libstdc++/62313] New: Data race in debug iterators

[Bug libstdc++/62313] New: Data race in debug iterators

[dvyukov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

            Bug ID: 62313
           Summary: Data race in debug iterators
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dvyukov at google dot com

$ g++ -v
gcc version 5.0.0 20140830 (experimental) (GCC) 

The program is:

=======
#include <list>
#include <pthread.h>
#include <unistd.h>

std::list<int>::iterator iter, iter2;

void *thread(void *arg)
{
    for (int i = 0; i < 1000000; i++) {
        std::list<int>::iterator it(iter);
        iter2 = it;
    }
    return 0;
}

int main()
{
    std::list<int> li;
    li.push_back(0);
    iter = li.begin();
    pthread_t th;
    pthread_create(&th, 0, thread, 0);
    for (int i = 0; i < 1000000; i++) {
        li.push_back(1);
        std::list<int>::iterator it = li.begin();
        it++;
        li.erase(it);
    }
    pthread_join(th, 0);
}
=====

Build it as:
$ g++ test.cc -Wall -lpthread -fsanitize=thread -pie -fPIE -D_GLIBCXX_DEBUG -g
-O2

Run the program. Output is:

WARNING: ThreadSanitizer: data race (pid=17058)
  Read of size 8 at 0x7faedc637b00 by main thread (mutexes: write M2):
    #0 void __gnu_debug::_Safe_sequence<std::__debug::list<int,
std::allocator<int> >
>::_M_invalidate_if<__gnu_debug::_Equal_to<std::__cxx1998::_List_const_iterator<int>
> >(__gnu_debug::_Equal_to<std::__cxx1998::_List_const_iterator<int> >)
/foo/include/c++/5.0.0/debug/safe_sequence.tcc:48 (a.out+0x000000002a61)
    #1 std::__debug::list<int, std::allocator<int>
>::_M_erase(std::__cxx1998::_List_iterator<int>)
/foo/include/c++/5.0.0/debug/list:464 (a.out+0x000000001e21)
    #2 std::__debug::list<int, std::allocator<int>
>::erase(__gnu_debug::_Safe_iterator<std::__cxx1998::_List_iterator<int>,
std::__debug::list<int, std::allocator<int> > >)
/foo/include/c++/5.0.0/debug/list:477 (a.out+0x000000001e21)
    #3 main test.cc:27 (a.out+0x000000001e21)

  Previous write of size 8 at 0x7faedc637b00 by thread T1:
    #0 __gnu_debug::_Safe_iterator<std::__cxx1998::_List_iterator<int>,
std::__debug::list<int, std::allocator<int> >
>::operator=(__gnu_debug::_Safe_iterator<std::__cxx1998::_List_iterator<int>,
std::__debug::list<int, std::allocator<int> > > const&)
/foo/include/c++/5.0.0/debug/safe_iterator.h:223 (a.out+0x000000002460)
    #1 thread(void*) test.cc:11 (a.out+0x000000002460)

  Location is global 'iter2' of size 40 at 0x7faedc637ae0
(a.out+0x000000203b00)

  Mutex M2 (0x7faedb100698) created at:
    #0 pthread_mutex_lock
../../.././libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2686
(libtsan.so.0+0x0000000368a6)
    #1 __gthread_mutex_lock
/ssd/src/gcc_trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/gthr-default.h:748
(libstdc++.so.6+0x0000000b284b)
    #2 __gnu_cxx::__mutex::lock()
/ssd/src/gcc_trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/concurrence.h:152
(libstdc++.so.6+0x0000000b284b)
    #3 __gnu_cxx::__scoped_lock::__scoped_lock(__gnu_cxx::__mutex&)
/ssd/src/gcc_trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/concurrence.h:244
(libstdc++.so.6+0x0000000b284b)
    #4
__gnu_debug::_Safe_sequence_base::_M_attach(__gnu_debug::_Safe_iterator_base*,
bool) ../../../.././libstdc++-v3/src/c++11/debug.cc:268
(libstdc++.so.6+0x0000000b284b)
    #5 __libc_start_main <null>:0 (libc.so.6+0x000000021ec4)

  Thread T1 (tid=17060, running) created by main thread at:
    #0 pthread_create ../../.././libsanitizer/tsan/tsan_interceptors.cc:853
(libtsan.so.0+0x000000026eb4)
    #1 main test.cc:22 (a.out+0x000000001aad)


As far as I see the safe iterator first attaches itself to the sequence in
_Safe_iterator_base ctor:

      _Safe_iterator(const _Safe_iterator& __x)
      : _Safe_iterator_base(__x, _M_constant()), _M_current(__x._M_current)

After that point it's accessible from other threads (in particular that
invalidate other iterators).
Only then it sets _M_current.
But _M_current is already read from another thread that invalidates a different
iterator.

There can be a similar race in dtor. They usually come together.

It can make sense to run some extensive test suite (if one exists) for debug
iterators with -fsanitize=thread -O{0,1,2}.

[Bug libstdc++/62313] Data race in debug iterators

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
You don't protect either the iterators or the list when touching it so I don't
think this is a bug. If they truly independent lists and that was causing
issues, then yes there would be an issue.

[Bug libstdc++/62313] Data race in debug iterators

[dvyukov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

--- Comment #2 from Dmitry Vyukov <dvyukov at google dot com> ---
The additional thread only touches iter, and the main thread does not touch
iter nor invalidate it. So there is nothing to protect here. The program does
not contain data races per se.

[Bug libstdc++/62313] Data race in debug iterators

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-08-31
     Ever confirmed|0                           |1

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Dmitry Vyukov from comment #0)
> As far as I see the safe iterator first attaches itself to the sequence in
> _Safe_iterator_base ctor:
> 
>       _Safe_iterator(const _Safe_iterator& __x)
>       : _Safe_iterator_base(__x, _M_constant()), _M_current(__x._M_current)
> 
> After that point it's accessible from other threads (in particular that
> invalidate other iterators).
> Only then it sets _M_current.
> But _M_current is already read from another thread that invalidates a
> different iterator.

Yes, that's a bug.

> It can make sense to run some extensive test suite (if one exists) for debug
> iterators with -fsanitize=thread -O{0,1,2}.

The tests for the debug mode don't generally involve threads, so that isn't
likely to help.

[Bug libstdc++/62313] Data race in debug iterators

[fdumont at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

--- Comment #4 from François Dumont <fdumont at gcc dot gnu.org> ---
For me there is no bug. Standard containers are known to not be thread safe. I
don't know what  Standard points are talking about it but what I consider as
valid was iterating through the container from different threads. However in
your case you are doing some iterator operations, no matter how simple they
are,  in one thread while modifying the container from another and this require
you to put some mutex in place to do so.

I think you will experiment the same issue with all versions of the Standard
lib, even the oldest ones. Synchronization of the list of iterators has never
been plan to cover this kind of usage which is considered as invalid.
>From gcc-bugs-return-460153-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 31 21:06:45 2014
Return-Path: <gcc-bugs-return-460153-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15221 invoked by alias); 31 Aug 2014 21:06:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15173 invoked by uid 55); 31 Aug 2014 21:06:41 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/62302] [5 Regression] Change in the comdat used for constructors
Date: Sun, 31 Aug 2014 21:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62302-4-ETiB19I7xV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62302-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62302-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg02650.txt.bz2
Content-length: 481

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb302

--- Comment #1 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Sun Aug 31 21:06:08 2014
New Revision: 214770

URL: https://gcc.gnu.org/viewcvs?rev!4770&root=gcc&view=rev
Log:
    PR c++/62302
    * optimize.c (cdtor_comdat_group): Just look at the
    DECL_ASSEMBLER_NAME of the 'tors.

Added:
    trunk/gcc/testsuite/g++.dg/abi/comdat1.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/optimize.c

[Bug libstdc++/62313] Data race in debug iterators

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to François Dumont from comment #4)
> For me there is no bug. Standard containers are known to not be thread safe.

No, containers are known to be thread-safe, when used correctly.

> I don't know what  Standard points are talking about it but what I consider
> as valid was iterating through the container from different threads. However
> in your case you are doing some iterator operations, no matter how simple
> they are,  in one thread while modifying the container from another and this
> require you to put some mutex in place to do so.

No it doesn't.

Only the main thread accesses the container. The other thread simply reads and
writes global iterator objects, which are distinct memory locations from the
container and so can be accessed concurrently. See 17.6.5.9
[res.on.data.races]: "-7- Implementations may share their own internal objects
between threads if the objects are not visible to users and are protected
against data races."

> I think you will experiment the same issue with all versions of the Standard
> lib, even the oldest ones. Synchronization of the list of iterators has
> never been plan to cover this kind of usage which is considered as invalid.

No, this is a bug.
>From gcc-bugs-return-460283-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 01 09:57:56 2014
Return-Path: <gcc-bugs-return-460283-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3996 invoked by alias); 1 Sep 2014 09:57:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3956 invoked by uid 48); 1 Sep 2014 09:57:53 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/62174] Component declarations overwrite types of Cray Pointee variables
Date: Mon, 01 Sep 2014 09:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-62174-4-PzTxTqWSLU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62174-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62174-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg00117.txt.bz2
Content-length: 734

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb174

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Patches should go to the gcc-patches at gcc.gnu.org mailing list (and in case
of Fortran FE patches also CC fortran at gcc.gnu.org ml).  That is where patch
review happens.  For a one-liner change like this, I think you don't need
Copyright assignment, but if you plan to submit further patches, please
consider following https://gcc.gnu.org/contribute.html

[Bug libstdc++/62313] Data race in debug iterators

[dvyukov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

--- Comment #6 from Dmitry Vyukov <dvyukov at google dot com> ---
> The tests for the debug mode don't generally involve threads, so that isn't likely to help.

Then you can run any heavily multithreaded program that extensively uses stl
and is currently race-free. That last condition is somewhat tricky. I could
suggest running Chromium browser as we oversee it for data races
(http://dev.chromium.org/developers/testing/threadsanitizer-tsan-v2), but it
can be somewhat tricky.

====

The issue introduces a data race into the following program -- 'it' parameter
is constructed concurrently with list mutation. If it is a bug in user program,
them all concurrent C++ program that use stl are buggy.

class X {
    std::list<int> li_;
    std::mutex mu_;
public:
    void erase(std::list<int>::iterator it) {
        mu_.lock();
        li_.erase(it);
        mu_unlock();
    }
};

[Bug libstdc++/62313] Data race in debug iterators

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It might be possible to solve using the base-from-member idiom so that
_M_current is set before the iterator is added to the collection.

[Bug libstdc++/62313] Data race in debug iterators

[dvyukov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

--- Comment #9 from Dmitry Vyukov <dvyukov at google dot com> ---
Don't forget about destructor -- the iterator must be removed from list before
it destruction starts.

[Bug libstdc++/62313] Data race in debug iterators

[fdumont at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

François Dumont <fdumont at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |fdumont at gcc dot gnu.org

--- Comment #10 from François Dumont <fdumont at gcc dot gnu.org> ---
Created attachment 33543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33543&action=edit
Race condition patch

Hi

Dmitry, could you have a try with this patch to confirm that it is fixing the
bug. It is a patch against libstdc++ trunk.

Thanks
>From gcc-bugs-return-462371-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 23 20:50:07 2014
Return-Path: <gcc-bugs-return-462371-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28853 invoked by alias); 23 Sep 2014 20:50:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28780 invoked by uid 48); 23 Sep 2014 20:50:00 -0000
From: "jifl-bugzilla at jifvik dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63347] New: m68k misoptimisation with -fschedule-insns
Date: Tue, 23 Sep 2014 20:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.7.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: jifl-bugzilla at jifvik dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-63347-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02205.txt.bz2
Content-length: 2697

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc347

            Bug ID: 63347
           Summary: m68k misoptimisation with -fschedule-insns
           Product: gcc
           Version: 4.7.4
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jifl-bugzilla at jifvik dot org

The following minimal test case (derived from much larger code) demonstrates a
problem which I could reproduce on m68k-elf-gcc 4.7.4. It can be built with
simply:

m68k-elf-gcc -c -O1 -fschedule-insns foo.c

extern int printf(const char *fmt, ...);

int print_info(unsigned int *ip_addr)
{
    int invalid = 0;

    if (ip_addr) {
        unsigned int haddr = *ip_addr;
        printf("%d.%d.%d.%d",
               (int)((haddr >> 24) & 0xff),
               (int)((haddr >> 16) & 0xff),
               (int)((haddr >> 8) & 0xff),
               (int)((haddr >> 0) & 0xff));
        if (0x0 == haddr) {
            invalid = 1;
        }
        printf("\n");
    } else {
        invalid = 1;
    }

    return invalid;
}

The problem manifests with the 'tstl' instruction corresponding to the 'if
(0x0==haddr)' simply disappearing, resulting in an incorrect return value.
Here's the relevant section of asm for a working version (without
-fschedule-insns):

  48:   4fef 0014       lea %sp@(20),%sp
  4c:   4a82            tstl %d2
  4e:   57c2            seq %d2
  50:   49c2            extbl %d2
  52:   4482            negl %d2
  54:   4879 0000 0000  pea 0 <print_info>
                        56: R_68K_32    .rodata.str1.1+0xc

%d2 is later moved to %d0 to give the return value.


and for a broken version:
  4c:   4fef 0014       lea %sp@(20),%sp
  50:   4879 0000 0000  pea 0 <print_info>
                        52: R_68K_32    .rodata.str1.1+0xc
  56:   57c2            seq %d2
  58:   49c2            extbl %d2
  5a:   4482            negl %d2

The 'tstl' insn is gone!

If you want to make this an executable, I added on the following which
demonstrates the problem:
int main(int argc, char *argv[])
{
    unsigned int myaddr;
    int ret;

    myaddr = 0x0;
    ret = print_info(&myaddr);
    if (!ret)
        printf("FAIL: addr 0 returned %d\n", ret);

    myaddr = 0x01020304;
    ret = print_info(&myaddr);
    if (ret)
        printf("FAIL: addr 1234 returned %d\n", ret);
    return 0;
}

This worked in gcc 4.4.5, but I haven't tried 4.5 or 4.6. Of course other
changes in the optimizer would probably perturb things enough that this code
wouldn't trigger it any more with different gcc versions (including 4.8 or
4.9), even if the problem in the compiler still remains.

[Bug libstdc++/62313] Data race in debug iterators

[dvyukov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

--- Comment #11 from Dmitry Vyukov <dvyukov at google dot com> ---
Just test it with
g++ test.cc -Wall -lpthread -fsanitize=thread -pie -fPIE -D_GLIBCXX_DEBUG -g
-O2
There is nothing else I can do on top of that.

[Bug libstdc++/62313] Data race in debug iterators

[fdumont at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

--- Comment #12 from François Dumont <fdumont at gcc dot gnu.org> ---
Author: fdumont
Date: Mon Sep 29 21:22:17 2014
New Revision: 215693

URL: https://gcc.gnu.org/viewcvs?rev=215693&root=gcc&view=rev
Log:
2014-09-29  François Dumont  <fdumont@gcc.gnu.org>

    PR libstdc++/62313
    * include/debug/safe_base.h
    (_Safe_iterator_base(const _Safe_iterator_base&)): Delete declaration.
    (_Safe_iterator_base& operator=(const _Safe_iterator_base&)): Likewise.
    * include/debug/safe_iterator.h (_Safe_iterator<>): Move normal iterator
    before _Safe_iterator_base in memory. Lock before modifying the iterator
    in numerous places.
    * include/debug/safe_local_iterator.h
    (_Safe_local_iterator_base(const _Safe_local_iterator_base&)): Delete
    declaration.
    (_Safe_local_iterator_base& operator=(const _Safe_local_iterator_base&)):
    Likewise.
    * include/debug/safe_unordered_base.h (_Safe_local_iterator<>):  Move
    normal iterator before _Safe_iterator_base in memory. Lock before
    modifying the iterator in numerous places.
    * include/debug/forward_list (_Safe_forward_list<>::_M_swap_aux): Adapt.
    * include/debug/safe_sequence.tcc
    (_Safe_sequence<>::_M_transfer_from_if): Adapt.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/debug/forward_list
    trunk/libstdc++-v3/include/debug/safe_base.h
    trunk/libstdc++-v3/include/debug/safe_iterator.h
    trunk/libstdc++-v3/include/debug/safe_local_iterator.h
    trunk/libstdc++-v3/include/debug/safe_sequence.tcc
    trunk/libstdc++-v3/include/debug/safe_unordered_base.h
>From gcc-bugs-return-462888-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 29 21:26:36 2014
Return-Path: <gcc-bugs-return-462888-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21409 invoked by alias); 29 Sep 2014 21:26:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21362 invoked by uid 48); 29 Sep 2014 21:26:33 -0000
From: "fdumont at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/62313] Data race in debug iterators
Date: Mon, 29 Sep 2014 21:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fdumont at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: fdumont at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-62313-4-RLqubtcSd9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62313-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62313-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02722.txt.bz2
Content-length: 648

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313

François Dumont <fdumont at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |5.0

--- Comment #13 from François Dumont <fdumont at gcc dot gnu.org> ---
A number of additional locks have been added to make sure we do not modify an
iterator while the list of iterators might be checked through another thread.
>From gcc-bugs-return-462889-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 29 21:40:15 2014
Return-Path: <gcc-bugs-return-462889-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28614 invoked by alias); 29 Sep 2014 21:40:15 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28576 invoked by uid 48); 29 Sep 2014 21:40:11 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63411] New: [4.9/5 regression] ivopt produces wrong struct offset
Date: Mon, 29 Sep 2014 21:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: critical
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter cf_gcchost cf_gcctarget
Message-ID: <bug-63411-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02723.txt.bz2
Content-length: 2438

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc411

            Bug ID: 63411
           Summary: [4.9/5 regression] ivopt produces wrong struct offset
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: critical
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: olegendo at gcc dot gnu.org
              Host: i686-linux-gnu
            Target: sh*-*-*

Compiling the following as C or C++:

typedef struct
{
  unsigned char sprindex;
  unsigned char y;
  unsigned char index;
  unsigned char attr;
  unsigned char x;
  unsigned short pattern;
} oam;

extern oam OAM3[8];

int test2 (unsigned c, int r)
{
  for (unsigned i = 0; i < c; ++i)
  {
    oam* s = &(OAM3[i]);
    if (s->attr & 0x40)
      r += s->pattern;
  }
  return r;
}

on SH (big or little endian, any CPU type) with -O2 results in the following
wrong code:

_test2:
        tst     r4,r4
        bt      .L12
        mov.l   .L14,r1
        .align 2
.L4:
        mov.b   @r1,r0
        tst     #64,r0
        bt/s    .L3
        mov     r1,r2
        add     #3,r2     <<< wrong struct offset '3'
        mov.w   @r2,r2    <<< should be '3*2', i.e. '6'.
        extu.w  r2,r2
        add     r2,r5
.L3:
        dt      r4
        bf/s    .L4
        add     #8,r1
.L12:
        rts
        mov     r5,r0
.L15:
        .align 2
.L14:
        .long   _OAM3+3
        .size   _test2, .-_test2
        .ident  "GCC: (GNU) 4.9.2 20140929 (prerelease)"


Disabling ivopt with '-fno-ivopts' produces correct code:

_test2:
        tst     r4,r4
        bt      .L12
        mov     #0,r2
        mov.l   .L14,r3
        .align 2
.L4:
        mov     r2,r1
        shll2   r1
        add     r1,r1
        add     r3,r1
        mov.b   @(3,r1),r0
        tst     #64,r0
        bt      .L3
        mov.w   @(6,r1),r0    <<< correct struct offset '6'
        extu.w  r0,r1
        add     r1,r5
.L3:
        dt      r4
        bf/s    .L4
        add     #1,r2
.L12:
        rts
        mov     r5,r0
.L15:
        .align 2
.L14:
        .long   _OAM3
        .size   _test2, .-_test2
        .ident  "GCC: (GNU) 4.9.2 20140929 (prerelease)"


I haven't checked whether this happens on other targets, but I guess this is
not SH specific.

This happens on the current 4.9 branch and trunk.  4.8 branch is not affected.