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 9 hours ago | parent | next [-]

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 6 hours ago | parent [-]

How does this bug concern aliasing?

▲

mrspuratic 30 minutes ago | parent | next [-]

In old school FORTRAN (I only recall WATFOR/F77, my uni's computers were quite ancient) subroutine (aka "subprogram") parameters are call-by-reference. If you passed a literal constant it would be treated as a variable in order to be aliased/passed by reference. Due to "constant pooling", modifications to a variable that aliased a constant could then propagate throughout the rest of the program where that constant[sic] was used.

"Passing constants to a subprogram" https://www.ibiblio.org/pub/languages/fortran/ch1-8.html

▲

Etheryte 4 hours ago | parent | prev [-]

It's literally in the description? Because of aliasing, a variable that should've been zero became four.

▲

pklausler 3 hours ago | parent [-]

It wasn't a variable.

	▲	Etheryte 2 hours ago \| parent [-]
		It wasn't intended to be a variable, but it did become one. Its value varied, it's in the name.

▲

uecker 5 hours ago | parent | prev | next [-]

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

https://godbolt.org/z/jva4shbjs

▲

adev_ 4 hours ago | parent [-]

> 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.

	▲	uecker 2 hours ago \| parent [-]
		Regarding "restrict", I don't think one puts it everywhere, just for certain numerical loops which otherwise are not vectorized should be sufficient. FORTRAN seems even more dangerous to me. IMHO a better solution would be to have explicit notation for vectorized operations. Hopefully we will get this in C. Otherwise, I am very happy with C for numerics, especially with variably modified typs. For C++, yes, I agree.

▲

kryptiskt 7 hours ago | parent | prev [-]

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