| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
(#110962)
Shipping a system configuration file for Clang is useful, but it limits
the relocatability of the toolchain because it bakes in a reference to
an absolute path on the file system.
Let's fix that by allowing for `CLANG_CONFIG_FILE_SYSTEM_DIR` to be set
to a relative path, and then interpreting that relative to the location
of the driver if applicable.
This would be useful for the LLVM package we ship at Homebrew. We
currently have to bake in a `DEFAULT_SYSROOT` in order to ship a
toolchain that works out of the box on macOS. If
`CLANG_CONFIG_FILE_SYSTEM_DIR` supported relative paths, we could
replace that with a configuration file which would be easier to update
when the compiled-in `DEFAULT_SYSROOT` becomes stale (e.g. on macOS
version upgrades).
We could, of course, set `CLANG_CONFIG_FILE_SYSTEM_DIR` to an absolute
path to begin with. However, we do have users who install Homebrew into
a prefix that is different from the one used on our buildbots, so doing
this would result in a broken toolchain for those users.
|
|
`*-windows-msvc` on non cl driver modes (#109607)
Similar to previous PRs I've done to change some `IsCLMode` checks to
`isWindowsMSVCEnvironment`.
I stumbled into this one accidentally last week. I did some greps and I
think this is the last one for now. All the remaining `IsCLMode` checks
are only valid for the cl driver mode.
For the `*-windows-msvc` target MSVC link.exe and lld are supported. LTO
isn't supported with MSVC link.exe and so we error when lto is enabled
but MSVC link.exe is being used. However we only error if the driver
mode is cl.
If we are using the clang driver with the `*-windows-msvc` target then
ensure an error is also emitted when LTO and MSVC link.exe are used
together.
|
|
The options are not translated correctly when targeting Vulkan using the
dxc
driver mode. Resuing the translator used for HLSL.
Fixes problem 2 in https://github.com/llvm/llvm-project/issues/108567.
|
|
a config file (#107613)
An example of this is the -mpure-code option. Without a config file
being used, an error message will print `-mpure-code`. But if a config
file is used, the error message will print `-mexecute-only`.
|
|
Reverts llvm/llvm-project#109340
Addressing the failed MAC Clang Driver test as part of this reland.
|
|
(#107664)
This adds support for:
* `muslabin32` (MIPS N32)
* `muslabi64` (MIPS N64)
* `muslf32` (LoongArch ILP32F/LP64F)
* `muslsf` (LoongArch ILP32S/LP64S)
As we start adding glibc/musl cross-compilation support for these
targets in Zig, it would make our life easier if LLVM recognized these
triples. I'm hoping this'll be uncontroversial since the same has
already been done for `musleabi`, `musleabihf`, and `muslx32`.
I intentionally left out a musl equivalent of `gnuf64` (LoongArch
ILP32D/LP64D); my understanding is that Loongson ultimately settled on
simply `gnu` for this much more common case, so there doesn't *seem* to
be a particularly compelling reason to add a `muslf64` that's basically
deprecated on arrival.
Note: I don't have commit access.
|
|
Reverts llvm/llvm-project#76838
Appears to be causing failures in MAC builders. First reverting the
patch and will investigate after.
|
|
Introduce changes necessary for UEFI X86_64 target Clang driver.
Addressed the review comments originally suggested in Phabricator.
Differential Revision: https://reviews.llvm.org/D159541
|
|
Reverts llvm/llvm-project#107734
The test modified in this commit, hip-cuid-hash.hip is failing on MacOS:
- https://lab.llvm.org/buildbot/#/builders/190/builds/5764
- https://lab.llvm.org/buildbot/#/builders/23/builds/3020
|
|
to avoid being nondeterministic due to random path in distributed build.
|
|
Right now we're bailing out too early, and `-cuid` does not get set for
the host-only compilations.
|
|
Sometimes a collection of multilibs has a gap in it, where a set of
driver command-line options can't work with any of the available
libraries.
For example, the Arm MVE extension requires special startup code (you
need to initialize FPSCR.LTPSIZE), and also benefits greatly from
-mfloat-abi=hard. So a multilib provider might build a library for
systems without MVE, and another for MVE with -mfloat-abi=hard,
anticipating that that's what most MVE users would want. But then if a
user compiles for MVE _without_ -mfloat-abi=hard, thhey can't use either
of those libraries – one has an ABI mismatch, and the other will fail to
set up LTPSIZE.
In that situation, it's useful to include a multilib.yaml entry for the
unworkable intermediate situation, and have it map to a fatal error
message rather than a set of actual libraries. Then the user gets a
build failure with a sensible explanation, instead of selecting an
unworkable library and silently generating bad output. The new
regression test demonstrates this case.
This patch introduces extra syntax into multilib.yaml, so that a record
in the `Variants` list can omit the `Dir` key, and in its place, provide
a `FatalError` key. Then, if that variant is selected, the error message
is emitted as a clang diagnostic, and multilib selection fails.
In order to emit the error message in `MultilibSet::select`, I had to
pass a `Driver &` to that function, which involved plumbing one through
to every call site, and in the unit tests, constructing one specially.
|
|
When Clang is consumed as a library, the CLANG_RESOURCE_DIR definition
is not exported from the CMake system, so external clients will be
unable to compute the same resource dir as Clang itself would, because
they don't know what to pass for the optional CustomResourceDir
argument.
All call sites except one would pass CLANG_RESOURCE_DIR to
Driver::GetResourcesPath. It seems the one exception in libclang
CIndexer was an oversight.
Move the use of CLANG_RESOURCE_DIR into GetResourcesPath and remove the
optional argument to avoid this inconsistency between internal and
external clients.
|
|
targets" (#104563)
This reverts llvm/llvm-project#104037 /
7227b44f928a87b5d7fb05bd1539fdfb6d4958dc.
This change had the unintended consequence of making e.g. `clang -target
armv7-windows-gnu --print-target-triple` output
`thumbv7-unknown-windows-gnu` rather than `armv7-unknown-windows-gnu`.
|
|
The target needs to be initialized in order to compute the correct
target triple from the command line. Without initialized targets the OS
component of the triple might not reflect what would be computed by the
driver for an actual compiler invocation.
Fixes https://github.com/llvm/llvm-project/issues/61762
|
|
Through the new `-foffload-via-llvm` flag, CUDA kernels can now be
lowered to the LLVM/Offload API. On the Clang side, this is simply done
by using the OpenMP offload toolchain and emitting calls to `llvm*`
functions to orchestrate the kernel launch rather than `cuda*`
functions. These `llvm*` functions are implemented on top of the
existing LLVM/Offload API.
As we are about to redefine the Offload API, this wil help us in the
design process as a second offload language.
We do not support any CUDA APIs yet, however, we could:
https://www.osti.gov/servlets/purl/1892137
For proper host execution we need to resurrect/rebase
https://tianshilei.me/wp-content/uploads/2021/12/llpp-2021.pdf
(which was designed for debugging).
```
❯❯❯ cat test.cu
extern "C" {
void *llvm_omp_target_alloc_shared(size_t Size, int DeviceNum);
void llvm_omp_target_free_shared(void *DevicePtr, int DeviceNum);
}
__global__ void square(int *A) { *A = 42; }
int main(int argc, char **argv) {
int DevNo = 0;
int *Ptr = reinterpret_cast<int *>(llvm_omp_target_alloc_shared(4, DevNo));
*Ptr = 7;
printf("Ptr %p, *Ptr %i\n", Ptr, *Ptr);
square<<<1, 1>>>(Ptr);
printf("Ptr %p, *Ptr %i\n", Ptr, *Ptr);
llvm_omp_target_free_shared(Ptr, DevNo);
}
❯❯❯ clang++ test.cu -O3 -o test123 -foffload-via-llvm --offload-arch=native
❯❯❯ llvm-objdump --offloading test123
test123: file format elf64-x86-64
OFFLOADING IMAGE [0]:
kind elf
arch gfx90a
triple amdgcn-amd-amdhsa
producer openmp
❯❯❯ LIBOMPTARGET_INFO=16 ./test123
Ptr 0x155448ac8000, *Ptr 7
Ptr 0x155448ac8000, *Ptr 42
```
|
|
|
|
Minor readability improvement (IMHO). Also makes it easier to find the
places where we are getting the offload lto mode.
|
|
On Darwin, -print-libgcc-file-name was returning a nonsensical result.
It would return the name of the library that would be used by the
default toolchain implementation, but that was something that didn't
exist on Darwin.
Fixing this requires initializing the Darwin toolchain before processing
`-print-libgcc-file-name`. Previously, the Darwin toolchain would only
be initialized when building the jobs for this compilation, which is too
late since `-print-libgcc-file-name` requires the toolchain to be
initialized in order to provide the right results.
rdar://90633749
Co-authored-by: Gabor Horvath <gaborh@apple.com>
|
|
bb83a3d introduced `--print-enabled-extensions` command line option for
AArch64. This patch introduces RISC-V support for this option. This patch
adds documentation for this option.
`riscvExtensionsHelp` is renamed to `printSupportedExtensions` to by
synonymous with AArch64 and so it is clear what that function does.
|
|
(#97965)
See the discussion in
https://github.com/llvm/llvm-project/pull/94352#discussion_r1657074801
|
|
Rename `CudaArch` to `OffloadArch` to better reflect its content and the
use.
Apply a similar rename to helpers handling the enum.
|
|
In
```
/tmp/StaticDebug/bin/clang -ccc-print-phases -lsomelib -fopenmp=libomp --target=powerpc64-ibm-linux-gnu -fopenmp-targets=x86_64-pc-linux-gnu,powerpc64-ibm-linux-gnu clang/test/Driver/openmp-offload.c clang/test/Driver/openmp-offload.c
```
Both ToolChains have one single empty arch. llvm::sort in
LLVM_ENABLE_EXPENSIVE_CHECKS=on builds could swap the two entries.
Fixes: 255986e27fcf9f0b36f7a23fbe030fcca1ba0249
|
|
(#95805) (#96795)
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.
The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.
As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
|
|
Reverts llvm/llvm-project#95805 due to test failures caught by the
buildbots.
|
|
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.
The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.
As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
|
|
This patch augments the HIPAMD driver to allow it to target AMDGCN
flavoured SPIR-V compilation. It's mostly straightforward, as we re-use
some of the existing SPIRV infra, however there are a few notable
additions:
- we introduce an `amdgcnspirv` offload arch, rather than relying on
using `generic` (this is already fairly overloaded) or simply using
`spirv` or `spirv64` (we'll want to use these to denote unflavoured
SPIRV, once we bring up that capability)
- initially it is won't be possible to mix-in SPIR-V and concrete AMDGPU
targets, as it would require some relatively intrusive surgery in the
HIPAMD Toolchain and the Driver to deal with two triples
(`spirv64-amd-amdhsa` and `amdgcn-amd-amdhsa`, respectively)
- in order to retain user provided compiler flags and have them
available at JIT time, we rely on embedding the command line via
`-fembed-bitcode=marker`, which the bitcode writer had previously not
implemented for SPIRV; we only allow it conditionally for AMDGCN
flavoured SPIRV, and it is handled correctly by the Translator (it ends
up as a string literal)
Once the SPIRV BE is no longer experimental we'll switch to using that
rather than the translator. There's some additional work that'll come
via a separate PR around correctly piping through AMDGCN's
implementation of `printf`, for now we merely handle its flags
correctly.
|
|
Flang's resource directory" (#96557)
Reverts llvm/llvm-project#90886
These changes broke linking to compiler-rt on Windows
|
|
Otherwise hip-phases.hip could fail when llvm::hash_value(StringRef)
changes.
|
|
Implements -Wmissing-include-dirs #92015
This is my first contribution and would love some feedback. Thanks!
|
|
After https://github.com/llvm/llvm-project/pull/68921, clang-cl gained
option `-x` but only for CUDA/HIP. This commit simply removes the
restriction on parameters to `-x`. Especially, it is able to use `-x
c++-module` and `-x c++-system-header` to build C++20 modules and header
units with clang-cl.
This effectively reverts commit
fe082124faa8455cc9a68be5fdf10fc46a4d066c.
Closes https://github.com/llvm/llvm-project/issues/88006.
|
|
resource directory (#90886)
This should be a NFC change for all drivers, but Flang.
|
|
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
13 under clang/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
|
|
Introduce just the option definitions and support for their existance at
a few different points in the frontend. This will be followed soon by
functionality that uses it.
Reviewers: bcardosolopes, jansvoboda11, AaronBallman, erichkeane, MaskRay
Reviewed By: erichkeane
Pull Request: https://github.com/llvm/llvm-project/pull/89030
|
|
This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.
This will allow us to generate part of RISCVISAInfo.cpp using tablegen.
|
|
This is the driver part of
https://github.com/llvm/llvm-project/pull/75894.
This patch introduces '-fexperimental-modules-reduced-bmi' to enable
generating the reduced BMI.
This patch did:
- When `-fexperimental-modules-reduced-bmi` is specified but
`--precompile` is not specified for a module unit, we'll skip the
precompile phase to avoid unnecessary two-phase compilation phases. Then
if `-c` is specified, we will generate the reduced BMI in CodeGenAction
as a by-product.
- When `-fexperimental-modules-reduced-bmi` is specified and
`--precompile` is specified, we will generate the reduced BMI in
GenerateModuleInterfaceAction as a by-product.
- When `-fexperimental-modules-reduced-bmi` is specified for a
non-module unit. We don't do anything nor try to give a warn. This is
more user friendly so that the end users can try to test and experiment
with the feature without asking help from the build systems.
The core design idea is that users should be able to enable this easily
with the existing cmake mechanisms.
The future plan for the flag is:
- Add this to clang19 and make it opt-in for 1~2 releases. It depends on
the testing feedback to decide how long we like to make it opt-in.
- Then we can announce the existing BMI generating may be deprecated and
suggesting people (end users or build systems) to enable this for 1~2
releases.
- Finally we will enable this by default. When that time comes, the term
`BMI` will refer to the reduced BMI today and the existing BMI will only
be meaningful to build systems which loves to support two phase
compilations.
I'll send release notes and document in seperate commits after this get
landed.
|
|
It's useful to have some significant build options visible in the
version when investigating problems with a specific compiler artifact.
This makes it easy to see if assertions, expensive checks, sanitizers,
etc. are enabled when checking a compiler version.
Example config line output:
Build configuration: +unoptimized, +assertions, +asan, +ubsan
|
|
Reenables b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.
Also adds a new warning for missing `--symbol-graph-dir` arg when
`--emit-extension-symbol-graphs` is provided. This also reverts the
commit that removed.
|
|
(#86676)"
This failed the test suite due to missing DiagGroup for a new warning.
This reverts commit b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.
|
|
This extends ExtractAPI to take into account symbols defined in categories to types defined in an external module.
This introduces 2 new command line flags, `--symbol-graph-dir=DIR` and `--emit-extension-symbol-graphs`, when used together this generates additional symbol graph files at `DIR/ExtendedModule@ProductName.symbols.json` for each external module that is extended in this way.
Additionally this makes some cleanups to tests to make them more resilient and cleans up the `APISet` data structure.
|
|
seperate function
Required in the review process of
https://github.com/llvm/llvm-project/pull/85050.
|
|
This adds a libc++ to modules.json as is currently used by libc++. When
libc++.so is not found the function will search for libc++.a as
fallback.
|
|
Summary:
The HIP phases do not emit the offload bundler output when we do not
invoke the final linker phase in device only mode. Check this propery.
|
|
Summary:
A recent change made the HIP compilation bundle by default. However we
don't want to do this for `-E`, which silently broke some handling.
|
|
Following of https://github.com/llvm/llvm-project/pull/82160
The reason why the above PR fails is that the `--sysroot` has lower
priority than the libc++ built from the same source. On the one hand, it
matches the codes behavior. We will add the built libc++ project paths
in the ToolChain class. But we will only add the path related to sysroot
in Linux class, which is derived from the ToolChain classes. So the
paths of just built libc++ is in the front of the paths relative to
sysroot. On the other hand, the behavior should be good from the higher
level. Since the just built libc++ has the same version number with the
just built clang, so it makes sense that these 2 compilers just matches.
So for patch it self, I hacked it by using resource dir in the test
since the resource dir has the higher priority, which is not strongly
correct since we won't do that in practice.
@kaz7 would you like to test on your environment to avoid this get
reverted again?
On the libc++ side, it shows that it lacks a `modules.json` file for the
just built libc++ directory. If we don't have that, it will be
problematic to use std modules from the just built clang and libc++
pair. Then it is not good. And I feel it may be problematic for future
compiler/standard library developers. So I feel this is somewhat a
libc++ issue that need to be fixed.
Also if we don't like the hacked test in the current patch, we must wait
for libc++ to fix this to proceed. But I feel this is somewhat odd since
the test of clang shouldn't dependent on libc++.
CC: @mordante
---------
Co-authored-by: Mark de Wever <koraq@xs4all.nl>
|
|
Move CCC_OVERRIDE_OPTIONS support to clangDriver so that it may be used outside of the
clang driver binary.
The override functionality will be used in LLDB, to apply adjustments to ClangImporter
flags. This will be useful as an escape hatch when there are issues that can be fixed
by adding or removing clang flags.
The only thing changed is the name, from `ApplyQAOverride` to `applyOverrideOptions`.
|
|
Summary:
The current behavior of HIP is that when --offload-device-only is set it
still bundles the outputs into a fat binary. Even though this is
different from how all the other targets handle this, it seems to be
dependned on by some tooling so just make it backwards compatible for
the `-fno-gpu-rdc` case.
|
|
Summary:
This default enum is used in other places, we should keep it consistent.
|
|
Summary:
The old driver embed PTX in rdc-mode and so does the `nvcc` compiler.
The new drivers currently does not do this, so we should keep it
consistent in this case. This simply requires adding the assembler
output as an input to the offloading action that gets fed to fatbin.
|
