Re: [Rpm-maint] [rpm-software-management/rpm] Fix data race in packageBinaries() function (#1264)

2020-06-17 Thread Tom Stellard
@pmatilai Do you want me to re-submit this pull request with your suggested fix?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1264#issuecomment-645700387___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Fix data race in packageBinaries() function (#1264)

2020-06-15 Thread Tom Stellard
> Okay, the problem is fairly obvious, pkg being declared way outside the 
> parallel block.
> But rather than sprinkling more OpenMP magic dust to solve it, can you verify 
> that this (ie just declare the variable inside the parallel block) solves the 
> problem?
> 
> ```
>  #pragma omp single
>  for (int i = 0; i < npkgs; i++) {
> -   pkg = tasks[i];
> +   Package pkg = tasks[i];

I just checked and doing this also fixes the bug.

> #pragma omp task untied priority(i)
> {
> pkg->rc = packageBinary(spec, pkg, cookie, cheating, >filename);
> ```



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1264#issuecomment-644201067___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Make the "rpmbuild debuginfo -g3 .debug_macro" test an expected fail … (#1267)

2020-06-15 Thread Tom Stellard
Would it be possible to backport this to the 4.16 branch?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1267#issuecomment-644187292___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Make the "rpmbuild debuginfo -g3 .debug_macro" test an expected fail … (#1267)

2020-06-11 Thread Tom Stellard
After more investigation, I discovered the the .debug_macro section is not a 
DWARF5 feature and is supported by clang when using the -fdebug-macro option.  
I've updated the spec file for this test to use this option when building with 
clang.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1267#issuecomment-643010658___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] Make the "rpmbuild debuginfo -g3 .debug_macro" test an expected fail … (#1267)

2020-06-10 Thread Tom Stellard
…when using clang

This relies on a DWARF5 feature which clang = 10 does not support.
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/1267

-- Commit Summary --

  * Make the rpmbuild debuginfo -g3 .debug_macro test an expected 
fail when using clang

-- File Changes --

M tests/rpmbuild.at (2)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1267.patch
https://github.com/rpm-software-management/rpm/pull/1267.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1267
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] Fix data race in packageBinaries() function (#1264)

2020-06-09 Thread Tom Stellard
The pkg variable used in the parallel loop was declared outside
of the omp parallel construct, so it was shared among tasks.  This
had the potential to cause a data race.  The gcc openmp implementation
did not hit this problem, but I uncovered it while trying to compile with
clang.  My best guess as to what was happening is that after the last
task was launched, all tasks had the same value of pkg and were operating
on the same data at the same time.

This patch marks the variable as firstprivate, so each tasks gets its
own copy of the variable.
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/1264

-- Commit Summary --

  * Fix data race in packageBinaries() function

-- File Changes --

M build/pack.c (2)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1264.patch
https://github.com/rpm-software-management/rpm/pull/1264.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1264
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint