3 ms·
Compilers still emit non vectorized code if there's a chance pointers are aliased, this is not fixed at all
by mkoubaa 4y ago
Compilers still emit non vectorized code if there's a chance pointers are aliased, this is not fixed at all
- int_19h 4y agoI think OP means "restrict". If you put that on every pointer by default, that would be the equivalent of what FORTRAN does. Do modern C compilers still assume aliasing in that case?
- pjmlp 4y agoThe problem with restrict, like everything in C, is that it is expected that developers know what they are doing. Use by mistake the same variable in separate restrict declarations, and UB dameons will be summoned.
- int_19h 4y agoI was under the impression that inadvertently causing aliasing via by-ref arguments in Fortran is also effectively UB, and any diagnostics that compilers might produce are best-effort and will not catch non-trivial cases.
- lmm 4y agoProbably the real difference is that Fortran compiler culture is to do the right thing for UB rather than screwing over the programmer.
- int_19h 4y agoWhat would the "right thing" be in this case, in cases where the compiler cannot detect at compile-time? Will it actually check all variables in scope for aliasing when entering the function?
- lmm 4y agoIf your pointers turn out to overlap then maybe you get "impossible" stale reads or something, but you don't get demons flying out of your nose like in C.
- adgjlsfhk1 4y agoThe same is true in Fortran. They "solved" the problem by declaring it UB and producing broken code.
- mkoubaa 4y agoIt's not broken if you test your code and it works