[Bug c++/40362] New: openmp: some libgomp functions trigger data races

uct: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bart dot vanassche at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu

[Bug c++/40362] openmp: some libgomp functions trigger data races

--- Comment #2 from bart dot vanassche at gmail dot com 2009-06-07 06:14 --- (In reply to comment #1) > >==21970==at 0x71A35FD: gomp_iter_dynamic_next (iter.c:190) > > Is a bogus warning as that is thread specific data: > struct gomp_thread *thr = gomp_thread

[Bug c++/40362] openmp: some libgomp functions trigger data races

--- Comment #4 from bart dot vanassche at gmail dot com 2009-06-07 06:52 --- (In reply to comment #3) > Except this is a false positive as thread 4 is not created when the thread 2 > writes to *thr. It looks like valgrind does not know what is happening here > really. I&#

[Bug c++/40362] openmp: some libgomp functions trigger data races

--- Comment #6 from bart dot vanassche at gmail dot com 2009-06-07 07:09 --- (In reply to comment #5) > You have to read the code to understand how that happens. > But basically GOMP_parallel_start does: > gomp_team_start (fn, data, num_threads, gomp_new_team (nu

[Bug c++/40362] openmp: some libgomp functions trigger data races

--- Comment #8 from bart dot vanassche at gmail dot com 2009-06-08 18:30 --- (In reply to comment #7) Thanks for the feedback. I'll use the above information to suppress the complaints on thr->ts.work_share->next_ws and will post the results here. -- http://gcc.gnu.o

[Bug c++/40362] openmp: some libgomp functions trigger data races

--- Comment #9 from bart dot vanassche at gmail dot com 2009-06-13 16:23 --- (In reply to comment #7) The patch below is sufficient to suppress all conflicting accesses reported by DRD. I've done my best to ensure that this patch is not only sufficient but also minimal. Although

[Bug c/40795] New: gcc generates incorrect code for inline assembly

assembly Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bart dot vanassche at gmail dot com GCC build triplet: x86_64-unknown

[Bug c/40795] gcc generates incorrect code for inline assembly

--- Comment #1 from bart dot vanassche at gmail dot com 2009-07-18 07:55 --- Created an attachment (id=18216) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18216&action=view) Test case source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40795

[Bug c/40795] gcc generates incorrect code for inline assembly

--- Comment #3 from bart dot vanassche at gmail dot com 2009-07-18 09:28 --- Created an attachment (id=18217) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18217&action=view) Test case source code Added "esp" to constraint list. -- http://gcc.gnu.org/bugz

[Bug c/40795] gcc generates incorrect code for inline assembly

--- Comment #4 from bart dot vanassche at gmail dot com 2009-07-18 09:29 --- Same result with "esp" added to constraint list. -- bart dot vanassche at gmail dot com changed: What|Removed

[Bug libgomp/35517] New: OpenMP: Incorrect result when run with two or more threads

: UNCONFIRMED Severity: major Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bart dot vanassche at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet

[Bug libgomp/35517] OpenMP: Incorrect result when run with two or more threads

--- Comment #1 from bart dot vanassche at gmail dot com 2008-03-09 19:58 --- Created an attachment (id=15286) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15286&action=view) Test program matinv_openmp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35517

[Bug libgomp/35517] OpenMP: Incorrect result when run with two or more threads

--- Comment #2 from bart dot vanassche at gmail dot com 2008-03-10 18:32 --- Everything works correctly after changing #pragma omp parallel for into #pragma omp parallel for private(j, k) -- bart dot vanassche at gmail dot com changed: What|Removed

[Bug bootstrap/35654] New: Native build of gcc 4.3.0 fails on 64-bit Ubuntu 7.10

iority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bart dot vanassche at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/sh

[Bug bootstrap/35654] Native build of gcc 4.3.0 fails on 64-bit Ubuntu 7.10

--- Comment #1 from bart dot vanassche at gmail dot com 2008-03-21 14:16 --- Created an attachment (id=15354) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15354&action=view) gcc compilation script -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35654

[Bug bootstrap/35654] Native build of gcc 4.3.0 fails on 64-bit Ubuntu 7.10

