On 26 June 2015 at 20:27, Joseph Myers <jos...@codesourcery.com> wrote: > On Fri, 26 Jun 2015, Peter Sewell wrote: > >> > It's s simple matter of points-to analysis. &foo + anything may be >> > assumed (in practice) to point to something within foo (or just past the >> > end) and not to alias anything accessed through a pointer based on &bar. >> > If the compiler can see something like &foo + (&bar - &foo) there is no >> > guarantee of whether it will assume it to point within foo or bar and that >> > may not be consistent for different uses (so it may end up concluding the >> > pointer compares unequal to itself). >> >> Ok, that's fine in some (perhaps most) situations, but it's not >> compatible with what seems to be a significant body of systems code >> out there - people mentioned important usages in FreeBSD, Linux, QEMU, >> and other places. How can these be reconciled? We imagine: > > Does that code actually access the same object via both routes in code > that might get moved past each other (or values get reused because the > compiler didn't think they could have changed) as a consequence of the > points-to analysis? If the aliasing isn't visible, it's less likely to > cause problems.
It's a good question - quite possibly not, though it's hard to investigate; really we have no idea. But I'm not sure how we could state a condition like that precisely in some reasonable way, and if the conditions under which this is safe become too complex, that in itself becomes a failing in the language definition - at the end of the day, it has to be comprehensible. More generally, the programming-language design tradeoff between simplicity on the one hand and performance and expressivity on the other is always a difficult thing to manage. The wide range of opinions out there about what C behaviour can be relied on suggests that C may have veered too far to the latter in some respects. >> a) Compilation of that systems code could turn off this analysis (and >> whatever optimisation depends on it) entirely. What's the cheapest >> way to do that? > > I think -fno-tree-pta should disable it (I don't know what the cost of > that is). thanks, Peter > -- > Joseph S. Myers > jos...@codesourcery.com
