https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
--- Comment #7 from Thomas Schwinge <tschwinge at gcc dot gnu.org> --- (In reply to jules from comment #6) > Please don't start making changes to the reference-counting code that is > being replaced by my overhaul patch. We first need to establish a stable baseline, with test cases, and then (or, as part of that) merge the several independent pieces of the big "OpenACC reference count overhaul". > The existing code was rewritten for a > reason -- that being, I hit various problems with it (albeit long since > forgotten) that interfered with the manual deep-copy implementation. So you'll have to dig out your notes, and/or we'll have to figure out any rationale again, now. Patches that change such fundamental things in libgomp we cannot just commit on the basis that once they made sense to somebody. They have to come with rationale, and test cases. > We have > refcount self-checking code for the overhauled code. ... which surely can be adapted. And, per my understanding, this is only checking libgomp internal consistency, but not the semantics exposed to users via OpenACC directives/API calls etc., which in part you're changing of your patch (without test cases). This, again, I've spent the best part of the past weeks understanding, writing test cases for, filing GCC PRs, resolving them one by one, independently, incrementally, comprehensibly. > We can address corner-case bug fixes as follow-ons once the main overhaul > patch is committed. Further bug fixes, yes, but we have to make some reasonable effort to not introduce new bugs with the big "OpenACC reference count overhaul" changes. It doesn't help if these changes go in, then the OpenACC 2.6 manual deep copy changes, but as part of that the dynamic reference counting behavior unexpectedly changes/breaks, for example.
