English is currently available.
Fortran DISCUSSION
I have read that Fortran can optimise numerical loops more aggressively than C because the compiler may assume that dummy arguments do not overlap. I have a routine subroutine add_twice(a, b) that executes a = a + b twice, and calling it as call add_twice(x, x) with x = 1.0 gives 4.0 in a debug build and 3.0 with optimisation.
Is that a compiler bug or my mistake? What exactly is the rule, and how do I legally call a routine when input and output really are the same variable?
It is your call that breaks the rules, not the compiler. The standard says that if a dummy argument is modified inside a procedure, the data it refers to must not be reached through any other name during that call, whether another dummy argument or a module or common variable. call add_twice(x, x) associates both a and b with x and then modifies a, so the program is non-conforming.
Compilers are not required to detect this, and as far as the standard is concerned either result is acceptable.
The two results show what the optimiser is allowed to do. Without optimisation the code reloads b from memory each time: 1 + 1 = 2, then 2 + 2 = 4. With optimisation the compiler reasons that assigning to a cannot change b, keeps b in a register as 1, and computes 1 + 1 + 1 = 3.
In a loop such as y(i) = y(i) + s * x(i) the same assumption lets the compiler load and store several elements at once with vector instructions, without first checking whether x and y overlap. A C compiler has to assume that two pointer parameters might overlap unless they are declared restrict, which is the closest C equivalent of the Fortran rule.
To call the routine legally when input and output coincide, pass a copy of the input. The shortest way is an extra pair of parentheses: call add_twice(x, (x)). The parenthesised argument is an expression, not a variable, so it is evaluated into a temporary and the two dummies no longer refer to the same storage. The result is then a well-defined 3.0.
For large arrays that temporary costs a full copy, so a routine that is commonly used in place is better given a separate single-argument version. Note that aliasing is only a problem when something is modified: passing the same array to two intent(in) dummies is perfectly legal.
The rule also covers partial overlap: call shift(v(1:9), v(2:10)) is non-conforming if either section is written, and this form is the more common real-world bug, typically producing results that change with optimisation level or array size.
Compilers catch only the obvious cases. With an explicit interface, gfortran's -Waliasing warns when the same variable is passed to both an intent(in) and an intent(out) dummy, which is another reason to declare intents and keep procedures in modules.
There is a sanctioned way to say that overlap is possible: dummy arguments with the pointer attribute, or with target in the cases the standard describes, may be aliased, and the compiler must then generate conservative code that reloads values after each store. That is why pointer-heavy Fortran tends to optimise no better than C.
It is also why allocatable arrays are preferred over pointer arrays for ordinary dynamic storage: an allocatable cannot be aliased by another variable unless it has the target attribute, so the fast assumptions still hold.
