Hi Jan,
On 21/01/2019 09:34, Jan Beulich wrote:
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.
What you see in a specific version of GCC. This does not mean this behavior is
valid across all the released versions and future one.
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).
Similarly, nothing tells the compiler that they are not two distinct symbols.
You haven't yet provided evidence a compiler cannot use that for optimization.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
