Re: [PATCH for-4.16] x86/passthrough: Fix hvm_gsi_eoi() build with GCC 12

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.

Thanks, Roger.