noalias question

Richard Stallman rms@gnu.org
Wed Aug 25 16:13:00 GMT 1999


    Note that 3rd is illegal because we stored there through pc, an char * and
    we are going to access it again at 3rd through a int *. It is fine (AFAIU)
    if you store a char though pc and access it as a char later.  The point is
    that this is _hard_ (probably impossible in the general case) to detect for
    a compiler, so the compiler is allowed to assume that *pi does not change,
    since no accesses through an int * could have changed *pi. 

I remember this aspect of the ANSI spec, but I think that `char *' is
an exception--I think that it can alias with anything, and compilers
are supposed to take account of that.

Could someone check the actual specification?

    The main problem is that illegal accesses like above are used al
    over the place, e.g. in memcpy() and its ilk to speed them up (so they work
    with longs, not char by char). 

Hold on a second.  Are you talking about the way the code of memcpy is
written inside of Glibc?  How GCC compiles that should have no effect
on callers of memcpy, unless the function is declared inline.  Is it
declared inline?

GCC can inline-expand some block-copies; is that what you are talking
about?

				   Mostly harmless, but the resulting kernels
    on i586 don't boot because of code reordering of a memset() and setting a
    struct member that tells the booting kernel to initialize IDE intefaces ;-)

I wrote the handling of inline block copies to use whole words because
that is more efficient.  But logically if a certain block copy is a
byte-wise operation, it should be treated as a byte-wise operation for
aliasing purposes.

Any explicit call to memset in the user's code is nominally a function
call, which means it could refer to any part of memory in any data
type.  Therefore, it is wrong to reorder memory references through
an explicit call to memset, even if that call happens to be open-coded.
Aliasing must be treated as a legitimate possibility.

If this were fixed, would it entirely solve the problem?  Do all the
problem cases involve calls to memset and memcpy?  If not, what other
cases are concerned?




More information about the Gcc mailing list