aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/VirtualFileSystem.cpp
diff options
context:
space:
mode:
authorFangrui Song <i@maskray.me>2022-03-30 09:12:09 -0700
committerFangrui Song <i@maskray.me>2022-03-30 09:12:09 -0700
commitc0065f118291e56ee6572032905a7301716e6b23 (patch)
tree6642c8c3c8d63e8aa8761c1100bcf7beca010e8e /llvm/lib/Support/VirtualFileSystem.cpp
parente78cea0a91e27cb75cdc4a428512d776feb16a86 (diff)
downloadllvm-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