[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <9F0C48F4-A62B-456C-9EBD-DB02026631D1@redhat.com>
Date: Fri, 15 Oct 2021 11:17:22 +0200
From: Christophe de Dinechin <cdupontd@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>,
Sean Christopherson <seanjc@...gle.com>,
Nathan Chancellor <nathan@...nel.org>,
Jim Mattson <jmattson@...gle.com>, torvic9@...lbox.org,
"vkuznets@...hat.com" <vkuznets@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"bp@...en8.de" <bp@...en8.de>
Subject: Re: [BUG] [5.15] Compilation error in arch/x86/kvm/mmu/spte.h with
clang-14
> On 14 Oct 2021, at 22:50, Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> On 14/10/21 21:06, Nick Desaulniers wrote:
>>> If we want to fix this, my vote is for casting to an int and updating the comment
>> At the least, I think bitwise operations should only be performed on
>> unsigned types.
>
> This is not a bitwise operation, it's a non-short-circuiting boolean operation. I'll apply Jim's suggestion.
What about making it an inline function, which would require evaluation of arguments:
static __always_inline bool BITWISE_BOOLEAN_OR(bool a, bool b)
{
return a || b; // Safe here, because arguments have been evaluated
}
Suggesting that because I'm always nervous about casts in macros hiding something that the type system would otherwise catch.
Christophe
>
> Paolo
>
Powered by blists - more mailing lists