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
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
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 for this
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
* c-family/c-common.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
* 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
* c-family/c-common.c (handle_no_instrument_function_attribute): Allow
no_instrument_function attribute in class member
definition/declaration.
Looking at the
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 gar
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:
res
rf regression in some testcases.
please advice.
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 Alfon
on the two tested targets : sh-superh-elf and
x86_64-unknown-linux-gnu.
Should I enter a bugzilla to track this ? Is it ok for trunk ?
2013-04-08 Laurent Alfonsi
* fold-const.c (fold_unary_loc): Suppress useless type promotion.
Thanks,
Laurent
#include
typedef char int8_t;
const
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
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
d_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
* src/c++98/mt_allocator.cc: Define/use an illegal t
Also, here is the Changelog :
2012-04-13 Laurent Alfonsi
PR libstdc++/52604
* src/mt_allocator.cc: (__freelist::~__freelist): Reset pointer.
All,
The attached patch re-initializes _M_thread_freelist in
__freelist::~__freelist just after calling
::operator delete(static_cast(_M_thread_freelist_array));
It avoids valgrind errors in __pool::_M_get_thread_id() later invoked.
Testcases :
ext/mt_allocator/deallocate_global_thread-
15 matches
Mail list logo
