Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: laurent.alfonsi at st dot com
Target Milestone: ---
Created attachment 39695
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39695&action=edit
te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602
--- Comment #8 from Laurent Aflonsi ---
Jeffrey,
As you asked for, I have performed much more testing on that fix.
I am far from having done as many tests as Jakub in 2004. In particular, I have
not been able to test on ppc/iaxx, because i don'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602
--- Comment #5 from Laurent Aflonsi ---
Ping ?
Is this ok for trunk ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49718
Laurent Aflonsi changed:
What|Removed |Added
CC||laurent.alfonsi at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602
--- Comment #4 from Laurent Aflonsi ---
When the .gcno graph file is opened for generating the coverage graph
information, the mode used is w+ as this code is shared with updating tools
such as libgcov. Thus, when GCC outputs .gcno files, it may l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602
--- Comment #3 from Laurent Aflonsi ---
Created attachment 31086
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31086&action=edit
source patch for trunk
-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: laurent.alfonsi at st dot com
Created attachment 30950
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30950&action=edit
script to reproduce
Gcc doesnot clean the .gcno file before writing in. Thus, it might
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #61 from Laurent Aflonsi ---
Yes that's the point. L3 can be reached by another block (L2):
tstr2,r2
mov#-1,r2
negcr2,r2
.L3:
tstr2,r2
bt/s.L11
[...]
.L2:
mov.l@r4,r2
tst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #59 from Laurent Aflonsi ---
I have a functional regression due to this improvement when we are compiling
the enclosed example in -O2.
$ sh-superh-elf-gcc -O2 pr51244-20-main.c pr51244-20.c
$ sh-superh-elf-run a.out
FAIL
Thus, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
Laurent Aflonsi changed:
What|Removed |Added
CC||laurent.alfonsi at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56894
--- Comment #1 from Laurent Aflonsi 2013-04-09
15:23:16 UTC ---
Created attachment 29842
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29842
testcase to reproduce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56894
Bug #: 56894
Summary: performance regression in gcc 4.7.x due to a +=
operation
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #18 from Laurent Aflonsi 2012-04-13
12:00:21 UTC ---
Author: chrbr
Date: Fri Apr 13 11:44:13 2012
New Revision: 186414
Log Message:
PR:52604: (~__freelist): Reset pointer
Modified:
trunk/libstdc++-v3/ChangeLog
t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #19 from Laurent Aflonsi 2012-04-13
12:00:44 UTC ---
Author: chrbr
Date: Fri Apr 13 11:58:15 2012
New Revision: 186415
Log Message:
fix last entry
Modified:
trunk/libstdc++-v3/ChangeLog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #14 from Laurent Aflonsi 2012-04-13
09:46:24 UTC ---
Thanks very much Paolo.
Here it is. I'll commit the patch in the mainline if no objection.
Laurent
2012-04-13 Laurent Alfonsi
PR libstdc++/52604
* src/mt_allocator.cc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #12 from Laurent Aflonsi 2012-04-12
21:55:42 UTC ---
Thanks very much Paolo. It works fine on SH4 also.
Is that enough to push the patch ?
Laurent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #9 from Laurent Aflonsi 2012-04-12
15:05:25 UTC ---
Paolo,
I ve discovered that the encoding of M_key is encoded differently for each
thread-implementation. On pthread implementation M_key is an integer, whereas
on others it is point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #7 from Laurent Aflonsi 2012-04-10
15:28:07 UTC ---
Ping ? Here is the patch proposed.
--- libstdc++-v3/src/mt_allocator.cc2011/08/04 07:56:492064
+++ libstdc++-v3/src/mt_allocator.cc2012/04/0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #6 from Laurent Aflonsi 2012-03-23
11:06:57 UTC ---
Sorry for the late answer (sickness).
Well, In fact there are 2 things in the atexit list :
1) The destruction of the "list_type" global variable. Destructor is :
"std::list > >:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #3 from Laurent Aflonsi 2012-03-20
12:31:31 UTC ---
Well, in fact I am facing a runtime crash on another target (SH4). The crash is
fixed by the patch proposed previously.
On the other hand, I ve tried to reproduce on x86, to easily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #1 from Laurent Aflonsi 2012-03-16
15:25:23 UTC ---
I would propose to fix as follows :
- Set the _M_Key=NULL when calling the freelist desctuctor.
- Testing the NULL Key before using it with setspecific.
see patch below :
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
Bug #: 52604
Summary: mt allocator crashes on multi-threaded
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P
22 matches
Mail list logo
