--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2008-01-21 03:15 ---
Created an attachment (id=14984)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14984action=view)
The code that triggers the ICE
Just compile with -g -O2 to see the problem.
--
http
ReportedBy: theodore dot papadopoulo at sophia dot inria dot fr
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34895
--- Comment #4 from theodore dot papadopoulo at sophia dot inria dot fr
2007-08-09 12:02 ---
Created an attachment (id=14046)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14046action=view)
A new more minimal test case
The same program was still working with gcc version 4.3.0
...
--
Summary: Wrong optimisation
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: theodore dot papadopoulo at sophia
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2007-08-08 17:49 ---
Created an attachment (id=14043)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14043action=view)
The piece of code that shows the problem.
One more note. The bug seems related
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2007-07-17 09:55 ---
This is similar to the comment (maybe misplaced) of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
The problem, as far as I understand it is that any kind of profiling (gprof,
profile-arcs
--- Comment #2 from theodore dot papadopoulo at sophia dot inria dot fr
2007-07-17 10:11 ---
And to reply to myself, it needs either to use thread local storage to hold the
counters and then to add some piece of code to fuse the values of the various
counters at the end of a thread
--- Comment #11 from theodore dot papadopoulo at sophia dot inria dot fr
2007-06-04 18:12 ---
(In reply to comment #8)
I suspect (unless I'm overlooked something) that this problem cause wrong
statistics when using jointly the -fopenmp and -profile-* flags.
I tried that and seen
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2007-06-01 10:22 ---
Created an attachment (id=13644)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13644action=view)
The source code showing the potential bug
--
http://gcc.gnu.org/bugzilla
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: theodore dot papadopoulo at sophia dot inria dot fr
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2007-04-26 07:32 ---
This is a duplicate of PR 31598 (which was against 4.3 not 4.2).
Jakub Jelinek proposed a patch
(http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01572.html) that seems to be
accepted
--- Comment #4 from theodore dot papadopoulo at sophia dot inria dot fr
2007-04-26 07:32 ---
The patch at posted by Jakub
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01572.html
seems to resolve this bug. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31598
--- Comment #2 from theodore dot papadopoulo at sophia dot inria dot fr
2007-04-23 16:46 ---
(From update of attachment 13378)
Slightly simplified the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31598
--- Comment #3 from theodore dot papadopoulo at sophia dot inria dot fr
2007-04-23 17:01 ---
Sorry to have added you without asking Jakub, but it looks like you are one of
the person that deals with OpenMP and this bug seems to have been unnoticed
up to now...
It seems
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: theodore dot papadopoulo at sophia dot inria dot fr
GCC build triplet: i686-pc-linux-gnu
GCC
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2007-04-17 09:21 ---
Created an attachment (id=13378)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13378action=view)
The source code showing the potential bug
--
http://gcc.gnu.org/bugzilla
: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: theodore dot papadopoulo at sophia dot inria dot fr
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2005-12-06 17:39 ---
Created an attachment (id=10419)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10419action=view)
The code describing the regression.
Simplify compile with g++
--
http://gcc.gnu.org
--- Comment #3 from theodore dot papadopoulo at sophia dot inria dot fr
2005-12-06 18:46 ---
(In reply to comment #0)
The code attached does not compile since version 4.0 of gcc.
Remove either the Cpu namespace or one element in the enumeration or replace
the array size in RGBPixel
--- Comment #4 from theodore dot papadopoulo at sophia dot inria dot fr
2005-12-06 18:51 ---
(In reply to comment #2)
I may accept that g++ is right to reject this code. I cannot convince myself
from reading the standard but I'm not a langage lawyer. I think that this is a
major flaw
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: theodore dot papadopoulo at sophia dot inria dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet
--- Additional Comments From theodore dot papadopoulo at sophia dot inria
dot fr 2005-07-18 15:00 ---
Created an attachment (id=9301)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9301action=view)
The two function should give the same error message!!!
--
http://gcc.gnu.org
--- Additional Comments From theodore dot papadopoulo at sophia dot inria
dot fr 2005-07-18 15:26 ---
Subject: Re: Differing error messages depending on
thelocality of a variable
On Mon, 2005-07-18 at 15:12 +, bangerth at dealii dot org wrote:
--- Additional Comments
23 matches
Mail list logo
