[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 18.01.19 at 11:48, <julien.grall@xxxxxxx> wrote:
> On 18/01/2019 09:54, Jan Beulich wrote:
>>>>> On 18.01.19 at 02:24, <sstabellini@xxxxxxxxxx> wrote:
>>> On Thu, 17 Jan 2019, Jan Beulich wrote:
>>>>>>> On 17.01.19 at 01:37, <sstabellini@xxxxxxxxxx> wrote:
>>>>> On Wed, 16 Jan 2019, Jan Beulich wrote:
>> Stop. No. We very much can prove they are - _end points at
>> one past the last element of _start[]. It is the compiler which
>> can't prove the opposite, and hence it can't leverage
>> undefined behavior for optimization purposes.
> You keep saying the compiler can't leverage it for optimization purpose, 
> however 
> there are confirmations that GCC may actually leverage it (e.g [1]). You 
> actually need to trick the compiler to avoid the optimization (e.g 
> So obviously, this is not only a MISRA "problem" as you state here and 
> below.
> I believe Stefano, Stewart and I provided plenty of documentation/thread to 
> support our positions. Can you provide us documentation/thread showing the 
> compiler will not try to leverage that case?
> Cheers,
> [1] 
> https://kristerw.blogspot.com/2016/12/pointer-comparison-invalid-optimization.html?m=1

Btw., the __start[] / __end[] example given there does not match
up with what I see. Only symbols defined in the same CU as where
the comparison sits get "optimized" this way. Externs as well as
weak symbols defined locally don't get dealt with like this. And how
could they? Nothing tells the compiler that two distinct symbols
refer to two distinct objects. It is easy to create objects with
multiple names, not only in assembly but also in C (using the "alias"


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.