[adev_]

Aliasing is no joke and currently the only reason why some arithmetic intensive code-bases still prefer Fortran even nowadays.

While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is a pain to do it properly.

[bregma]

Aliasing can be a problem in Fortran too.

Decades ago I was a Fortran developer and encountered a very odd bug in which the wrong values were being calculated. After a lot of investigation I tracked it down to a subroutine call in which a hard-coded zero was being passed as an argument. It turned out that in the body of that subroutine the value 4 was being assigned to that parameter for some reason. The side effect was that the value of zero because 4 for the rest of the program execution because Fortran aliases all parameters since it passes by descriptor (or at least DEC FORTRAN IV did so on RSX/11). As you can imagine, hilarity ensued.

[pklausler]

How does this bug concern aliasing?

[uecker]

Is it? You just add "restrict" where needed?

https://godbolt.org/z/jva4shbjs

[adev_]

> Is it? You just add "restrict" where needed?

Yes. That is the main solution and it is not a good one.

1- `restrict` need to be used carefully. Putting it everywhere in large codebase can lead to pretty tricky bugs if aliasing does occurs under the hood.

1- Restrict is not an official keyword in C++. C++ always has refused to standardize it because it plays terribly with almost any object model.

[kryptiskt]

Support for arrays without having to mess with pointers is pretty attractive for number crunchers too.