This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: DR#236 analysis
- From: Paul Brook <paul at codesourcery dot com>
- To: gcc at gcc dot gnu dot org
- Cc: Paul Schlie <schlie at comcast dot net>
- Date: Sat, 4 Dec 2004 02:07:24 +0000
- Subject: Re: DR#236 analysis
- Organization: CodeSourcery
- References: <BDD670A8.8217%schlie@comcast.net>
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