DR#236 analysis

Paul Brook paul@codesourcery.com
Sat Dec 4 02:07:00 GMT 2004


On Saturday 04 December 2004 00:36, Paul Schlie wrote:
> > Geoff Keating writes:
> > I see. Yes, that's not what I meant. In this case, the type of the
> > malloc-ed memory is 'struct elf_link_hash_entry', and that's what's not
> > allowed to change; what I want prohibited is code like:
> >
> >  void * mem = malloc (max (sizeof (int), sizeof (float));
> >  *(int *)mem = 1;
> >  *(float *)mem = 2.0;
> >
> > where the top-level type of the memory changes.
>
> What's wrong with conservatively assuming that a pointer may alias
> cumulatively any object type if ever explicitly dereferences, where
> a dereferenced union is equivalent to it's cumulative set of types.)
>
>  (i.e. logical equivalent to your example, mem :: int*, float*, or void*)
>
> Where then if someone wants to take advantage of potential optimizations;
> they should use pointers conservatively, and ideally explicitly declare
> them as not being aliased if enabled by the language.
>
> As it would seem to be better to be safe than sorry, and not unnecessarily
> restrict programmers to accomplish what they want to do, with the
> understanding that there may be consequences to their decisions.

It's called -fno-strict-aliasing.

The scheme you suggest rapidly degenerates to this because without whole 
program analysis we have to assume that third party libraries could violate 
aliasing rules. Cases where we can show pointers don't escape aren't 
particularly interesting because we can (should be able to?) prove those 
without using type based aliasing.

Paul



More information about the Gcc mailing list