Mailinglist Archive: opensuse-bugs (6095 mails)

< Previous Next >
[Bug 1040589] bash/gcc/gzip/python differ between builds because of profiling
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 18 Apr 2018 07:46:10 +0000
  • Message-id: <bug-1040589-21960-13kvpAQgkG@http.bugzilla.suse.com/>
http://bugzilla.suse.com/show_bug.cgi?id=1040589
http://bugzilla.suse.com/show_bug.cgi?id=1040589#c8

--- Comment #8 from Richard Biener <rguenther@xxxxxxxx> ---
(In reply to Richard Biener from comment #7)
Honza, are you aware of any issue regarding reproducability of the final
.gcda files when merging results of multiple invocations? IIRC we use
file-locking to serialize the update but of course different parallel
program invocations might result in random order of merging. How can that
ever be an issue? Maybe for counter overflows? or some ordering of items
and then rippling down effects when the profile is read by -fprofile-use?

Looking at libgcov-merge.c there are several types of counters (most
value-profiling ones) that have merging routines that are sensitive to the
order
of merging. Some even look wrong to me (__gcov_merge_single - though
maybe counters[1] is just too little specified).

So it's not really "races" but for example when merging single-value
counters in the written order { 1, 2, 10 }, { 2, 4, 10 }, { 1, 4, 10 }
then we get { 2, 4, 30 } and in any other order we'd get { 1, 6, 30 }
Ok, not really, somehow we massage counter[1] to avoid this? Here
we'd go merging the 2nd into the first { 2, 2, 20 } and then merging in
the third { 1, 2, 30 }. When starting with the 2nd we'd go
{ 2, 2, 20 }, { 1, 2, 30 } so here it seems to "work" but I'd have a
hard time believing the simple "trick" makes the merging independent of
order.

Using _add for GCOV_COUNTER_AVERAGE also looks odd. Combining
200 1 and 20000 1 yields 20200 2 ...

--
You are receiving this mail because:
You are on the CC list for the bug.
< Previous Next >