[LLVMdev] C as used/implemented in practice: analysis of responses

[Joerg Sonnenberger]

On Thu, Jul 02, 2015 at 02:19:22PM -0700, Sean Silva wrote:
> On Thu, Jul 2, 2015 at 9:07 AM, Joerg Sonnenberger <joerg at britannica.bec.de>
> wrote:
> 
> > On Wed, Jul 01, 2015 at 04:06:45PM +0100, Peter Sewell wrote:
> > > - for some, OS developers are already routinely turning off
> > > optimisations for the sake of more predictable semantics, e.g. with
> > > fno-strict-aliasing.
> >
> > This one is interesting, because the biggest problem with strict
> > aliasing is that there is no standard compliant way to override it.
> > The most basic issue is how the allocator is supposed to work
> > internally. If you can fully inline malloc/free pairs, it is practically
> > impossible to avoid aliasing conflicts.
> >
> 
> I thought strict aliasing was more about types? I think memcpy is the
> standard escape hatch there. Generally speaking a fixed-size memcpy into a
> local variable is optimized down into the load/store that you want. This is
> e.g. how Support/Endian.h works. Yes, this is very awkward, and there might
> be some namespacing issues when writing memcpy itself though :)

It is about types, but with a malloc/free pair, the type of the same
pointer value can change. Imagine a simple stack like allocator, where
memory is reused iff the free happened in reverse order. That's simple
enough that a compiler can understand it and compute the value of the
pointers.

Joerg