public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/62313] New: Data race in debug iterators
@ 2014-08-30 16:07 dvyukov at google dot com
2014-08-30 16:12 ` [Bug libstdc++/62313] " pinskia at gcc dot gnu.org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: dvyukov at google dot com @ 2014-08-30 16:07 UTC (permalink / raw)
To: gcc-bugs
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}.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
@ 2014-08-30 16:12 ` pinskia at gcc dot gnu.org
2014-08-30 16:23 ` dvyukov at google dot com
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2014-08-30 16:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
2014-08-30 16:12 ` [Bug libstdc++/62313] " pinskia at gcc dot gnu.org
@ 2014-08-30 16:23 ` dvyukov at google dot com
2014-08-31 19:07 ` redi at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: dvyukov at google dot com @ 2014-08-30 16:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
2014-08-30 16:12 ` [Bug libstdc++/62313] " pinskia at gcc dot gnu.org
2014-08-30 16:23 ` dvyukov at google dot com
@ 2014-08-31 19:07 ` redi at gcc dot gnu.org
2014-08-31 20:56 ` fdumont at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: redi at gcc dot gnu.org @ 2014-08-31 19:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
` (2 preceding siblings ...)
2014-08-31 19:07 ` redi at gcc dot gnu.org
@ 2014-08-31 20:56 ` fdumont at gcc dot gnu.org
2014-09-01 9:44 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: fdumont at gcc dot gnu.org @ 2014-08-31 20:56 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
` (3 preceding siblings ...)
2014-08-31 20:56 ` fdumont at gcc dot gnu.org
@ 2014-09-01 9:44 ` redi at gcc dot gnu.org
2014-09-01 10:12 ` dvyukov at google dot com
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: redi at gcc dot gnu.org @ 2014-09-01 9:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
` (4 preceding siblings ...)
2014-09-01 9:44 ` redi at gcc dot gnu.org
@ 2014-09-01 10:12 ` dvyukov at google dot com
2014-09-01 22:36 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: dvyukov at google dot com @ 2014-09-01 10:12 UTC (permalink / raw)
To: gcc-bugs
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();
}
};
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
` (5 preceding siblings ...)
2014-09-01 10:12 ` dvyukov at google dot com
@ 2014-09-01 22:36 ` redi at gcc dot gnu.org
2014-09-02 3:30 ` dvyukov at google dot com
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: redi at gcc dot gnu.org @ 2014-09-01 22:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
` (6 preceding siblings ...)
2014-09-01 22:36 ` redi at gcc dot gnu.org
@ 2014-09-02 3:30 ` dvyukov at google dot com
2014-09-23 20:47 ` fdumont at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: dvyukov at google dot com @ 2014-09-02 3:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
` (7 preceding siblings ...)
2014-09-02 3:30 ` dvyukov at google dot com
@ 2014-09-23 20:47 ` fdumont at gcc dot gnu.org
2014-09-24 0:43 ` dvyukov at google dot com
2014-09-29 21:22 ` fdumont at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: fdumont at gcc dot gnu.org @ 2014-09-23 20:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
` (8 preceding siblings ...)
2014-09-23 20:47 ` fdumont at gcc dot gnu.org
@ 2014-09-24 0:43 ` dvyukov at google dot com
2014-09-29 21:22 ` fdumont at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: dvyukov at google dot com @ 2014-09-24 0:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libstdc++/62313] Data race in debug iterators
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
` (9 preceding siblings ...)
2014-09-24 0:43 ` dvyukov at google dot com
@ 2014-09-29 21:22 ` fdumont at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: fdumont at gcc dot gnu.org @ 2014-09-29 21:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-09-29 21:22 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-30 16:07 [Bug libstdc++/62313] New: Data race in debug iterators dvyukov at google dot com
2014-08-30 16:12 ` [Bug libstdc++/62313] " pinskia at gcc dot gnu.org
2014-08-30 16:23 ` dvyukov at google dot com
2014-08-31 19:07 ` redi at gcc dot gnu.org
2014-08-31 20:56 ` fdumont at gcc dot gnu.org
2014-09-01 9:44 ` redi at gcc dot gnu.org
2014-09-01 10:12 ` dvyukov at google dot com
2014-09-01 22:36 ` redi at gcc dot gnu.org
2014-09-02 3:30 ` dvyukov at google dot com
2014-09-23 20:47 ` fdumont at gcc dot gnu.org
2014-09-24 0:43 ` dvyukov at google dot com
2014-09-29 21:22 ` fdumont at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).