On Fri, 2016-08-05 15:43:02 +0200, Martin Liška wrote:
[...]
> Great, attaching install candidate.
> >From 0b3ac8636ef34b02e301f22c86dde0602f9969ef Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Thu, 28 Jul 2016 14:32:47 +0200
> Subject: [PATCH 1/4] Cherry-pick fprofile-ge
On 08/05/16 09:43, Martin Liška wrote:
On 08/05/2016 03:14 PM, Nathan Sidwell wrote:
On 08/05/16 08:48, Martin Liška wrote:
Ok, after all the experimenting and inventing "almost" thread-safe code, I
incline to not to include __gcov_one_value_profiler_body_atomic
counter. The final solution is
agree, I'll prepare a final version of patch?
>
> Agreed.
>
> nathan
>
Great, attaching install candidate.
Martin
>From 0b3ac8636ef34b02e301f22c86dde0602f9969ef Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 28 Jul 2016 14:32:47 +0200
Subject: [PATCH 1/4] Cherry-pick f
On 08/05/16 08:48, Martin Liška wrote:
Ok, after all the experimenting and inventing "almost" thread-safe code, I
incline to not to include __gcov_one_value_profiler_body_atomic
counter. The final solution is cumbersome and probably does not worth doing.
Moreover, even having a thread-safe imp
On 08/05/2016 02:38 PM, Nathan Sidwell wrote:
> On 08/05/16 04:55, Martin Liška wrote:
>
>> Thank you for very intensive brainstorming ;) Well I still believe that
>> following code
>> is not thread safe, let's image following situation:
>>
>
> yeah, you're right.
>
>>> we could do better by us
On 08/05/16 04:55, Martin Liška wrote:
Thank you for very intensive brainstorming ;) Well I still believe that
following code
is not thread safe, let's image following situation:
yeah, you're right.
we could do better by using compare_exchange storing value, and detect the race
I mentione
On 08/04/2016 07:03 PM, Nathan Sidwell wrote:
> On 08/04/16 12:43, Nathan Sidwell wrote:
>
>> How about:
>> gcov_t expected;
>> atomic_load (&counter[0], val, ...);
>> gcov_t delta = val == value ? 1 : -1;
>> atomic_add (&counter[1], delta); <-- or atomic_add_fetch
>> if (delta < 0) {
>> /* c
On 08/04/16 12:43, Nathan Sidwell wrote:
How about:
gcov_t expected;
atomic_load (&counter[0], val, ...);
gcov_t delta = val == value ? 1 : -1;
atomic_add (&counter[1], delta); <-- or atomic_add_fetch
if (delta < 0) {
/* can we set counter[0]? */
atomic_load (&counter[1], &expected, ...);
On 08/04/16 11:34, Martin Liška wrote:
On 08/04/2016 04:48 PM, Nathan Sidwell wrote:
diff --git a/libgcc/libgcov-profiler.c b/libgcc/libgcov-profiler.c
+static inline void
+__gcov_one_value_profiler_body_atomic (gcov_type *counters, gcov_type value)
+{
...
The body looks to have data races. So
On 08/04/2016 04:48 PM, Nathan Sidwell wrote:
> diff --git a/libgcc/libgcov-profiler.c b/libgcc/libgcov-profiler.c
> +static inline void
> +__gcov_one_value_profiler_body_atomic (gcov_type *counters, gcov_type value)
> +{
> ...
>
> The body looks to have data races. Some kind of cmp_store needed
On 08/01/16 09:29, Martin Liška wrote:
I also added a small hunk that describes problematic of app having not-joined
(or detached) threads,
can you please take a look at documentation change, maybe it would need some
transformation?
sorry for the tady response,thanks for the ping.
In genera
tunningly similar.
Fixed.
I also added a small hunk that describes problematic of app having not-joined
(or detached) threads,
can you please take a look at documentation change, maybe it would need some
transformation?
Martin
>
> nathan
>From 7e19e28f3d6e227bb67fb770575831d637abe3a
As I just wrote, this patch needs work. the general points are:
1) exposing integers 0-3 to the user as switch values. Don't do that, give them
names. In this case a comma separated list of orthogonal names seems
appropriate. But see below.
2) Poor documentation. How might the user might
libgcc/ChangeLog:
2016-07-28 Martin Liska
* Makefile.in: Add functions to LIBGCOV_PROFILER.
* libgcov-profiler.c (__gcov_one_value_profiler_body_atomic):
New function.
(__gcov_one_value_profiler_atomic): Likewise.
(__gcov_indirect_call_profiler_v2): Fix
14 matches
Mail list logo
