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

[Jan Beulich <jbeulich@xxxxxxxx>]

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