Similar to how clang-cl driver does it, make it possible to build arm64x
binaries with a mingw-style invocation.
Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
On MinGW targets, the .ctors section is always used for constructors.
When using the .ctors section, the constructors need to be emitted in
reverse order to get them execute in the right order. (Constructors with
a specific priority are sorted separately by the linker later.) In LLVM,
in CodeGen/AsmPrinter/AsmPrinter.cpp, there's code that reverses them
before writing them out, executed when using the .ctors section. This
logic is done whenever TM.Options.UseInitArray is set to false. Thus,
make sure to set UseInitArray to false for this target.
This fixes https://github.com/llvm/llvm-project/issues/55938.
Account for backslashes in paths in mingw.cpp.
Testing clang with the <triple>-clang form seems to require the
x86 target to be enabled, when the triple is an x86 triple. Just
skip that aspect of the test, since the "clang --target=<triple>"
form should give enough test coverage here.
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
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
There's code in clang/lib/Driver/ToolChains/Gnu.cpp for Clang to use Gentoo's include and lib paths, but this is missing for mingw, meaning that any C++ programs using the STL will fail to compile.
See https://bugs.gentoo.org/788430
Differential Revision: https://reviews.llvm.org/D111081
The existing logic for per-target libc++ include directories only
seem to exist for the Gnu and Fuchsia drivers, added in
ea12d779bc238c387511fe7462020f4ecf4a8246 / D89013.
This is less generic than the corresponding case in the Gnu driver,
but matches the existing level of genericity in the MinGW driver
(and others too).
Differential Revision: https://reviews.llvm.org/D107893
Actually compare each version to the version of the last chosen one.
There's no guarantee that the added test case does showcase the
previous issue (it depends on the order that directory entries
are returned when iterating), but with the issue fixed it should behave
deterministically in any case.
Also improve the match patterns in the mingw-sysroot.cpp test a bit.
Differential Revision: https://reviews.llvm.org/D102873
Previously it would only accept a string as a GCC version if it had
either two components and no suffix, or three components with an
optional suffix.
Debian and ubuntu provided mingw compilers have lib/gcc/target entries
like "5.3-posix" and "5.3-win32". This doesn't try to make any specific
preference between them (other than lexical sorting of the suffix).
Differential Revision: https://reviews.llvm.org/D45505
llvm-svn: 330696
This makes it consistent with libstdc++ and the other default
include directories.
If these headers are found in both locations and one isn't a
symlink to the other, this will cause errors due to libc++ headers
having wrapper headers for some standard C headers, wrappers that
do #include_next the actual one.
If the same libc++ standard C wrapper header exists in more than one
include directory before the real system one, the header include
guard will stop it from doing another #include_next to pick up the
real one, breaking things.
As this is a rather uncommon situation, this should be acceptable
and toolchain maintainers can adapt accordingly if necessary.
Also simplify some of the existing code with a local variable.
Differential Revision: https://reviews.llvm.org/D45500
llvm-svn: 329946
This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru
which we can specify a default value for -rtlib (libgcc or
compiler-rt) at build time, just like how we set the default C++
stdlib thru CLANG_DEFAULT_CXX_STDLIB.
With these two options, we can configure clang to build binaries on
Linux that have no runtime dependence on any gcc libs (libstdc++ or
libgcc_s).
Patch by Lei Zhang!
Differential Revision: https://reviews.llvm.org/D22663
llvm-svn: 276848
Summary:
There are a number of files in the tree which have been accidentally checked in with DOS line endings. Convert these to native line endings.
There are also a few files which have DOS line endings on purpose, and I have set the svn:eol-style property to 'CRLF' on those.
Reviewers: joerg, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D15849
llvm-svn: 256704
Summary:
When we want to use mingw-w64 and clang with compiler-rt we should not
need to have libgcc installed. This fixes finding includes when libgcc
is not installed
Reviewers: yaron.keren
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11808
llvm-svn: 244902
Address Richard Smith comments: remove the trailing seperator from the Arch
variable, implement six mingw_* trees under tools/clangtest/Driver/Inputs
and merge linux and Windows tests into a universal test that uses these trees.
llvm-svn: 243098
