forked from OSchip/llvm-project
c0065f1182
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 |
||
|---|---|---|
| .. | ||
| ELF | ||
| _static | ||
| _templates | ||
| llvm-theme | ||
| CMakeLists.txt | ||
| NewLLD.rst | ||
| Partitions.rst | ||
| README.txt | ||
| ReleaseNotes.rst | ||
| WebAssembly.rst | ||
| conf.py | ||
| error_handling_script.rst | ||
| hello.png | ||
| index.rst | ||
| ld.lld.1 | ||
| make.bat | ||
| missingkeyfunction.rst | ||
| partitions.dot | ||
| partitions.svg | ||
| windows_support.rst | ||
README.txt
lld Documentation ================= The lld documentation is written using the Sphinx documentation generator. It is currently tested with Sphinx 1.1.3. We currently use the 'nature' theme and a Beaker inspired structure. See sphinx_intro.rst for more details.