Re: [Xen-devel] [PATCH] x86/dom0-build: fix build with clang5

[Jan Beulich <JBeulich@xxxxxxxx>]

On 15.07.2019 16:44, Tamas K Lengyel wrote:
> On Mon, Jul 15, 2019 at 8:13 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>
>> On 15.07.2019 15:41, Tamas K Lengyel wrote:
>>> On Mon, Jul 15, 2019 at 4:36 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>
>>>> With non-empty CONFIG_DOM0_MEM clang5 produces
>>>>
>>>> dom0_build.c:344:24: error: use of logical '&&' with constant operand 
>>>> [-Werror,-Wconstant-logical-operand]
>>>>        if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
>>>>                           ^  ~~~~~~~~~~~~~~~~~~
>>>> dom0_build.c:344:24: note: use '&' for a bitwise operation
>>>>        if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
>>>>                           ^~
>>>>                           &
>>>> dom0_build.c:344:24: note: remove constant to silence this warning
>>>>        if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
>>>>                          ~^~~~~~~~~~~~~~~~~~~~~
>>>> 1 error generated.
>>>>
>>>> Obviously neither of the two suggestions are an option here. Oddly
>>>> enough swapping the operands of the && helps, while e.g. casting or
>>>> parenthesizing doesn't. Another workable variant looks to be the use of
>>>> !! on the constant.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>> ---
>>>> I'm open to going the !! or yet some different route. No matter which
>>>> one we choose, I'm afraid it is going to remain guesswork what newer
>>>> (and future) versions of clang will choke on.
>>>
>>> Is disabling the check itself not an option? Seems to me to be a more
>>> sensible option then hacking around it.
>>
>> How would you envision to disable the check? It's there for a reason
>> after all.
> 
> By passing -Wno-constant-logical-operand to the compiler. It looks
> like a check for a non-common situation which evidently Xen uses, so
> what's the point of keeping it but hacking around with it with tricks
> that are fragile?

Oh, so you meant disabling the compiler warning. That may be an option,
but I wouldn't routinely suggest such as often besides unhelpful
instances there are also helpful ones.

Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel