Re: DR#236 analysis

[Paul Schlie <schlie at comcast dot net>]

> From: Paul Brook <paul@codesourcery.com>
>> 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

Yes, but at the programmers discretion (as a consequence of the actual use
of pointers, as opposed to it being forbidden) which seems like a reasonable
tradeoff if one subscribes to the philosophy that the programmer should be
given the latitude to get the job done as desired (within reason)?

WRT library alias attributes, might it be reasonably possible to record the
function's argument alias attributes in an information section within the
compiled library which may be subsequently referenced by the compiler as
necessary? (although do understand such a thing doesn't presently exist)