C as used/implemented in practice: analysis of responses

[Peter Sewell]

On 26 June 2015 at 20:27, Joseph Myers <joseph@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
> joseph@codesourcery.com