--- 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
--- 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
--- 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
--- 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
--- 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...
> >
>
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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&#
--- 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
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
--- 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
--- 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
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
--- 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
--- 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
: 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
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
--- 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
--- 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
--- 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
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-
--- 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
-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
--- 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
33 matches
Mail list logo
