[all-commits] [llvm/llvm-project] 02b25b: [clang] [MinGW] Improve/extend the gcc/sysroot det...

Tue Nov 29 13:17:40 PST 2022

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

  Changed paths:
    M clang/lib/Driver/ToolChains/MinGW.cpp
    M clang/lib/Driver/ToolChains/MinGW.h
    A clang/test/Driver/Inputs/mingw_fedora_tree/usr/lib/gcc/x86_64-w64-mingw32ucrt/12.2.1/include-fixed/.keep
    A clang/test/Driver/Inputs/mingw_fedora_tree/usr/x86_64-w64-mingw32ucrt/sys-root/mingw/include/.keep
    A clang/test/Driver/Inputs/mingw_fedora_tree/usr/x86_64-w64-mingw32ucrt/sys-root/mingw/include/c++/backward/.keep
    A clang/test/Driver/Inputs/mingw_fedora_tree/usr/x86_64-w64-mingw32ucrt/sys-root/mingw/include/c++/x86_64-w64-mingw32ucrt/.keep
    M clang/test/Driver/mingw-sysroot.cpp
    M clang/test/Driver/mingw.cpp

  Log Message:
  -----------
  [clang] [MinGW] Improve/extend the gcc/sysroot detection logic

There are three functions that try to detect the right implicit
sysroot and libgcc directory setup to use
- One which looks for mingw sysroots located in
  <clangbin>/../<sysrootname>
- One which looks for a mingw-targeting gcc executables in the PATH
- One which looks in the <gccroot>/lib/gcc directory to find the
  right one to use, and the right specific triple used for arch
  specific directories in the gcc/libstdc++ install

These have mostly tried to look for executables named
"<arch>-w64-mingw32-gcc" or "mingw32-gcc" or subdirectories
named "<arch>-w64-mingw32" or "mingw32".

In the case of findClangRelativeSysroot, it also has looked
for directories with the name of the actual triple. This
was added in deff7536278d355977171726124f83aa4bb95419,
with the intent of looking for a directory matching exactly
the user provided literal triple - however the triple here
is the normalized one, not the one provided by the user on
the command line.

Improve and unify this logic somewhat:
- Always first look for things based on the literal triple
  provided by the user.
- Secondly look for things based on the normalized triple
  (which usually ends up as e.g. x86_64-w64-windows-gnu),
  accessed via the Triple which is passed to the constructor
- Then look for the common triple form <arch>-w64-mingw32

The literal triple provided by the user is available via
Driver::getTargetTriple(), but computeTargetTriple() may
change e.g. the architecture of it, so we need to
reapply the effective architecture on the literal triple
spelling from Driver::getTargetTriple().

Do this consistently for all of findGcc, findClangRelativeSysroot
and findGccLibDir (while keeping the existing plain "mingw32"
cases in findGcc and findGccLibDir too).

Fedora 37 started shipping mingw sysroots targeting UCRT,
in addition to the traditional msvcrt.dll, and these use
triples in the form <arch>-w64-mingw32ucrt - see
https://fedoraproject.org/wiki/Changes/F37MingwUCRT.

Thus, in addition to the existing default tested triples,
try looking for triples in the form <arch>-w64-mingw32ucrt,
to automatically find the UCRT sysroots on Fedora 37.
By explicitly setting a specific target on the Clang command
line, the user can be more explicit with which flavour is
to be preferred.

This should fix the main issue in
https://github.com/llvm/llvm-project/issues/59001.

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

  Commit: 98454e388500de2f264c06b555d6009614f8f56e
      https://github.com/llvm/llvm-project/commit/98454e388500de2f264c06b555d6009614f8f56e
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-11-29 (Tue, 29 Nov 2022)

  Changed paths:
    M clang/lib/Driver/ToolChains/MinGW.cpp
    M clang/lib/Driver/ToolChains/MinGW.h
    M clang/test/Driver/mingw.cpp

  Log Message:
  -----------
  [clang] [MinGW] Improve detection of libstdc++ headers on Fedora

There's some variation in where different toolchain distributions
(and linux distributions) package the mingw sysroots - this is
so far handled by adding specific known subdirectory paths
to the include and lib directory lists.

There are multiple degrees of combinatorics involved here though;
the distros may use different locations such as
/usr/x86_64-w64-mingw32/include or
/usr/x86_64-w64-mingw32/sys-root/mingw/include.

So far, this setup has been treated as base=/usr, subdir=x86_64-w64-mingw32,
and the driver tries to add further subdirectories such as
<base>/<subdir>/include, <base>/<subdir>/sys-root/mingw/include.

When it comes to libstdc++ (and libc++), each of these come with
a large number of potential subdirectories. Instead of further
exploding the combinatorics another step by adding all combinations
of all paths, check whether <base>/<subdir>/sys-root/mingw/include
exists, and if it does, append that subpath into the subdir variable.

This allows finding libstdc++ headers in e.g.
/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/x86_64-w64-mingw32
on Fedora.

The same logic (where everything belonging to this target fits
under one expanded <subdir> path, with just /include and /lib
under it) doesn't seem to apply on Gentoo, where the includes
are found in <base>/<subdir>/usr/include while the libraries
are in <base>/<subdir>/mingw/lib (see
8e218026f8d5eabfdef9141ae5e26aa91d1933e6). But apparently
the libstdc++ headers aren't installed under
<base>/<subdir>/usr/include, so that path hierarchy quirk doesn't
need to be taken into account in AddClangCXXStdlibIncludeArgs.

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

  Commit: 2bd2734f445b434fbaa56f35797f40d7c0d91a6e
      https://github.com/llvm/llvm-project/commit/2bd2734f445b434fbaa56f35797f40d7c0d91a6e
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-11-29 (Tue, 29 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:
  -----------
  Reapply [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.

Reapply: Make sure OPENMP_TEST_COMPILER_FEATURES is defined
properly in all other test subdirectories other than
runtime/test too.

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

  Commit: 624e9e131827162fe186cb40239f753dcff0eb20
      https://github.com/llvm/llvm-project/commit/624e9e131827162fe186cb40239f753dcff0eb20
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-11-29 (Tue, 29 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] Use stdint.h instead of manual code defining kmp_int*. NFC.

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

Compare: https://github.com/llvm/llvm-project/compare/43b86bf9921b...624e9e131827