[all-commits] [llvm/llvm-project] ead7c3: [clang] [MinGW] Add an implicit .exe suffix even w...

[Martin Storsjö via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: ead7c3cdc34c63d8df78d8e333b7cc64d03236ea
      https://github.com/llvm/llvm-project/commit/ead7c3cdc34c63d8df78d8e333b7cc64d03236ea
  Author: Martin Storsjö <martin at martin.st>
  Date:   2020-09-21 (Mon, 21 Sep 2020)

  Changed paths:
    M clang/lib/Driver/ToolChains/MinGW.cpp
    R clang/test/Driver/mingw-implicit-extension-cross.c
    M clang/test/Driver/mingw-implicit-extension-windows.c

  Log Message:
  -----------
  [clang] [MinGW] Add an implicit .exe suffix even when crosscompiling

GCC 8 changed behaviour wrt this, and made it consistent for cross
compilation cases. While it's a change, it's a more sensible behaviour
going forward.

Differential Revision: https://reviews.llvm.org/D88005


  Commit: 4d85444b317a00a3e15da63cdb693d272c99a0cc
      https://github.com/llvm/llvm-project/commit/4d85444b317a00a3e15da63cdb693d272c99a0cc
  Author: Martin Storsjö <martin at martin.st>
  Date:   2020-09-21 (Mon, 21 Sep 2020)

  Changed paths:
    M clang/lib/Driver/Driver.cpp
    M clang/test/Driver/cl-inputs.c
    M llvm/include/llvm/Support/Process.h
    M llvm/lib/Support/Process.cpp

  Log Message:
  -----------
  [clang-cl] Always interpret the LIB env var as separated with semicolons

When cross compiling with clang-cl, clang splits the INCLUDE env
variable around semicolons (clang/lib/Driver/ToolChains/MSVC.cpp,
MSVCToolChain::AddClangSystemIncludeArgs) and lld splits the
LIB variable similarly (lld/COFF/Driver.cpp,
LinkerDriver::addLibSearchPaths). Therefore, the consensus for
cross compilation with clang-cl and lld-link seems to be to use
semicolons, despite path lists normally being separated by colons
on unix and EnvPathSeparator being set to that.

Therefore, handle the LIB variable similarly in Clang, when
handling lib file arguments when driving linking via Clang.

This fixes commands like "clang-cl test.c -Fetest.exe kernel32.lib" in
a cross compilation setting. Normally, most users call (lld-)link
directly, but meson happens to use this command syntax for
has_function() tests.

Differential Revision: https://reviews.llvm.org/D88002


  Commit: 36c64af9d7f97414d48681b74352c9684077259b
      https://github.com/llvm/llvm-project/commit/36c64af9d7f97414d48681b74352c9684077259b
  Author: Martin Storsjö <martin at martin.st>
  Date:   2020-09-21 (Mon, 21 Sep 2020)

  Changed paths:
    M llvm/lib/CodeGen/AsmPrinter/WinException.cpp
    M llvm/test/CodeGen/AArch64/win64-jumptable.ll
    M llvm/test/CodeGen/AArch64/wineh1.mir
    M llvm/test/CodeGen/X86/avx512-intel-ocl.ll
    M llvm/test/CodeGen/X86/avx512-regcall-Mask.ll
    M llvm/test/CodeGen/X86/avx512-regcall-NoMask.ll
    M llvm/test/CodeGen/X86/break-false-dep.ll
    M llvm/test/CodeGen/X86/conditional-tailcall-pgso.ll
    M llvm/test/CodeGen/X86/conditional-tailcall.ll
    M llvm/test/CodeGen/X86/gnu-seh-nolpads.ll
    M llvm/test/CodeGen/X86/mingw-comdats.ll
    M llvm/test/CodeGen/X86/mixed-ptr-sizes.ll
    M llvm/test/CodeGen/X86/musttail-varargs.ll
    M llvm/test/CodeGen/X86/no-sse-win64.ll
    M llvm/test/CodeGen/X86/win64-jumptable.ll
    M llvm/test/CodeGen/X86/win64_frame.ll
    M llvm/test/DebugInfo/COFF/defer-complete-type.ll
    M llvm/test/DebugInfo/COFF/enum-co.ll
    M llvm/test/DebugInfo/COFF/global_visibility.ll
    M llvm/test/DebugInfo/COFF/type-quals.ll
    M llvm/test/DebugInfo/COFF/types-basic.ll
    M llvm/test/DebugInfo/COFF/types-data-members.ll
    M llvm/test/DebugInfo/COFF/types-method-ref-qualifiers.ll
    M llvm/test/DebugInfo/COFF/types-recursive-struct.ll

  Log Message:
  -----------
  [CodeGen] [WinException] Only produce handler data at the end of the function if needed

If we are going to write handler data (that is written as variable
length data following after the unwind info in .xdata), we need to
emit the handler data immediately, but for cases where no such
info is going to be written, skip emitting it right away. (Unwind
info for all remaining functions that hasn't gotten it emitted
directly is emitted at the end.)

This does slightly change the ordering of sections (triggering a
bunch of updates to DebugInfo/COFF tests), but the change should be
benign.

This also matches GCC's assembly output, which doesn't output
.seh_handlerdata unless it actually is needed.

For ARM64, the unwind info can be packed into the runtime function
entry itself (leaving no data in the .xdata section at all), but
that can only be done if there's no follow-on data in the .xdata
section. If emission of the unwind info is triggered via
EmitWinEHHandlerData (or the .seh_handlerdata directive), which
implicitly switches to the .xdata section, there's a chance of the
caller wanting to pass further data there, so the packed format
can't be used in that case.

Differential Revision: https://reviews.llvm.org/D87448


Compare: https://github.com/llvm/llvm-project/compare/2697d138a65a...36c64af9d7f9