>>> On 18.01.19 at 11:48, <julien.gr...@arm.com> wrote: > On 18/01/2019 09:54, Jan Beulich wrote: >>>>> On 18.01.19 at 02:24, <sstabell...@kernel.org> wrote: >>> On Thu, 17 Jan 2019, Jan Beulich wrote: >>>>>>> On 17.01.19 at 01:37, <sstabell...@kernel.org> 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 > RELOC_HIDE). > > 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" attribute). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
