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

[Julien Grall <julien.grall@xxxxxxx>]

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.
Cheers,

--
Julien Grall

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