Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.19 at 16:41, <julien.grall@xxxxxxx> wrote:
> Hi Jan,
> 
> On 14/01/2019 10:11, Jan Beulich wrote:
>>>>> On 11.01.19 at 19:04, <sstabellini@xxxxxxxxxx> wrote:
>>> On Fri, 11 Jan 2019, Jan Beulich wrote:
>>>>>>> On 11.01.19 at 03:14, <sstabellini@xxxxxxxxxx> wrote:
>>>>> Hi Juergen, Jan,
>>>>>
>>>>> I spoke with Julien: we are both convinced that the unsigned long
>>>>> solution is best. But Julien also did some research and he thinks that
>>>>> Jan's version (returning pointer type) not only does not help with
>>>>> MISRA-C, but also doesn't solve the potential GCC problem either. A
>>>>> description of the GCC issue is available here:
>>>>>
>>>>>
>>> 
> https://kristerw.blogspot.com/2016/12/pointer-comparison-invalid-optimization 
> .h
>>> tml?m=1
>>>>
>>>> I've read through it, and besides not agreeing with some of the
>>>> author's arguments I wasn't able to spot where it tells me why/how
>>>> the suggested approach doesn't solve the problem.
>>>>
>>>>> (Also keep in mind that Linux uses the unsigned long solution to solve
>>>>> the GCC issue, deviating from it doesn't seem wise.)
>>>>
>>>> Which specific gcc issue (that is not solved by retaining type)?
>>>
>>> I am hoping Julien and his team will be able to provide the more
>>> decisive information next week for us to make a decision, but it looks
>>> like the issue is not clear-cut and people on the GCC list disagree on
>>> how it should be handled.
>>>
>>>
>>> The C standard says that "Two pointers compare equal if and only if both
>>> are null pointers, both are pointers to the same object (including a
>>> pointer to an object and a subobject at its beginning) or function, both
>>> are pointers to one past the last element of the same array object, or
>>> one is a pointer to one past the end of one array object and the other
>>> is a pointer to the start of a different array object that happens to
>>> immediately follow the first array object in the address space."
>>>
>>> In short, the compiler is free to return false in a pointer comparison
>>> if it believes that the pointers point to different non-consecutive
>>> object.
>> 
>> And it is this "it believes" which we undermine with the construct:
>> As long as the compiler can't prove two pointers point to different
>> objects, it can't eliminate the actual comparison.
> 
> May I ask where does this come from? A compiler could technically be free to 
> assume the inverse. I.e as long as it can't prove two pointers point to 
> different objects, it can rely on the undefined behavior to optimize it.

No. As long as there's a chance that both pointers point to the same
object, it can't do bad things, because _if_ they do, the result of the
comparison has to be correct (as per the text still quoted above).

Jan



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