This patch added a distinct CUID for each input file, which is represented by InputAction.
clang initially creates an InputAction for each input file for the host compilation. In CUDA/HIP action
builder, each InputAction is given a CUID and cloned for each GPU arch, and the CUID is also cloned. In this way,
we guarantee the corresponding device and host compilation for the same file shared the
same CUID. On the other hand, different compilation units have different CUID.
-fuse-cuid=random|hash|none is added to control the method to generate CUID. The default
is hash. -cuid=X is also added to specify CUID explicitly, which overrides -fuse-cuid.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D95007
This patch adds AMDGPUOpenMPToolChain for supporting OpenMP
offloading to AMD GPU's.
Originally authored by Greg Rodgers
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D94961
Add powerpcle support to clang.
For FreeBSD, assume a freestanding environment for now, as we only need it in the first place to build loader, which runs in the OpenFirmware environment instead of the FreeBSD environment.
For Linux, recognize glibc and musl environments to match current usage in Void Linux PPC.
Adjust driver to match current binutils behavior regarding machine naming.
Adjust and expand tests.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D93919
There is a use case that users want to emit preprocessor
output as file and compile the preprocessor output later
with -x hip-cpp-output.
Clang emits bundled preprocessor output when users
compile with -E for combined host/device compilations.
Clang should be able to compile the bundled preprocessor
output with -x hip-cpp-output. Basically clang should
unbundle the bundled preprocessor output and launch
device and host compilation actions.
Currently there is a bug in clang driver causing bundled
preprocessor output not unbundled.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D92720
I am working on a baremetal riscv toolchain using LLVM runtime and
LLD linker. Baremetal.cpp provides most of the things needed for such
toolchain. So I have modified it to also handle riscv64/32-unknown-elf
targets alongside arm-none-eabi.
Currently, targets like riscv64-unknown-elf are handled by RISCVToolChain
which mostly expects a gcc toolchain to be present. If you dont
want the dependency on gcc-toolchain/libgloss or want to use LLD, then
RISCVToolChain is not a good fit.
So in the toolchain selection code, I have made this dependency of
RISCVToolChain on gcc toolchain explicit. It is created if gcc-toolchain
option is present. Otherwise Baremetal toolchain is created. I will be
happy to hear if there is a better way to choose between these two
toolchains.
Reviewed By: jroelofs
Differential Revision: https://reviews.llvm.org/D91442
The option -fproc-stat-report=<file> makes driver to generate child
process resource comsumption report. In the report executable name was
not quoted and it made parsing the report more difficult. With this
change the executable name is surrounded by quotation marks.
The new option `-fproc-stat-info=<file>` can be used to generate report
about used memory and execution tile of each stage of compilation.
Documentation for this option can be found in `UserManual.rst`. The
option can be used in parallel builds.
Differential Revision: https://reviews.llvm.org/D78903
This patch introduces the dependencies required to read and manage input files
provided by the command line option. It also adds the infrastructure to create
and write to output files. The output is sent to either stdout or a file
(specified with the `-o` flag).
Separately, in order to be able to test the code for file I/O, it adds
infrastructure to create frontend actions. As a basic testable example, it adds
the `InputOutputTest` FrontendAction. The sole purpose of this action is to
read a file from the command line and print it either to stdout or the output
file. This action is run by using the `-test-io` flag also introduced in this
patch (available for `flang-new` and `flang-new -fc1`). With this patch:
```
flang-new -test-io input-file.f90
```
will read input-file.f90 and print it in the output file.
The `InputOutputTest` frontend action has been introduced primarily to
facilitate testing. It is hidden from users (i.e. it's only displayed with
`--help-hidden`). Currently Clang doesn’t have an equivalent action.
`-test-io` is used to trigger the InputOutputTest action in the Flang frontend
driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1"
by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to
“flang-new -fc1” without `-E`. This way we make sure that the preprocessor is
_not_ run in the frontend driver. This is the desired behaviour: `-test-io`
should only read the input file and print it to the output stream.
co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Differential Revision: https://reviews.llvm.org/D87989
By convention the default output file for -E is "-" (stdout).
This is expected by tools like ccache, which uses output
of -E to determine if a file and its dependence has changed.
Currently clang does not use stdout as default output file for -E
for HIP, which causes ccache not working.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D88730
Currently CUDA/HIP toolchain uses "unknown" as bound arch
for offload action for fat binary. This causes -mcpu or -march
with "unknown" added in HIPToolChain::TranslateArgs or
CUDAToolChain::TranslateArgs.
This causes issue for https://reviews.llvm.org/D88377 since
HIP toolchain needs to check -mcpu in HIPToolChain::TranslateArgs.
The bound arch of offload action for fat binary is not really
used, therefore set it to CudaArch::UNUSED.
Differential Revision: https://reviews.llvm.org/D88524
When cross compiling with clang-cl, clang splits the INCLUDE env
variable around semicolons (clang/lib/Driver/ToolChains/MSVC.cpp,
MSVCToolChain::AddClangSystemIncludeArgs) and lld splits the
LIB variable similarly (lld/COFF/Driver.cpp,
LinkerDriver::addLibSearchPaths). Therefore, the consensus for
cross compilation with clang-cl and lld-link seems to be to use
semicolons, despite path lists normally being separated by colons
on unix and EnvPathSeparator being set to that.
Therefore, handle the LIB variable similarly in Clang, when
handling lib file arguments when driving linking via Clang.
This fixes commands like "clang-cl test.c -Fetest.exe kernel32.lib" in
a cross compilation setting. Normally, most users call (lld-)link
directly, but meson happens to use this command syntax for
has_function() tests.
Reapply: Change Program.h to define procid_t as ::pid_t. When included
in lldb/unittests/Host/NativeProcessProtocolTest.cpp, it is included
after an lldb namespace containing an lldb::pid_t typedef, followed
later by a "using namespace lldb;". Previously, Program.h wasn't
included in this translation unit, but now it ends up included
transitively from Process.h.
Differential Revision: https://reviews.llvm.org/D88002
This reverts commit 4d85444b31.
This commit broke building lldb's NativeProcessProtocolTest.cpp,
with errors like these:
In file included from include/llvm/Support/Process.h:32:0,
from tools/lldb/unittests/Host/NativeProcessProtocolTest.cpp:12:
include/llvm/Support/Program.h:39:11: error: reference to ‘pid_t’ is ambiguous
typedef pid_t procid_t;
/usr/include/sched.h:38:17: note: candidates are: typedef __pid_t pid_t
typedef __pid_t pid_t;
tools/lldb/include/lldb/lldb-types.h:85:18: note: typedef uint64_t lldb::pid_t
typedef uint64_t pid_t;
When cross compiling with clang-cl, clang splits the INCLUDE env
variable around semicolons (clang/lib/Driver/ToolChains/MSVC.cpp,
MSVCToolChain::AddClangSystemIncludeArgs) and lld splits the
LIB variable similarly (lld/COFF/Driver.cpp,
LinkerDriver::addLibSearchPaths). Therefore, the consensus for
cross compilation with clang-cl and lld-link seems to be to use
semicolons, despite path lists normally being separated by colons
on unix and EnvPathSeparator being set to that.
Therefore, handle the LIB variable similarly in Clang, when
handling lib file arguments when driving linking via Clang.
This fixes commands like "clang-cl test.c -Fetest.exe kernel32.lib" in
a cross compilation setting. Normally, most users call (lld-)link
directly, but meson happens to use this command syntax for
has_function() tests.
Differential Revision: https://reviews.llvm.org/D88002
Summary:
This is the first patch implementing the new Flang driver as outlined in [1],
[2] & [3]. It creates Flang driver (`flang-new`) and Flang frontend driver
(`flang-new -fc1`). These will be renamed as `flang` and `flang -fc1` once the
current Flang throwaway driver, `flang`, can be replaced with `flang-new`.
Currently only 2 options are supported: `-help` and `--version`.
`flang-new` is implemented in terms of libclangDriver, defaulting the driver
mode to `FlangMode` (added to libclangDriver in [4]). This ensures that the
driver runs in Flang mode regardless of the name of the binary inferred from
argv[0].
The design of the new Flang compiler and frontend drivers is inspired by it
counterparts in Clang [3]. Currently, the new Flang compiler and frontend
drivers re-use Clang libraries: clangBasic, clangDriver and clangFrontend.
To identify Flang options, this patch adds FlangOption/FC1Option enums.
Driver::printHelp is updated so that `flang-new` prints only Flang options.
The new Flang driver is disabled by default. To enable it, set
`-DBUILD_FLANG_NEW_DRIVER=ON` when configuring CMake and add clang to
`LLVM_ENABLE_PROJECTS` (e.g. -DLLVM_ENABLE_PROJECTS=“clang;flang;mlir”).
[1] “RFC: new Flang driver - next steps”
http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html
[2] “RFC: Adding a fortran mode to the clang driver for flang”
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html
[3] “RFC: refactoring libclangDriver/libclangFrontend to share with Flang”
http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
[4] https://reviews.llvm.org/rG6bf55804924d5a1d902925ad080b1a2b57c5c75c
co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Reviewed By: richard.barton.arm, sameeranjoshi
Differential Revision: https://reviews.llvm.org/D86089
This patch adds the initial toolchain for z/OS that will set some defaults. In subsequent patches, we plan to add support to use the system linker and assembler.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D86707
The non-standard header file `<sysexits.h>` provides some return values.
`EX_IOERR` is used to as a special value to signal a broken pipe to the clang driver.
On z/OS Unix System Services, this header file does not exists. This patch
- adds a check for `<sysexits.h>`, removing the dependency on `LLVM_ON_UNIX`
- adds a new header file `llvm/Support/ExitCodes`, which either includes
`<sysexits.h>` or defines `EX_IOERR`
- updates the users of `EX_IOERR` to include the new header file
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D83472
Once available in the relevant toolchains this will allow us to implement
LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR after D84127 by directly placing the dSYM
in the desired location instead of emitting next to the output file and moving
it.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D84572
To match GCC (either crossing or not), which doesn't prepend target triple prefixes to `exec_prefixes`.
As an example, powerpc64le-linux-gnu-gcc does not search "powerpc64le-linux-gnu-${name}" in a -B path.
Summary:
Rename VE.cpp and VE.h to VEToolchain.cpp and VEToolchain.h respectively
in order to avoid link warning message. Linker warns that VE.cpp.o and
Arch/VE.cpp.o have the same name.
Reviewers: simoll, k-ishizaka
Reviewed By: simoll
Subscribers: mgorny, cfe-commits
Tags: #llvm, #ve, #clang
Differential Revision: https://reviews.llvm.org/D82968
specified at Command creation, rather than as part of the Tool.
This resolves the hack I just added to allow Darwin toolchain to vary
its level of support based on `-mlinker-version=`.
The change preserves the _current_ settings for response-file support.
Some tools look likely to be declaring that they don't support
response files in error, however I kept them as-is in order for this
change to be a simple refactoring.
Differential Revision: https://reviews.llvm.org/D82782
This reverts commit f570d58104.
The test was failing on MacOS if you set
LLVM_DEFAULT_TARGET_TRIPLE. For example if you set it to
"x86_64-apple-darwin" clang actually uses
"x86_64-apple-darwin<version>".
To fix this get default triple from clang itself during the
test instead of substituting it in via lit.
Add GNU Static Lib Tool, which supports the --emit-static-lib
flag. For HIP, a static library archive will be created and
consist of HIP Fat Binary host object with the device images embedded.
Using llvm-ar to create the static archive. Also, delete existing
output file to ensure a new archive is created each time.
Reviewers: yaxunl, tra, rjmccall, echristo
Subscribers: echristo, JonChesterfield, scchan, msearles
Differential Revision: https://reviews.llvm.org/D78759
This patch is a follow up on https://reviews.llvm.org/D78759.
Extract the HIP Linker script from generic GNU linker,
and move it into HIP ToolChain. Update OffloadActionBuilder
Link actions feature to apply device linking and host linking
actions separately. Using MC Directives, embed the device images
and define symbols.
Reviewers: JonChesterfield, yaxunl
Subscribers: tra, echristo, jdoerfert, msearles, scchan
Differential Revision: https://reviews.llvm.org/D81963
Summary:
As seen in:
https://bugs.llvm.org/show_bug.cgi?id=45693
When clang looks for a tool it has a set of
possible names for it, in priority order.
Previously it would look for these names in
the program path. Then look for all the names
in the PATH.
This means that aarch64-none-elf-gcc on the PATH
would lose to gcc in the program path.
(which was /usr/bin in the bug's case)
This changes that logic to search each name in both
possible locations, then move to the next name.
Which is more what you would expect to happen when
using a non default triple.
(-B prefixes maybe should follow this logic too,
but are not changed in this patch)
Subscribers: kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79988
Summary:
We're trying to use the --config options to pass distro specific
options for Fedora via the CFLAGS variable. However, some projects
end up using the CFLAGS variable multiple times in their command line,
which leads to an error when --config is used.
This patch resolves this issue by allowing more than one --config option
on the command line as long as the file names are the same.
Reviewers: sepavloff, hfinkel
Reviewed By: sepavloff
Subscribers: cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81424
This patch is a follow up on https://reviews.llvm.org/D81627.
In addition to default -fno-gpu-rdc case, this patches let
HIP toolchain not use llvm-link/opt/llc to link device code
for -fgpu-rdc case. Instead, uses standard lto.
This will eliminate some redundant optimizations and speed
up the compilation/linking.
Differential Revision: https://reviews.llvm.org/D81861
Currently HIP toolchain calls clang to emit bitcode then calls opt/llc for device compilation for the default -fno-gpu-rdc
case, which is unnecessary since clang is able to compile a single source file to ISA.
This patch fixes the HIP action builder and toolchain so that the default -fno-gpu-rdc can be done like a canonical
toolchain, i.e. one clang -cc1 invocation to compile source code to ISA.
This can avoid unnecessary processes to speed up the compilation, and avoid redundant LLVM passes which are
performed in clang -cc1 and opt.
Differential Revision: https://reviews.llvm.org/D81627
Summary:
- In HIP, just as the regular device-only compilation, the device-only
relocatable code compilation should not involve offload bundle.
- In addition, that device-only relocatable code compilation should have
the similar 3 steps, namely preprocessor, compile, and backend, to the
regular code generation with `-emit-llvm`.
Reviewers: yaxunl, tra
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81427
We need a way to know supported targets by clang since
people may use clang as assembler and they want to
choose the clang which supports their target.
This patch let clang print registered targets when
--version option is passed to clang.
Differential Revision: https://reviews.llvm.org/D79210
Currently the library is separately linked, but this isn't correct to
implement fast math flags correctly. Each module should get the
version of the library appropriate for its combination of fast math
and related flags, with the attributes propagated into its functions
and internalized.
HIP already maintains the list of libraries, but this is not used for
OpenCL. Unfortunately, HIP uses a separate --hip-device-lib argument,
despite both languages using the same bitcode library. Eventually
these two searches need to be merged.
An additional problem is there are 3 different locations the libraries
are installed, depending on which build is used. This also needs to be
consolidated (or at least the search logic needs to deal with this
unnecessary complexity).
In this case we interpret the path as relative the clang driver binary.
This allows SDKs to be built that include clang along with a custom
sysroot without requiring users to specify --sysroot to point to the
directory where they installed the SDK.
See https://github.com/WebAssembly/wasi-sdk/issues/58
Differential Revision: https://reviews.llvm.org/D76653
When Clang crashes a useful message is output:
"PLEASE submit a bug report to https://bugs.llvm.org/ and include the
crash backtrace, preprocessed source, and associated run script."
A similar message is now output for all tools.
Differential Revision: https://reviews.llvm.org/D74324
As discussed in https://reviews.llvm.org/D74447, this patch disables integrated-cc1 behavior if there's more than one job to be executed. This is meant to limit memory bloating, given that currently jobs don't clean up after execution (-disable-free is always active in cc1 mode).
I see this behavior as temporary until release 10.0 ships (to ease merging of this patch), then we'll reevaluate the situation, see if D74447 makes more sense on the long term.
Differential Revision: https://reviews.llvm.org/D74490
As detailed on PR43462, clang static analyzer is complaining about a null pointer dereference as we provide a 'host' toolchain fallback if the ToolChain pointer is null, but then use that pointer anyhow to report the triple.
Tests indicate the ToolChain pointer is always valid and the 'host' code path is redundant.
Differential Revision: https://reviews.llvm.org/D74046
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Flags are clang's default UI is flags.
We can have an env var in addition to that, but in D69825 nobody has yet
mentioned why this needs an env var, so omit it for now. If someone
needs to set the flag via env var, the existing CCC_OVERRIDE_OPTIONS
mechanism works for it (set CCC_OVERRIDE_OPTIONS=+-fno-integrated-cc1
for example).
Also mention the cc1-in-process change in the release notes.
Also spruce up the test a bit so it actually tests something :)
Differential Revision: https://reviews.llvm.org/D72769
When clang is invoked with a source file without -c or -S, it creates a
cc1 job, a linker job and if debug info is requested, a dsymutil job. In
case of remarks, we should also create a dsymutil job to avoid losing
the remarks that will be generated in a tempdir that gets removed.
Differential Revision: https://reviews.llvm.org/D71675
This patch allows for -o to be used with -c when compiling with clang
interface stubs enabled. This is because the second file will be an
intermediate ifs stubs file that is the text stub analog of the .o file.
Both get produces in this case, so two files.
Why are we doing this? Because we want to support the case where
interface stubs are used bu first invoking clang like so:
clang -c <other flags> -emit-interface-stubs foo.c -o foo.o
...
clang -emit-interface-stubs <.o files> -o libfoo.so
This should generate N .ifs files, and one .ifso file. Prior to this
patch, using -o with the -c invocation was not possible. Currently the
clang driver supports generating a a.out/.so file at the same time as a
merged ifs file / ifso file, but this is done by checking that the final
job is the IfsMerge job. When -c is used, the final job is a Compile job
so what this patch does is check to figure out of the job type is
TY_IFS_CPP.
Differential Revision: https://reviews.llvm.org/D70763
On Darwin the clang driver does not invoke Driver::BuildActions directly
due to the need to handle Universal apps. Because of this there is a
difference in code path where Driver::BuildUniversalActions is called
instead of Driver::BuildActions. BuildUniversalActions ends up calling
Driver::BuildAction but what it does differently is it takes the driver
actions returned and wraps them each into a BindArchAction.
In Driver::BuildJobs there is a check for '-o' to determine that
multiple files are not specified when passing -o, except for Clang
Interface Stub this need to be an exception as we actually want to write
out multiple files: for every libfoo.so we have a libfoo.ifso sidecar
ifso file, etc. To allow this to happen there is a check for
IfsMergeAction, which is permitted to write out a secondary file. Except
on Darwin, the IfsMergeAction gets wrapped in the BindArchAction by
Driver::BuildUniversalActions so the check fails.
This patch is to look inside a BindArchAction in Driver::BuildJobs to
determine if there is in fact an IfsMergeAction, and if-so (pun intended)
allow the secondary sidecard ifs/ifso file to be written out.
Third Landing Attempt (dropping any linker invocation from clang driver):
Up until now, clang interface stubs has replaced the standard
PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in
conjunction with it. So what when you build your code you will get an
a.out or lib.so as well as an interface stub file.
Example:
clang -shared -o libfoo.so -emit-interface-stubs ...
will generate both a libfoo.so and a libfoo.ifso. The .so file will
contain the code from the standard compilation pipeline and the .ifso
file will contain the ELF stub library.
Note: For driver-test.c I've added -S in order to prevent any bot failures on
bots that don't have the proper linker for their native triple. You could always
specify a triple like x86_64-unknown-linux-gnu and on bots like x86_64-scei-ps4
the clang driver would invoke regular ld instead of getting the error
'Executable "orbis-ld" doesn't exist!' but on bots like ppc64be and s390x you'd
get an error "/usr/bin/ld: unrecognised emulation mode: elf_x86_64"
Differential Revision: https://reviews.llvm.org/D70274
Second Landing Attempt:
Up until now, clang interface stubs has replaced the standard
PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in
conjunction with it. So what when you build your code you will get an
a.out or lib.so as well as an interface stub file.
Example:
clang -shared -o libfoo.so -emit-interface-stubs ...
will generate both a libfoo.so and a libfoo.ifso. The .so file will
contain the code from the standard compilation pipeline and the .ifso
file will contain the ELF stub library.
Differential Revision: https://reviews.llvm.org/D70274
Up until now, clang interface stubs has replaced the standard
PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in
conjunction with it. So what when you build your code you will get an
a.out or lib.so as well as an interface stub file.
Example:
clang -shared -o libfoo.so -emit-interface-stubs ...
will generate both a libfoo.so and a libfoo.ifso. The .so file will
contain the code from the standard compilation pipeline and the .ifso
file will contain the ELF stub library.
Differential Revision: https://reviews.llvm.org/D70274
For RISC-V the value provided to -march should determine whether to
compile for 32- or 64-bit RISC-V irrespective of the target provided to
the Clang driver. This adds a test for this flag for RISC-V and sets the
Target architecture correctly in these cases.
Differential Revision: https://reviews.llvm.org/D54214
This patch adds a new Flang mode. When in Flang mode, the driver will
invoke flang for fortran inputs instead of falling back to the GCC
toolchain as it would otherwise do.
The behaviour of other driver modes are left unmodified to preserve
backwards compatibility.
It is intended that a soon to be implemented binary in the flang project
will import libclangDriver and run the clang driver in the new flang
mode.
Please note that since the binary invoked by the driver is under
development, there will no doubt be further tweaks necessary in future
commits.
* Initial support is added for basic driver phases
* -E, -fsyntax-only, -emit-llvm -S, -emit-llvm, -S, (none specified)
* -### tests are added for all of the above
* This is more than is supported by f18 so far, which will emit errors
for those options which are unimplemented.
* A test is added that ensures that clang gives a reasonable error
message if flang is not available in the path (without -###).
* Test that the driver accepts multiple inputs in --driver-mode=flang.
* Test that a combination of C and Fortran inputs run both clang and
flang in --driver-mode=flang.
* clang/test/Driver/fortran.f95 is fixed to use the correct fortran
comment character.
Differential revision: https://reviews.llvm.org/D63607
This patch removes the remaining part of the OpenMP offload linker scripts which was used for inserting device binaries into the output linked binary. Device binaries are now inserted into the host binary with a help of the wrapper bit-code file which contains device binaries as data. Wrapper bit-code file is dynamically created by the clang driver with a help of new tool clang-offload-wrapper which takes device binaries as input and produces bit-code file with required contents. Wrapper bit-code is then compiled to an object and resulting object is appended to the host linking by the clang driver.
This is the second part of the patch for eliminating OpenMP linker script (please see https://reviews.llvm.org/D64943).
Differential Revision: https://reviews.llvm.org/D68166
llvm-svn: 374219
Currently clang does not save some of the intermediate file generated during device compilation for HIP when -save-temps is specified.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D68665
llvm-svn: 374198
Second Landing Attempt:
This patch enables end to end support for generating ELF interface stubs
directly from clang. Now the following:
clang -emit-interface-stubs -o libfoo.so a.cpp b.cpp c.cpp
will product an ELF binary with visible symbols populated. Visibility attributes
and -fvisibility can be used to control what gets populated.
* Adding ToolChain support for clang Driver IFS Merge Phase
* Implementing a default InterfaceStubs Merge clang Tool, used by ToolChain
* Adds support for the clang Driver to involve llvm-ifs on ifs files.
* Adds -emit-merged-ifs flag, to tell llvm-ifs to emit a merged ifs text file
instead of the final object format (normally ELF)
Differential Revision: https://reviews.llvm.org/D63978
llvm-svn: 374061
Sometimes it is useful to compile HIP device code to LLVM BC. It is not convenient to use clang -cc1 since
there are lots of options needed.
This patch allows clang driver to compile HIP device code to LLVM BC with -emit-llvm -c.
Differential Revision: https://reviews.llvm.org/D68284
llvm-svn: 373561
This patch enables end to end support for generating ELF interface stubs
directly from clang. Now the following:
clang -emit-interface-stubs -o libfoo.so a.cpp b.cpp c.cpp
will product an ELF binary with visible symbols populated. Visibility attributes
and -fvisibility can be used to control what gets populated.
* Adding ToolChain support for clang Driver IFS Merge Phase
* Implementing a default InterfaceStubs Merge clang Tool, used by ToolChain
* Adds support for the clang Driver to involve llvm-ifs on ifs files.
* Adds -emit-merged-ifs flag, to tell llvm-ifs to emit a merged ifs text file
instead of the final object format (normally ELF)
Differential Revision: https://reviews.llvm.org/D63978
llvm-svn: 373538
This made clang unable to open files using relative paths on network shares on
Windows (PR43204). On the bug it was pointed out that createPhysicalFileSystem()
is not terribly mature, and using it is risky. Reverting for now until there's
a clear way forward.
> Currently the `-working-directory` option does not actually impact the working
> directory for all of the clang driver, it only impacts how files are looked up
> to make sure they exist. This means that that clang passes the wrong paths
> to -fdebug-compilation-dir and -coverage-notes-file.
>
> This patch fixes that by changing all the places in the driver where we convert
> to absolute paths to use the VFS, and then calling setCurrentWorkingDirectory on
> the VFS. This also changes the default VFS for `Driver` to use a virtualized
> working directory, instead of changing the process's working directory.
>
> Differential Revision: https://reviews.llvm.org/D62271
This also revertes the part of r369938 which checked that -working-directory works.
llvm-svn: 371027
Summary:
This significantly reduces the time required to run clangd tests, by
~10%.
Should also have an effect on other tests that run command-line parsing
multiple times inside a single invocation.
Reviewers: gribozavr, sammccall
Reviewed By: sammccall
Subscribers: kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67163
llvm-svn: 370908
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
This patch simply moves code that already exists into a new function.
Specifically I think it will make the BuildActions code for building a clang
job pipeline easier to read and work with.
Differential Revision: https://reviews.llvm.org/D66058
llvm-svn: 368881
This patch removes usage of FinalPhase from anywhere outside of the scope where
it is used to do argument handling. It also adds argument based trimming of
the Phase list pulled out of the Types.def table.
Differential Revision: https://reviews.llvm.org/D65993
llvm-svn: 368734
I am working to remove this concept of the "FinalPhase" in the clang driver,
but it is used in a lot of different places to do argument handling for
different combinations of phase pipelines and arguments. I am trying to
consolidate most of the uses of "FinalPhase" into its own separate scope.
Eventually, in a subsequent patch I will move all of this stuff to a separate
function, and have more of the complication phase list construction setup into
types::getComplicationPhases.
Differential Revision: https://reviews.llvm.org/D65969
llvm-svn: 368393
Moves list of phases into Types.def table: Currently Types.def contains a
table of strings that are used to assemble a list of compilation phases to be
setup in the clang driver's jobs pipeline. This change makes it so that the table
itself contains the list of phases. A subsequent patch will remove the strings.
Differential Revision: https://reviews.llvm.org/D64098
llvm-svn: 366761
Summary:
Previously, passing -fthinlto-index= to clang required that bitcode
files be explicitly marked by -x ir. This change makes us detect files
with object file extensions as bitcode files when -fthinlto-index= is
present, so that explicitly marking them is no longer necessary.
Explicitly specifying -x ir is still accepted and continues to be part
of the test case to ensure we continue to support it.
Reviewers: tejohnson, rnk, pcc
Subscribers: mehdi_amini, steven_wu, dexonsmith, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64610
llvm-svn: 366127
This fixes an 8-year-old regression. r105763 made it so that aliases
always refer to the unaliased option – but it missed the "joined" branch
of JoinedOrSeparate flags. (r162231 then made the Args classes
non-virtual, and r169344 moved them from clang to llvm.)
Back then, there was no JoinedOrSeparate flag that was an alias, so it
wasn't observable. Now /U in CLCompatOptions is a JoinedOrSeparate alias
in clang, and warn_slash_u_filename incorrectly used the aliased arg id
(using the unaliased one isn't really a regression since that warning
checks if the undefined macro contains slash or backslash and only then
emits the warning – and no valid use will pass "-Ufoo/bar" or similar).
Also, lld has many JoinedOrSeparate aliases, and due to this bug it had
to explicitly call `getUnaliasedOption()` in a bunch of places, even
though that shouldn't be necessary by design. After this fix in Option,
these calls really don't have an effect any more, so remove them.
No intended behavior change.
(I accidentally fixed this bug while working on PR29106 but then
wondered why the warn_slash_u_filename broke. When I figured it out, I
thought it would make sense to land this in a separate commit.)
Differential Revision: https://reviews.llvm.org/D64156
llvm-svn: 365186
This change reverts r363649; effectively re-landing r363626. At this point
clang::Index::CodegenNameGeneratorImpl has been refactored into
clang::AST::ASTNameGenerator. This makes it so that the previous circular link
dependency no longer exists, fixing the previous share lib
(-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649.
Clang interface stubs (previously referred to as clang-ifsos) is a new frontend
action in clang that allows the generation of stub files that contain mangled
name info that can be used to produce a stub library. These stub libraries can
be useful for breaking up build dependencies and controlling access to a
library's internal symbols. Generation of these stubs can be invoked by:
clang -fvisibility=<visibility> -emit-interface-stubs \
-interface-stub-version=<interface format>
Notice that -fvisibility (along with use of visibility attributes) can be used
to control what symbols get generated. Currently the interface format is
experimental but there are a wide range of possibilities here.
Currently clang-ifs produces .ifs files that can be thought of as analogous to
object (.o) files, but just for the mangled symbol info. In a subsequent patch
I intend to add support for merging the .ifs files into one .ifs/.ifso file
that can be the input to something like llvm-elfabi to produce something like a
.so file or .dll (but without any of the code, just symbols).
Differential Revision: https://reviews.llvm.org/D60974
llvm-svn: 363948
This reverts commit rC363626.
clangIndex depends on clangFrontend. r363626 adds a dependency from
clangFrontend to clangIndex, which creates a circular dependency.
This is disallowed by -DBUILD_SHARED_LIBS=on builds:
CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
"clangFrontend" of type SHARED_LIBRARY
depends on "clangIndex" (weak)
"clangIndex" of type SHARED_LIBRARY
depends on "clangFrontend" (weak)
At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries.
Note, the dependency on clangIndex cannot be removed because
libclangFrontend.so is linked with -Wl,-z,defs: a shared object must
have its full direct dependencies specified on the linker command line.
In -DBUILD_SHARED_LIBS=off builds, this appears to work when linking
`bin/clang-9`. However, it can cause trouble to downstream clang library
users. The llvm build system links libraries this way:
clang main_program_object_file ... lib/libclangIndex.a ... lib/libclangFrontend.a -o exe
libclangIndex.a etc are not wrapped in --start-group.
If the downstream application depends on libclangFrontend.a but not any
other clang libraries that depend on libclangIndex.a, this can cause undefined
reference errors when the linker is ld.bfd or gold.
The proper fix is to not include clangIndex files in clangFrontend.
llvm-svn: 363649
Clang interface stubs (previously referred to as clang-ifsos) is a new frontend
action in clang that allows the generation of stub files that contain mangled
name info that can be used to produce a stub library. These stub libraries can
be useful for breaking up build dependencies and controlling access to a
library's internal symbols. Generation of these stubs can be invoked by:
clang -fvisibility=<visibility> -emit-interface-stubs \
-interface-stub-version=<interface format>
Notice that -fvisibility (along with use of visibility attributes) can be used
to control what symbols get generated. Currently the interface format is
experimental but there are a wide range of possibilities here.
Differential Revision: https://reviews.llvm.org/D60974
llvm-svn: 363626
Abhina Sreeskantharajan