I was attempting to build openblas with clang in msys2's `ucrt64`
environment (I'm aware of the `clang64` environment, but I wanted
libstdc++). The openblas link failed with the following:
```
clang -march=native -mtune=native -m64 -O2 -fno-asynchronous-unwind-tables -O2 -DSMALL_MATRIX_OPT -DMS_ABI -DMAX_STACK_ALLOC=2048 -Wall -m64 -DF_INTERFACE_GFORT -DDYNAMIC_ARCH -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=512 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.29\" -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME= -DASMFNAME=_ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\" -DNO_AFFINITY -I.. libopenblas64_.def dllinit.obj \
-shared -o ../libopenblas64_.dll -Wl,--out-implib,../libopenblas64_.dll.a \
-Wl,--whole-archive ../libopenblas64_p-r0.3.29.a -Wl,--no-whole-archive -LC:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0 -LC:/msys64/ucrt64/bin/../lib/gcc -LC:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../x86_64-w64-mingw32/lib/../lib -LC:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../lib -LC:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../x86_64-w64-mingw32/lib -LC:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../.. -lgfortran -lmingwex -lmsvcrt -lquadmath -lm -lpthread -lmingwex -lmsvcrt -defaultlib:advapi32 -lgfortran -defaultlib:advapi32 -lgfortran
C:/msys64/ucrt64/bin/ld: C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../lib/libmingw32.a(lib64_libmingw32_a-pseudo-reloc.o): in function `__report_error':
D:/W/B/src/mingw-w64/mingw-w64-crt/crt/pseudo-reloc.c:157:(.text+0x59): undefined reference to `abort'
C:/msys64/ucrt64/bin/ld: C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../lib/libmingw32.a(lib64_libmingw32_a-tlsthrd.o): in function `___w64_mingwthr_add_key_dtor':
D:/W/B/src/mingw-w64/mingw-w64-crt/crt/tlsthrd.c:48:(.text+0xa5): undefined reference to `calloc'
C:/msys64/ucrt64/bin/ld: C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../lib/libmingw32.a(lib64_libmingw32_a-pesect.o): in function `_FindPESectionByName':
D:/W/B/src/mingw-w64/mingw-w64-crt/crt/pesect.c:79:(.text+0xfd): undefined reference to `strncmp'
```
These symbols come from the `-lmingw32` dep that the driver added and
are ordinarily found in `-lmsvcrt`, which got skipped here, because
openblas passed `-lmsvcrt` explicitly earlier in the link line. Since we
always add these libraries at the end here, I think that clang is "at
fault" (as opposed to a user or packaging mistake) and should have added
some crt here.
To preserve the intent of letting the user override which crt is chosen,
duplicate the (first) user chosen crt `-l` into this position, although
we should perhaps consider an explicit `-mcrtdll` like gcc has as well.
(cherry picked from commit 7f470586e10543aa12efc7e04d4d4ac814eaca35)
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>
This patch moves the CommonArgs utilities into a location visible by the
Frontend Drivers, so that the Frontend Drivers may share option parsing
code with the Compiler Driver. This is useful when the Frontend Drivers
would like to verify that their incoming options are well-formed and
also not reinvent the option parsing wheel.
We already see code in the Clang/Flang Drivers that is parsing and
verifying its incoming options. E.g. OPT_ffp_contract. This option is
parsed in the Compiler Driver, Clang Driver, and Flang Driver, all with
slightly different parsing code. It would be nice if the Frontend
Drivers were not required to duplicate this Compiler Driver code. That
way there is no/low maintenance burden on keeping all these parsing
functions in sync.
Along those lines, the Frontend Drivers will now have a useful mechanism
to verify their incoming options are well-formed. Currently, the
Frontend Drivers trust that the Compiler Driver is not passing back junk
in some cases. The Language Drivers may even accept junk with no error
at all. E.g.:
`clang -cc1 -mprefer-vector-width=junk test.c'
With this patch, we'll now be able to tighten up incomming options to
the Frontend drivers in a lightweight way.
---------
Co-authored-by: Cameron McInally <cmcinally@nvidia.com>
Co-authored-by: Shafik Yaghmour <shafik.yaghmour@intel.com>
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
This PR is to improve the driver code to build `flang-rt` path by
re-using the logic and code of `compiler-rt`.
1. Moved `addFortranRuntimeLibraryPath` and `addFortranRuntimeLibs` to
`ToolChain.h` and made them virtual so that they can be overridden if
customization is needed. The current implementation of those two
procedures is moved to `ToolChain.cpp` as the base implementation to
default to.
2. Both AIX and PPCLinux now override `addFortranRuntimeLibs`.
The overriding function of `addFortranRuntimeLibs` for both AIX and
PPCLinux calls `getCompilerRTArgString` => `getCompilerRT` =>
`buildCompilerRTBasename` to get the path to `flang-rt`. This code
handles `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` setting. As shown in
`PPCLinux.cpp`, `FT_static` is the default. If not found, it will search
and build for `FT_shared`. To differentiate `flang-rt` from `clang-rt`,
a boolean flag `IsFortran` is passed to the chain of functions in order
to reach `buildCompilerRTBasename`.
(this is clang related part)
Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects. For example,
`clagd` may report even `llvm-config.h` as "no used" in case it defines
a macro, that is explicitly used with #ifdef. It is actually amplified
with different build configs which use different set of macros.
This reverts 130e93cc26ca9d3ac50ec5a92e3109577ca2e702 for the MinGW
target.
This avoids the issue that is discussed in
https://github.com/llvm/llvm-project/issues/96899 (and which is
summarized in the code comment). This is intended as a temporary
workaround until the issue is handled better within libc++.
Use the LazyDetector also for the remaining toolchains to avoid unnecessarily checking for the Cuda and Rocm installations.
This fixes rdar://121397534.
This fixes uses of the MSYS2 clang64 environment compilers, if another
set of GCC based compilers are available further back in PATH (which may
be explicitly added, or inherited unintentionally from other software
installed).
(The issue in the clang64 environment can be worked around somewhat by
installing *-gcc-compat packages which present aliases named
<triple>-gcc within the clang64 environment as well.)
This fixes https://github.com/msys2/MINGW-packages/issues/11495 and
https://github.com/msys2/MINGW-packages/issues/19279.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
The flang driver was silently ignoring the `main()` function in
`Fortran_main.a` for entry into the Fortran program unit if an external
`main()` as supplied (e.g., via cross-language linkage with Fortran and
C/C++). This PR fixes this by making sure that the linker always pulls
in the `main()` definition from `Fortran_main.a` and consequently fails
due to multiple definitions of the same symbol if another object file
also has a definition of `main()`.
This patch uses the added --dependent-lib support to add the relevant
runtimes on MSVC targets as `/DEFAULTLIB:` sections in the object file
rather than on the link line. This should help CMake support for flang
on Windows.
Fixes#63741Fixes#68017
Currently flang's runtime libraries are only built for the specific CRT
that LLVM itself was built against. This patch adds the cmake logic for
building a separate runtime for each CRT configuration and adds a flag
for selecting a CRT configuration to link against.
-Z is an Apple ld64 option. ELF linkers don't recognize -Z, except
OpenBSD which patched GNU ld to add -Z for zmagic (seems unused)
> -Z Produce 'Standard' executables, disables Writable XOR Executable
features in resulting binaries.
Some `ToolChain`s have -Z due to copy-and-paste mistakes.
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.
Prior to 591c4b64b3650884c2c68eb47d755ebb62981b99, the mingw specific
linker options -mthreads, -mconsole, -mwindows and -mdll would be
tolerated also at compile time, but generating a warning about being
unused.
After that commit, they were marked as target specific, which means that
it's an error if they're unused (which would consider them used for the
wrong target). These specific options are only relevant when linking,
but we want to tolerate them at compile time too, like before.
This was fixed for -mthreads in
a79995ca6004082774a87f7a58ab6be5343364b7, while the other options didn't
seem to be commonly used during compilation.
After the 17.x release, we've got more reports about this actually being
an issue, in #64464. Therefore, apply the same fix for them; marking
them as tolerated for mingw targets during compilation, even if they're
unused. Also add a testcase for -mthreads which was already handled.
Thus, this fixes#64464.
In GCC, the .refptr stubs are only generated for x86_64, and only
for code models medium and larger (and medium is the default for
x86_64 since this was introduced). They can be omitted for
projects that are conscious about performance and size, and don't
need automatically importing dll data members, by passing -mcmodel=small.
In Clang/LLVM, such .refptr stubs are generated for any potentially
symbol reference that might end up autoimported. The .refptr stubs
are emitted for three separate reasons:
- Without .refptr stubs, undefined symbols are mostly referenced
with 32 bit wide relocations. If the symbol ends up autoimported
from a different DLL, a 32 bit relative offset might not be
enough to reference data in a different DLL, depending on runtime
loader layout.
- Without .refptr stubs, the runtime pseudo relocation mechanism
will need to temporarily make sections read-write-executable
if there are such relocations in the text section
- On ARM and AArch64, the immediate addressing encoded into
instructions isn't in the form of a plain 32 bit relative offset,
but is expressed with various bits scattered throughout two
instructions - the mingw runtime pseudo relocation mechanism
doesn't support updating offsets in that form.
If autoimporting is known not to be needed, the user can now
compile with -fno-auto-import, avoiding the extra overhead of
the .refptr stubs.
However, omitting them is potentially fragile as the code
might still rely on automatically importing some symbol without
the developer knowing. If this happens, linking still usually
will succeed, but users may encounter issues at runtime.
Therefore, if the new option -fno-auto-import is passed to the compiler
when driving linking, it passes the flag --disable-auto-import to
the linker, making sure that no symbols actually are autoimported
when the generated code doesn't expect it.
Differential Revision: https://reviews.llvm.org/D61670
Have ToolChain::IsIntegratedAssemblerDefault default to true.
Almost all of the ToolChains are using IAS nowadays. There are a few exceptions like
XCore, some NaCl archs, and NVPTX/XCore in Generic_GCC::IsIntegratedAssemblerDefault.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D154902
-e has the LinkerInput flag (commit fcf8ada18f9cfb1261262e4b0399ae9ab40451f8)
and is rendered by AddLinkerInputs. We should remove duplicate rendering (e.g.,
`Args.AddAllArgs(CmdArgs, options::OPT_e)`).
For unclaimed target-agnostic options, we can apply clang_ignored_gcc_optimization_f_Group
to accept but warn about them.
```
% clang -c -fexpensive-optimizations a.c
clang: warning: optimization flag '-fexpensive-optimizations' is not supported [-Wignored-optimization-argument]
```
For an unclaimed target-specific option, one target may want to accept but warn
about it. Add `llvm::opt::Arg::IgnoredTargetSpecific` to support this warning
need.
Close https://github.com/llvm/llvm-project/issues/63282
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D152856
As stated in https://github.com/llvm/llvm-project/issues/61685, by
passing LLD the import lib of the asan DLL first, the asan DLL will be
listed as the first entry in the Import Directory Table, making it be
loaded first before other user DLLs. This allows asan to be initialized
as early as possible to increase its instrumentation coverage to include
other DLLs not built with asan.
This also avoids some false asan reports on `realloc` for memory
allocated during initialization of user DLLs being loaded earlier than
asan, because after this change they will be loaded later than asan.
Differential Revision: https://reviews.llvm.org/D146908
The MinGW compiler driver first tries to deduce the root of
the toolchain installation (either clang itself or a separate
cross mingw gcc installation). On top of this root, a number
of include and lib paths are added (some added unconditionally,
some only if they exist):
- <base>/x86_64-w64-mingw32/include
- <base>/include
- <base>/include/x86_64-w64-windows-gnu
(Some more are also added for libstdc++ and/or libc++.)
The first one is the one commonly used for MinGW targets so
far. For LLVM runtimes installed with the
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR option, the latter two are
used though (this is currently not the default, not yet at least).
For cross compiling, if base is a separate dedicated directory,
this is fine, but when using the sysroots of a distro-installed
cross mingw toolchain, base is /usr - and having /usr/include
in the include path for cross compilation is a potential
source for problems; see
https://github.com/llvm/llvm-project/issues/59871.
If not cross compiling though, <base>/include needs to be included
too. E.g. in the case of msys2, most headers are in e.g.
/mingw64/include while the compiler is /mingw64/bin/clang.
When cross compiling, if the sysroot has been explicitly set
by the user, keep <base>/include too. (In the case of a distro
provided cross gcc toolchain in /usr, the sysroot needs to be set
to /usr and not /usr/x86_64-w64-mingw32 though, to be able to find
libgcc files under /usr/lib/gcc/x86_64-w64-mingw32. So with such a
toolchain, setting the sysroot explicitly does retain the problem.)
All in all - this avoids adding /usr/include and /usr/lib to the
include/lib paths when doing mingw cross compilation with a
distro-provided sysroot in /usr/x86_64-w64-mingw32.
Test that the include directory is omitted in the mingw-sysroot.cpp
tests, when cross compiling. That test is only ever executed on
non-Windows hosts, since it uses symlinks to set up fake environments
with colocated compilers and header/lib directories. There aren't
really any current corresponding tests for the same implicit behaviours
when actually running on Windows.
Differential Revision: https://reviews.llvm.org/D141206
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
This is a follow-up to 53c98d85a, which made the same change but only
for GNU. It seems that we should try to provide a consistent behavior
across all targets.
This fixes an issue where clang/test/Driver/nostdincxx.cpp would start
failing on non-GNU targets because that test was too loose in its checks.
It would only check that 'file not found' was part of the error message,
but didn't ensure that the file we had not found was <vector>.
Differential Revision: https://reviews.llvm.org/D138062
This option can be used to enable Control Flow Guard checks and
generation of address-taken function table. They are equivalent to
`/guard:cf` and `/guard:cf,nochecks` in clang-cl. Passing this flag to
the Clang driver will also pass `--guard-cf` to the MinGW linker.
This feature is disabled by default. The option `-mguard=none` is also
available to explicitly disable this feature.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D132810
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
When linking a Fortran program, we need to add the runtime libraries to
the command line. This is exactly what we do for Linux/Darwin, but the
MSVC interface is slightly different (e.g. -libpath instead of -L).
We also remove oldnames and libcmt, since they're not needed at the
moment and they bring in more dependencies.
We also pass `/subsystem:console` to the linker so it can figure out the
right entry point. This is only needed for MSVC's `link.exe`. For LLD it
is redundant but doesn't hurt.
Differential Revision: https://reviews.llvm.org/D126291
Co-authored-by: Markus Mützel <markus.muetzel@gmx.de>
Clang has custom handling of --no-demangle, where it is removed
from the input -Wl and -Xlinker options, and readded specifically
by the drivers where it's known to be supported.
Both ld.bfd and lld support the --no-demangle option. This handles
the option in the same way as in ToolChains/Gnu.cpp.
Differential Revision: https://reviews.llvm.org/D114064
The driver uses class SanitizerArgs to store parsed sanitizer arguments. It keeps a cached
SanitizerArgs object in ToolChain and uses it for different jobs. This does not work if
the sanitizer options are different for different jobs, which could happen when an
offloading toolchain translates the options for different jobs.
To fix this, SanitizerArgs should be created by using the actual arguments passed
to jobs instead of the original arguments passed to the driver, since the toolchain
may change the original arguments. And the sanitizer arguments should be diagnose
once.
This patch also fixes HIP toolchain for handling -fgpu-sanitize: a warning is emitted
for GPU's not supporting sanitizer and skipped. This is for backward compatibility
with existing -fsanitize options. -fgpu-sanitize is also turned on by default.
Reviewed by: Artem Belevich, Evgenii Stepanov
Differential Revision: https://reviews.llvm.org/D111443
For x86, most contempory mingw toolchains use i686 as 32 bit
x86 arch target.
As long as the target triple is set to the right form, this works
fine, either as the compiler's default target, or via e.g.
a triple prefix like i686-w64-mingw32-clang.
However, if the unprefixed toolchain targets x86_64, but the user
tries to switch it to target 32 bit by adding the -m32 option, the
computeTargetTriple function in Clang, together with
Triple::get32BitArchVariant, sets the arch to i386. This causes
the right sysroot to not be found.
When targeting an arch where there are potential spelling ambiguities
with respect to the sysroots (i386 and arm), check if the driver can
find a sysroot with the arch name - if not, try a couple other
candidates.
Differential Revision: https://reviews.llvm.org/D111952
This string isn't a plain architecture name, but contains the whole
subdir name used for the sysroot, which often is equal to the target
triple.
Differential Revision: https://reviews.llvm.org/D112387
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
Moving `InputInfo.h` from `lib/Driver/` into `include/Driver` to be able to expose it in an API consumed from outside of `clangDriver`.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D106787
This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.cpp)
isn't touched.
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
