Andy Wingo <[email protected]> writes: > But OK, the question here is, what if another thread is concurrently > mutating X and Y? If this were C++ or Java, the answer would be that > they can still fold, because access to a multithreaded mutable needs > to be synchronized. I think this is reasonable. What do you think?
You don't even need multithreading for undefined effects of sequence ordering in C/C++. i = i++; is already undefined. Scheme has several non-guarantees regarding execution order as well (like the order in which function arguments will get evaluated). History time: Fortran specifies that if array arguments to a function do not point to distinct objects, the results are undefined. C passes arrays (actually, vectors) using pointers, and a pointer is a memory reference that can point anywhere in an array, and there are no restrictions about the same-object relations (whether at the same address or with an offset) of several arguments: the behavior is well-defined either way. The C99 standard or whatever it was allows passing multidimensional arrays to functions. In addition, you can use the "restrict" pointer syntax (total hell to use, by the way) to tell the compiler that a pointer argument to a function is not in an aliasing relation to other pointers accessible to the function. As a result, it has now become theoretically possible to write C code for multidimensional array manipulations that can be optimized as well as naively written Fortran code from 1960. In practice, however, it turns out that both code writers as well as compiler writers are not quite up to the task yet. Lesson: make hard to find and optimize corner cases undefined behavior if you don't want to make it almost impossible to write code that can be optimized well. The more assumptions an optimizer is allowed to make by default, the better it can do its work. _Without_ special help by the programmer. And if we wanted to rely on special help by the programmer, it would be more straightforward if we let the programmer write the assembly code rather than the compiler. -- David Kastrup
