This is an archive of the discontinued LLVM Phabricator instance.

[ELF] Default to --no-fortran-common
ClosedPublic

Authored by MaskRay on Mar 24 2022, 7:40 PM.

Details

Summary

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 "$@".

Diff Detail

Event Timeline

MaskRay created this revision.Mar 24 2022, 7:40 PM
Herald added a project: Restricted Project. · View Herald Transcript
MaskRay requested review of this revision.Mar 24 2022, 7:40 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 24 2022, 7:40 PM

If I understand it right, --fortran-common is useful in rare scenarios but can slow down linking when handling COMMON symbols, and it also hinders implementing the parallel symbol resolution. If that is true, I agree with the change.

MaskRay added a comment.EditedMar 28 2022, 1:48 PM

If I understand it right, --fortran-common is useful in rare scenarios but can slow down linking when handling COMMON symbols, and it also hinders implementing the parallel symbol resolution. If that is true, I agree with the change.

The understanding is right.

If we implement parallel symbol resolution, we probably have two code paths for a while. Not wasting efforts on implementing --fortran-common for the parallel code path helps.
(If we ever are able to drop the serial code path, we may need to implement --fortran-common. But the code path can be disabled for most use cases to not cause slowdown.)

ikudrin accepted this revision.Mar 28 2022, 11:58 PM

LGTM then

This revision is now accepted and ready to land.Mar 28 2022, 11:58 PM

Apologies for delay in responding, been OoO for a bit. I'm happy with the change. Do we have enough people that commented in favour of D86142 in the reviewer/subscriber list? If only to make sure they are aware of the change.

Apologies for delay in responding, been OoO for a bit. I'm happy with the change. Do we have enough people that commented in favour of D86142 in the reviewer/subscriber list? If only to make sure they are aware of the change.

Sent a comment https://reviews.llvm.org/D86142#3414187

sfertile accepted this revision.Mar 30 2022, 7:31 AM

LGTM.

This revision was automatically updated to reflect the committed changes.