[all-commits] [llvm/llvm-project] c0065f: [ELF] Default to --no-fortran-common

[Fangrui Song via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c0065f118291e56ee6572032905a7301716e6b23
      https://github.com/llvm/llvm-project/commit/c0065f118291e56ee6572032905a7301716e6b23
  Author: Fangrui Song <i at maskray.me>
  Date:   2022-03-30 (Wed, 30 Mar 2022)

  Changed paths:
    M lld/ELF/Driver.cpp
    M lld/docs/ReleaseNotes.rst
    M lld/test/ELF/common-archive-lookup.s
    M lld/test/ELF/warn-backrefs.s

  Log Message:
  -----------
  [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