diff options
author | Fangrui Song <i@maskray.me> | 2022-03-30 09:12:09 -0700 |
---|---|---|
committer | Fangrui Song <i@maskray.me> | 2022-03-30 09:12:09 -0700 |
commit | c0065f118291e56ee6572032905a7301716e6b23 (patch) | |
tree | 6642c8c3c8d63e8aa8761c1100bcf7beca010e8e /llvm/lib/Support/VirtualFileSystem.cpp | |
parent | e78cea0a91e27cb75cdc4a428512d776feb16a86 (diff) | |
download | llvm-c0065f118291e56ee6572032905a7301716e6b23.zip llvm-c0065f118291e56ee6572032905a7301716e6b23.tar.gz llvm-c0065f118291e56ee6572032905a7301716e6b23.tar.bz2 |
[ELF] Default to --no-fortran-common
D86142 introduced --fortran-common and defaulted it to true (matching GNU ld
but deviates from gold/macOS ld64). The default state was motivated by transparently
supporting some FORTRAN 77 programs (Fortran 90 deprecated common blocks).
Now I think it again. I believe we made a mistake to change the default:
* this is a weird and legacy rule, though the breakage is very small
* --fortran-common introduced complexity to parallel symbol resolution and will slow down it
* --fortran-common more likely causes issues when users mix COMMON and
STB_GLOBAL definitions (see https://github.com/llvm/llvm-project/issues/48570 and
https://maskray.me/blog/2022-02-06-all-about-common-symbols).
I have seen several issues in our internal projects and Android.
On the other hand, --no-fortran-common is safer since
COMMON/STB_GLOBAL have the same semantics related to archive member extraction.
Therefore I think we should switch back, not punishing the common uage.
A platform wanting --fortran-common can implement ld.lld as a shell script
wrapper around `lld -flavor gnu --fortran-common "$@"`.
Reviewed By: ikudrin, sfertile
Differential Revision: https://reviews.llvm.org/D122450
Diffstat (limited to 'llvm/lib/Support/VirtualFileSystem.cpp')
0 files changed, 0 insertions, 0 deletions