3 ms·
It's forbidden by the language standard, hence compilers assume no aliasing occurs, but it nevertheless may do so due to 'non-conforming' code. In the words of
by cygx 7y ago
It's forbidden by the language standard, hence compilers assume no aliasing occurs, but it nevertheless may do so due to 'non-conforming' code.
In the words of the g77 manual:
> Essentially, compilers are promised (by the standard and, therefore, by programmers who write code they claim to be standard-conforming) that if they cannot detect aliasing via static analysis of a single program unit's EQUIVALENCE and COMMON statements, no such aliasing exists. In such cases, compilers are free to assume that an assignment to one variable will not change the value of another variable, allowing it to avoid generating code to re-read the value of the other variable, to re-schedule reads and writes, and so on, to produce a faster executable.
> [...]
> Unfortunately, there is no way to find all possible cases of violations of the prohibitions against aliasing in Fortran code. Static analysis is certainly imperfect, as is run-time analysis, since neither can catch all violations. (Static analysis can catch all likely violations, and some that might never actually happen, while run-time analysis can catch only those violations that actually happen during a particular run. Neither approach can cope with programs mixing Fortran code with routines written in other languages, however.)
Like in C, it will result in undefined behaviour (though the Fortran spec doesn't use the term).
- pjmlp 7y agoFortran 77, when the latest version is Fortran 2018? Nevertheless, that is like describing C semantics with something that is only possible in GNU C. Naturally if one goes outside what the standard allows, everything goes.
- cygx 7y agoFortran 77, when the latest version is Fortran 2018? It was the first relevant search result. Feel free to look for more recent resources on the topic, eg https://www.sciencedirect.com/science/article/pii/S1571066104803967 https://www.sciencedirect.com/science/article/pii/S157106610... (still a bit dated). Naturally if one goes outside what the standard allows, everything goes. Which makes the Fortran situation essentially the same as the C one once you've typed out `restrict`.
- pjmlp 7y agoNot really, because the standard is what defines the language, just because GNU Fortran does non conforming stuff it doesn't mean that for example PGI Fortran would do the same non conforming behavior. By the same measure I can assert that C++ is a memory safe language given that Visual C++ enables bounds checking and iterator invalidation in the standard library by default.
- cygx 7y agoThe C language standard makes certain guarantees, such as no out-of-bounds array access, or no modification of memory accessed through a restrict-qualified expression by other means. If such things happen during program execution, the program does not conform to the standard, and its runtime behaviour becomes undefined. This is exactly the same situation you have with Fortran, which makes certain guarantees about, say, the aliasing of function arguments. If all such cases could be detected ahead of time, it would be impossible for programmers to write non-conforming programs. This is not possible. I repeat, there is no essential difference between the Fortran and C situation. The best one could argue is that given that the Fortran guarantees are universal (instead of limited to restrict-qualified pointers), a Fortran programmer is less likely to write an incorrect program, but that's it.
- pjmlp 7y agoI guess we have different ways to interpret ISO standards documents, so let's leave at it.