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. >