--- Comment #3 from bart dot vanassche at gmail dot com 2008-03-22 08:43 --- It would be nice if the configure script would print a comprehensible error message in case 32-bit libraries are not found on a 64-bit system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35654

[Bug other/23656] New: Cross-compilation with newlib fails in libiberty

-compilation with newlib fails in libiberty Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bart dot vanassche at gmail dot com

[Bug other/23656] Cross-compilation with newlib fails in libiberty

--- Additional Comments From bart dot vanassche at gmail dot com 2005-08-31 15:36 --- Created an attachment (id=9631) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9631&action=view) patch for gcc-3.4.4/libiberty/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug

[Bug c++/43163] New: gcc doesn't report uninitialized member variables

Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bart dot vanassche at gmail dot com GCC build triplet: i686-pc-cygwin GCC host tripl

[Bug c++/43163] gcc doesn't report uninitialized member variables

--- Comment #1 from bart dot vanassche at gmail dot com 2010-02-24 12:06 --- Created an attachment (id=19945) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19945&action=view) uninitialized-member-variable.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43163

[Bug c++/40059] "uninitialized" warning missed when uninitialized class member used as array index

--- Comment #1 from bart dot vanassche at gmail dot com 2010-02-24 11:46 --- gcc 4.3.4 doesn't complain about dereferencing uninitialized member variables either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40059

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #10 from bart dot vanassche at gmail dot com 2010-02-24 19:10 --- (In reply to comment #9) > I think there is no reasonable way to get reliable uninitialized variable > warnings for incoming pointed-to memory. The only way we can warn here > is by inlining the co

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #18 from bart dot vanassche at gmail dot com 2010-02-25 07:00 --- (In reply to comment #16) > (In reply to comment #14) > > > (In reply to comment #8) > > > > Incidentally, perhaps we should mark the this parameter as __restrict... > > >

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #19 from bart dot vanassche at gmail dot com 2010-02-25 07:05 --- (In reply to comment #17) > (In reply to comment #15) > > Alternatively, the C++ front-end could create an uninitialized variable for > > each member variable. Initialize those, then, at the

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

--- Comment #11 from bart dot vanassche at gmail dot com 2010-04-07 17:54 --- (In reply to comment #10) > I think this is for mainline only. In a couple of few weeks a I will give it a > second thought for 4_4-branch but certainly isn't a regression. Any status update

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

--- Comment #14 from bart dot vanassche at gmail dot com 2010-04-08 06:03 --- (In reply to comment #13) > I agree it's probably not worth backporting to a release branch, it wasn't a > regression. > > Haven't affected users written valgrind suppression

[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

--- Comment #18 from bart dot vanassche at gmail dot com 2010-04-08 10:28 --- (In reply to comment #12) > In my opinion it's too late now, I'm not even sure a 4.4.4 will be released > any > time soon, and 4.5.0 is around the corner. But if Jon would also like to s

[Bug c++/23296] Combination of -finstrument-functions and -O3 produces incorrect results

--- Additional Comments From bart dot vanassche at gmail dot com 2005-08-09 17:52 --- Subject: Re: Combination of -finstrument-functions and -O3 produces incorrect results Hello pinskia, Thanks for the info -- I recompiled the code with the extra option -fno-inline, and so I

[Bug libstdc++/26875] New: Array allocator use count is shared between array_allocator instances

atus: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bart dot vanassche at gmail dot com GCC build triplet: i586-suse-linux GCC host triplet: i586-suse-linux GCC target triplet: i586-

[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances

--- Comment #1 from bart dot vanassche at gmail dot com 2006-03-26 09:32 --- Created an attachment (id=11128) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11128&action=view) Non-preprocessed test code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26875

[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances

--- Comment #2 from bart dot vanassche at gmail dot com 2006-03-26 09:33 --- Created an attachment (id=11129) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11129&action=view) Preprocessed test source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26875

[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances

--- Comment #4 from bart dot vanassche at gmail dot com 2006-03-27 10:53 --- (In reply to comment #3) > Confirmed. Though it looks like this is a fundamental problem of the > interface > provided. Should be documented so though. Also destroying an array allocator > i

[Bug c++/29765] New: -Wparentheses does not warn on single equals sign inside if statement

dBy: bart dot vanassche at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29765