[all-commits] [llvm/llvm-project] 30d5b7: [llvm-objcopy] [COFF] Always set PointerToRawData ...

[Martin Storsjö via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 30d5b755ea4f07ca014ed7e89b40054fb2b29eda
      https://github.com/llvm/llvm-project/commit/30d5b755ea4f07ca014ed7e89b40054fb2b29eda
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-11-28 (Mon, 28 Nov 2022)

  Changed paths:
    M llvm/lib/ObjCopy/COFF/COFFWriter.cpp
    A llvm/test/tools/llvm-objcopy/COFF/empty-sections.s

  Log Message:
  -----------
  [llvm-objcopy] [COFF] Always set PointerToRawData when writing a COFF file

If we don't want to set PointerToRawData, for an empty section,
we do must set it to zero explicitly. Some object file generators
do set it to zero for empty sections, while others set a nonzero
value pointing at the end of the previous section.

If the value was nonzero on input, we need to update it - either
setting it to zero, or to a valid offset in the output file (not
out of bounds)

This fixes https://github.com/mstorsjo/llvm-mingw/issues/313.

Testing this is tricky, because we can't use yaml2obj, since that
doesn't produce object files with nonzero PointerToRawData for
empty sections. We can use llvm-mc to assemble a small file
(assuming that LLVM's MC layer keeps this behaviour), or bundle
a small binary object file. I opted for using llvm-mc for now here
(with a test that it actually does keep this property), but I don't
mind changing it to a canned object file to make the test less brittle.

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


  Commit: db6406acec7b70c39970f888617884e684b3ca9e
      https://github.com/llvm/llvm-project/commit/db6406acec7b70c39970f888617884e684b3ca9e
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-11-28 (Mon, 28 Nov 2022)

  Changed paths:
    M openmp/runtime/src/kmp_os.h

  Log Message:
  -----------
  [openmp] Use GCC style intrinsics for atomics on Clang-cl on aarch64 too

This fixes compilation in the Clang-cl configuration on aarch64;
Clang doesn't implement all the aarch64 MSVC atomic intrinsics yet.

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


  Commit: 63f0fdc2628dfb2f52ed5a92e579f99261d946ed
      https://github.com/llvm/llvm-project/commit/63f0fdc2628dfb2f52ed5a92e579f99261d946ed
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-11-28 (Mon, 28 Nov 2022)

  Changed paths:
    M openmp/runtime/test/lit.cfg

  Log Message:
  -----------
  [openmp] [test] Set __COMPAT_LAYER=RunAsInvoker when running tests on Windows

Windows heuristics may decide to want to run some tested processes
as elevated (since it may think some of them are installers - executables
with "dispatch" in the name may hit a heuristic looking for "patch").

Set this environment variable to disable this heuristic and just run
the executable with whatever privileges the caller has.

This fixes a couple tests on such versions of Windows where this
heuristic is active.

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


  Commit: 03bf001b6d95f7c6a88a2b95f3cad752b9d1ed45
      https://github.com/llvm/llvm-project/commit/03bf001b6d95f7c6a88a2b95f3cad752b9d1ed45
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-11-28 (Mon, 28 Nov 2022)

  Changed paths:
    M openmp/cmake/OpenMPTesting.cmake
    M openmp/runtime/test/CMakeLists.txt
    M openmp/runtime/test/misc_bugs/many-microtask-args.c

  Log Message:
  -----------
  [openmp] [test] XFAIL many-microtask-args.c on ARM

On ARM, a C fallback version of __kmp_invoke_microtask is used,
which only handles up to a fixed number of arguments - while
many-microtask-args.c tests that the function can handle an
arbitrarily large number of arguments (the testcase produces 17
arguments).

On the CMake level, we can't add ${LIBOMP_ARCH} directly to
OPENMP_TEST_COMPILER_FEATURES in OpenMPTesting.cmake, since
that file is parsed before LIBOMP_ARCH is set. Instead
convert the feature list into a proper CMake list, and append
${LIBOMP_ARCH} into it before serializing it to an Python array.

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


  Commit: 4ed8fcc59a699b3eb62c6a8929f4589dd3463776
      https://github.com/llvm/llvm-project/commit/4ed8fcc59a699b3eb62c6a8929f4589dd3463776
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-11-28 (Mon, 28 Nov 2022)

  Changed paths:
    M openmp/runtime/test/tasking/bug_nested_proxy_task.c
    M openmp/runtime/test/tasking/bug_proxy_task_dep_waiting.c

  Log Message:
  -----------
  [openmp] [test] Fix data structure mismatches for tests that define kmp_depend_info

Use the correct data type for pointer sized integers on Windows;
"long" is always 32 bit, even on 64 bit Windows - don't use it
for the kmp_intptr_t type.

Provide the exact correct definition of the kmp_depend_info
struct - avoid the risk of mismatches (if a platform would pack
things slightly differently when things are declared differently).

Zero initialize the whole dep_info struct before filling it in;
if only setting the in/out bits, the rest of the unallocated bits
in the bitfield can have undefined values. Libomp reads the flags
in combined form as an kmp_uint8 by reading the flag field - thus,
the unused bits do need to be zeroed. (Alternatively, the flag field
could be set to zero before setting the individual bits in the
bitfield).

Use kmp_intptr_t instead of long for casting pointers to integers.

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


Compare: https://github.com/llvm/llvm-project/compare/94f73fd6f834...4ed8fcc59a69