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:

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

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:

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

[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

[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