Type based aliasing

Type based aliasing

[Nathan Sidwell]

Hi,
Do C's type based aliasing rules mean the following?
	void foo (int *ip, float *fp)
	{
		if (ip == fp)
			this_is_unreachable ()
	}

I vaguely remember some discussion about this, but can't remember the
conclusion. Presumably IP & FP could point to members of the same union.

(f77 has code like the above, where the condition may or may not be false.)

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: Type based aliasing

[Michael Matz]

Hi,

On Wed, 2 Oct 2002, Nathan Sidwell wrote:

> Hi,
> Do C's type based aliasing rules mean the following?
> 	void foo (int *ip, float *fp)
> 	{
> 		if (ip == fp)
> 			this_is_unreachable ()
> 	}

Why should it?  The accessed values are 'ip' and 'fp' itself and they are
accessed through their effective type.  So 6.5.7 is fullfilled, ergo the
accesses to 'ip' and 'fp' are defined.  The compare itself is Ok, as even
if everything breaks, one of the two pointer can be converted to the other
pointer type, which is only undefined, if alignment rules of that type are
not followed.


Ciao,
Michael.

Re: Type based aliasing

[Michael Matz]

Hi,

On Wed, 2 Oct 2002, Nathan Sidwell wrote:

> 	void foo (int *ip, float *fp)
> 	{
> 		if (ip == fp)
> 			this_is_unreachable ()
> 	}

A followup to my last mail.  Think about this:

void bar ()
{
  int i;
  int *ip = &f;
  foo ( ip, (float *)ip);
}

Suppose, that in your foo() for the compare 'fp' is casted to 'int*'
(maybe because it has looser alignment).  Then it's required per
6.3.2.3 #7 to compare equal to the original pointer, which is ip.


Ciao,
Michael.

Re: Type based aliasing

[Toon Moene]

Nathan Sidwell wrote:

> Do C's type based aliasing rules mean the following?
>     void foo (int *ip, float *fp)
>     {
>         if (ip == fp)
>             this_is_unreachable ()
>     }
> 
> I vaguely remember some discussion about this, but can't remember the
> conclusion. Presumably IP & FP could point to members of the same union.
> 
> (f77 has code like the above, where the condition may or may not be false.)

Fortran rules don't allow arguments (which are references in g77) to 
overlap at all, so in this case, g77 would just assume (without 
checking) that *ip and *fp wouldn't overlap.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Type based aliasing

[Nathan Sidwell]

Toon Moene wrote:

>> (f77 has code like the above, where the condition may or may not be 
>> false.)
> 
> 
> Fortran rules don't allow arguments (which are references in g77) to 
> overlap at all, so in this case, g77 would just assume (without 
> checking) that *ip and *fp wouldn't overlap.
yes.Sorry to be unclear, the f77 front end has such (C) code. I will
provide the obvious patch to inhibit the warning.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: Type based aliasing

[Robert Dewar]

<<Fortran rules don't allow arguments (which are references in g77) to
overlap at all, so in this case, g77 would just assume (without
checking) that *ip and *fp wouldn't overlap.
>>

Is that really true? I thought the rule was that if there is any aliasing
then assignment by any alias path is forbidden (this certainly was the
original rule in Fortran, it might have changed, but that would surprise me).

Re: Type based aliasing

[Toon Moene]

Robert Dewar wrote:

> <<Fortran rules don't allow arguments (which are references in g77) to
> overlap at all, so in this case, g77 would just assume (without
> checking) that *ip and *fp wouldn't overlap.

> Is that really true? I thought the rule was that if there is any aliasing
> then assignment by any alias path is forbidden (this certainly was the
> original rule in Fortran, it might have changed, but that would surprise me).

The rule is that you can't `define' a dummy argument that's 
argument-associated with another dummy argument.

`Define' in Fortran-speak is to `have a value assigned to it and all of 
the entities that are associated with it'.

Assignment is one way to cause problems here, but not the only one.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Type based aliasing

[Robert Dewar]

<<`Define' in Fortran-speak is to `have a value assigned to it and all of
the entities that are associated with it'.

Assignment is one way to cause problems here, but not the only one.
>>

OK, sure, I was using assignment loosely, but the statement that "Fortran
rules don't allow arguments to overlap at all" is definitely misleading,
since it is just fine for arguments to overlap providing that no definitions
occur in an aliased situation.

Re: Type based aliasing

[Toon Moene]

Robert Dewar wrote:

> <<`Define' in Fortran-speak is to `have a value assigned to it and all of
> the entities that are associated with it'.
> 
> Assignment is one way to cause problems here, but not the only one.

> OK, sure, I was using assignment loosely, but the statement that "Fortran
> rules don't allow arguments to overlap at all" is definitely misleading,
> since it is just fine for arguments to overlap providing that no definitions
> occur in an aliased situation.

Yep, this is definitely true and might by worth stressing.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Type based aliasing

[Robert Dewar]

>>Yep, this is definitely true and might by worth stressing.

I always thought that this was a clever way of dealing with aliasing. Very
precisely defined, and you could in fact add run time checks for this if you
wanted.