On 18.11.2021 10:34, Roger Pau Monné wrote: > On Thu, Nov 18, 2021 at 09:51:52AM +0100, Jan Beulich wrote: >> On 18.11.2021 09:33, Roger Pau Monné wrote: >>> On Thu, Nov 04, 2021 at 01:17:53PM +0100, Jan Beulich wrote: >>>> On 04.11.2021 11:48, Andrew Cooper wrote: >>>>> If your answer is "well actually, we didn't mean to say 'if a GSI is >>>>> mapped' in the comment, and here's a different predicate which actually >>>>> inspects the state of a dpci object for validity", then fine - that >>>>> will shut the compiler up because you're no longer checking for the >>>>> NULLness of a pointer to a sub-object of a non-NULL pointer, but that's >>>>> a bugfix which needs backporting several releases too. >>>>> >>>>> The current logic is not correct, and does not become correct by trying >>>>> pass blame to the compiler. >>>> >>>> I have yet to understand in which way you deem the current logic to not >>>> be correct. I'm sorry for being dense. >>>> >>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967 is the GCC bug, but >>>>> the result of it was them persuading me that the diagnostic was >>>>> legitimate, even if currently expressed badly. They've agreed to fix >>>>> how it is expressed, but I doubt you'll persuade them that the trigger >>>>> for the diagnostic in the first place was wrong. >>>> >>>> Well, thanks for the pointer in any event. I've commented there as well. >>> >>> Did we get any resolution out of this? >> >> I don't think we did. I'm still struggling to understand Andrew's way >> of thinking. > > What about the GCC bug report? > > Ultimately we need GCC people to make the check less restrictive or we > need a way to rework the code in a way that doesn't trigger it, either > Andrew's proposal or something else. > >>> It would be good IMO if we could build out of the box with GCC 12 >>> instead of having to backport fixes later on. >> >> I guess gcc12 is too far from getting released that there could be any >> guarantee for no further issues to get exposed by that point. It has >> also been common for us to backport fixes and workarounds when new >> compiler versions appear. >> >> I could agree to being proactive if the change to make to our code was >> uncontroversial. > > OK, but unless GCC changes their mind we are likely to have this > conversation again in the future, so we might be just delaying the > inevitable.
Yes, but we apparently need time to settle on how to work around the issue. I was actually surprised Andrew was able to talk you into going the chosen route despite your open-coding concerns, which I share. In the course of the discussion at least one alternative approach was already outlined, iirc. Jan
