On 30/09/14 22:18 +0200, François Dumont wrote:
Hi
I prefer to submit this patch to you cause I am not very
comfortable with Python stuff.
I simply rely on Python cast feature. It doesn't really matter but
is it going to simply consider the debug iterator as a normal one or
Yes.
is
Hi
I prefer to submit this patch to you cause I am not very
comfortable with Python stuff.
I simply rely on Python cast feature. It doesn't really matter but
is it going to simply consider the debug iterator as a normal one or is
it going through the C++ explicit cast operator on deb
I forgot to check pretty printer tests indeed, I will.
François
On 30/09/2014 17:32, Jonathan Wakely wrote:
On 26/09/14 11:05 +0100, Jonathan Wakely wrote:
On 26/09/14 00:00 +0200, François Dumont wrote:
Apart from those minor adjustments I think this looks good, but I'd
like to know that i
On 26/09/14 11:05 +0100, Jonathan Wakely wrote:
On 26/09/14 00:00 +0200, François Dumont wrote:
Apart from those minor adjustments I think this looks good, but I'd
like to know that it has been tested with -fsanitize=thread, even if
only lightly tested.
Hi
Dmitry, who reported the bug,
On 26/09/14 00:00 +0200, François Dumont wrote:
Apart from those minor adjustments I think this looks good, but I'd
like to know that it has been tested with -fsanitize=thread, even if
only lightly tested.
Hi
Dmitry, who reported the bug, confirmed the fix. Can I go ahead
and commit ?
Apart from those minor adjustments I think this looks good, but I'd
like to know that it has been tested with -fsanitize=thread, even if
only lightly tested.
Hi
Dmitry, who reported the bug, confirmed the fix. Can I go ahead and
commit ?
François
On Tue, Sep 23, 2014 at 10:42:31PM +0200, François Dumont wrote:
> No I hadn't and try since but without success. When I build with
> -fsanitize=thread the produced binary just segfault at startup. It
> complained about using -fPIE at compilation time and -lpie at link time but
> even with those op
On 22/09/2014 00:04, Jonathan Wakely wrote:
On 10/09/14 22:55 +0200, François Dumont wrote:
Hi
Here is a proposal to fix this data race issue.
I finally generalized bitset approach to fix it by inheriting from
the normal iterator first and then the _Safe_iterator_base type. None
of the
On 10/09/14 22:55 +0200, François Dumont wrote:
Hi
Here is a proposal to fix this data race issue.
I finally generalized bitset approach to fix it by inheriting from
the normal iterator first and then the _Safe_iterator_base type. None
of the libstdc++ iterator types are final so it is
Hi
Here is a proposal to fix this data race issue.
I finally generalized bitset approach to fix it by inheriting from
the normal iterator first and then the _Safe_iterator_base type. None of
the libstdc++ iterator types are final so it is fine. Surprisingly,
despite inheritance being
10 matches
Mail list logo
