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
This patch allows clang users to print out a list of supported CPU models using
clang [--target=<target triple>] --print-supported-cpus
Then, users can select the CPU model to compile to using
clang --target=<triple> -mcpu=<model> a.c
It is a handy feature to help cross compilation.
llvm-svn: 363464
This is useful when looking for directories or files relative to the
toolchain root, e.g. include/c++/v1. This change also adds a test
to make sure this functionality doesn't regress in the future.
Differential Revision: https://reviews.llvm.org/D62558
llvm-svn: 361903
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
llvm-svn: 361885
