Description of problem: This package is showing ABI changes which need your attention. Note that this package is on ABI compatibility list [1] in level 1. The ABI changes were tested using libabigail - abipkgdiff [2], only for subpackage: libgomp See http://gov-cert.brq.redhat.com/abidiff/results/level1_72vs70/72vs70_gcc-4.8.2-16.el7_vs_gcc-4.8.5-4.el7_libgomp.txt for detailed results from the scan. Note that the results are merged for all architectures, thus there can be some duplicity. To reproduce the issue run the abipkgdiff on the reported package libgomp: $ abipkgdiff --d1 OLD_DEBUGINFO --d2 NEW_DEBUGINFO OLD_RPM NEW_RPM See the tool documentation for more information [2]. ***What is action is required from the assignee of this bugzilla?*** Please review the results and, in the case of a bug, resolve the ABI breakage ASAP in the next RHEL-7 release. In the case that all ABI changes are expected, please close this bugzilla as NOTABUG. Version-Release number of selected component (if applicable): gcc-4.8.5-4.el7 How reproducible: 100% Actual results: http://gov-cert.brq.redhat.com/abidiff/results/level1_72vs70/72vs70_gcc-4.8.2-16.el7_vs_gcc-4.8.5-4.el7_libgomp.txt Expected results: No issues or all issues expected (after your review) Additional info: [1] https://access.redhat.com/sites/default/files/attachments/rhel7_app_compatibility_wp.pdf [2] https://sourceware.org/libabigail/manual/abipkgdiff.html
*** Please, when closing bug as NOTABUG, provide a short justification ****
The change is in addition of symbols (backwards compatible) and GOMP_task indeed has added a parameter, which looks like ABI incompatible change, but we rely on knowledge of the ABI calling conventions of the arches we care about and the new argument is only used if a new bit is set in a preexisting bitmask argument, where old code would have always a 0 bit at that spot. Thus, this is an upstream known ABI backward compatible change (though, admittedly not really super clean, so it is ok that ABI diff flags it).