http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834

--- Comment #6 from richard.guenther at gmail dot com <richard.guenther at 
gmail dot com> 2010-10-18 13:57:19 UTC ---
On Mon, Oct 18, 2010 at 3:53 PM, bmei at broadcom dot com
<gcc-bugzi...@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45834
>
> --- Comment #5 from Bingfeng Mei <bmei at broadcom dot com> 2010-10-18 
> 13:53:37 UTC ---
>>
>> Sure, but we have other means of dealing with that (MEM_ALIAS_SET == 0).
>
> Do you mean this check is redundant here ? I dig out the ancient code (from
> 1997)
>
>  /* If both references are struct references, or both are not, nothing
>     is known about aliasing.
>
>     If either reference is QImode or BLKmode, ANSI C permits aliasing.
>
>     If both addresses are constant, or both are not, nothing is known
>     about aliasing.  */
>  if (MEM_IN_STRUCT_P (x) == MEM_IN_STRUCT_P (mem)
>      || mem_mode == QImode || mem_mode == BLKmode
>      || GET_MODE (x) == QImode || GET_MODE (mem) == BLKmode
>      || varies (x_addr) == varies (mem_addr))
>    return 1;
>
> The comment indicates that the check for QImode is for meeting aliasing rule 
> of
> char type.

I just say that we have other means to test for "char", the check for QImode
is bogus.  But it might well be that removing it exposes bugs.

>>
>> > But I am not sure whether a
>> > restrict qualifier will override that rule.
>>
>> restrict is a different concept from type-based aliasing.
>>
> Sure, but in this example, on one hand, char type pointer is supposed to alias
> any other data type, on the other hand, all the char pointers have restrict
> qualifiers. What is correct behaviour, alias or not?

char aliases all types.  accesses through two different restrict qualified
pointers do not alias.

I don't see any conflict here.

> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

Reply via email to