Jeff, All,
As you suggested, I have extended my testing around this fix to prevent
race condition issues.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602#c8
All my tests passed successfully. Is it ok for trunk ?
Thanks,
Laurent
On 10/03/13 17:01, Laurent Alfonsi wrote:
Hi All,
We
Perfect. Thanks very much for the commit.
Regards,
Laurent
On 01/15/14 20:25, Jeff Law wrote:
On 01/09/14 07:17, Laurent Alfonsi wrote:
On 01/09/14 06:02, Jeff Law wrote:
On 01/08/14 02:05, Laurent Alfonsi wrote:
All,
I was looking at PR49718. I have enclosed a simple fix
Ping ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602
As a reminder, that prevent running lcov on kernel side.
http://sourceforge.net/p/ltp/mailman/message/31141937/
Thanks
Laurent
On 10/03/13 17:01, Laurent Alfonsi wrote:
Hi All,
We have discovered a bug on gcno file generation
Ping ? Ok for trunk ?
On 01/09/14 15:17, Laurent Alfonsi wrote:
On 01/09/14 06:02, Jeff Law wrote:
On 01/08/14 02:05, Laurent Alfonsi wrote:
All,
I was looking at PR49718. I have enclosed a simple fix for this bug
report.
2014-01-07 Laurent Alfonsi laurent.alfo...@st.com
* c
On 01/09/14 06:02, Jeff Law wrote:
On 01/08/14 02:05, Laurent Alfonsi wrote:
All,
I was looking at PR49718. I have enclosed a simple fix for this bug report.
2014-01-07 Laurent Alfonsi laurent.alfo...@st.com
* c-family/c-common.c (handle_no_instrument_function_attribute): Allow
All,
I was looking at PR49718. I have enclosed a simple fix for this bug report.
2014-01-07 Laurent Alfonsi laurent.alfo...@st.com
* c-family/c-common.c (handle_no_instrument_function_attribute): Allow
no_instrument_function attribute in class member
definition/declaration
Hi All,
We have discovered a bug on gcno file generation registred as PR58602.
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 leave
The patch well fix the adobe_cpp performance regression on the int8_t
type. But the same degradation exists on uint8_t type, which is not
fixed by the patch referenced in PR53676.
With the signed version, the code:
result_5 = (signed char) ((int) result_2 + 2)
is now well narrowed to:
.
Also, I didn't find the bugzilla that led to this change of the +=
operation. I would be interested to have a look at it, if you can find it.
Thanks
Laurent
On 09.04.2013 10:50, Richard Biener wrote:
On Mon, Apr 8, 2013 at 9:13 PM, Laurent Alfonsi laurent.alfo...@st.com wrote:
Hello,
I
.
Should I enter a bugzilla to track this ? Is it ok for trunk ?
2013-04-08 Laurent Alfonsi laurent.alfo...@st.com
* fold-const.c (fold_unary_loc): Suppress useless type promotion.
Thanks,
Laurent
#include cstdio
typedef char int8_t;
const int iterations = 20;
const int SIZE = 200
Thanks very much Paolo.
I'll apply this patch on my side for a while.
I ll tell you if i see anything strange.
Regards,
Laurent
On 04/19/12 17:52, Paolo Carlini wrote:
On 04/19/2012 05:02 PM, Laurent Alfonsi wrote:
Well, I don't know mt_allocator enough to know if this is a fix for
real
All,
The attached patch re-initializes _M_thread_freelist in
__freelist::~__freelist just after calling
::operator delete(static_castvoid*(_M_thread_freelist_array));
It avoids valgrind errors in __pooltrue::_M_get_thread_id() later invoked.
Testcases :
*)arg);
pthread_exit (0);
}
int main()
{
pthread_t th1;
if (pthread_create (th1, NULL, my_thread_process, (void*)1) 0) {
fprintf (stderr, pthread_create error for thread 1\n);
exit (1);
}
l.push_back(bayou bend);
return 0;
}
2012-04-19 Laurent Alfonsi laurent.alfo...@st.com
Well, I don't know mt_allocator enough to know if this is a fix for real
or a quick fix.
Regards,
Laurent
On 04/19/12 16:26, Paolo Carlini wrote:
Hi,
All,
The enclosed testcases (very close to
ext/mt_allocator/deallocate_global_thread-1.cc) exposes a pattern
where the following sequence
14 matches
Mail list logo
