| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a fragment of a compilation database for each compilation
This patch adds a new option called -gen-cdb-fragment-path to the driver,
which can be used to specify a directory path to which clang can emit a fragment
of a CDB for each compilation it needs to invoke.
This option emits the same CDB contents as -MJ, and will be ignored if -MJ is specified.
Differential Revision: https://reviews.llvm.org/D66555
llvm-svn: 369938
|
|
|
|
|
|
|
|
|
| |
-dA was in the d_group, which is a preprocessor state dumping group.
However -dA is a debug flag to cause a verbose asm. It was already
implemented to do the same thing as -fverbose-asm, so make it just be an
alias.
llvm-svn: 369926
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been working on a new tool, llvm-ifs, for merging interface stub files
generated by clang and I've iterated on my derivative format of TBE to a newer
format. llvm-ifs will only support the new format, so I am going to drop the
older experimental interface stubs formats in this commit to make things
simpler.
Differential Revision: https://reviews.llvm.org/D66573
llvm-svn: 369719
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After posting llvm-ifs on phabricator, I made some progress in hardening up how
I think the format for Interface Stubs should look. There are a number of
things I think the TBE format was missing (no endianness, no info about the
Object Format because it assumes ELF), so I have added those and broken off
from being as similar to the TBE schema. In a subsequent commit I can drop the
other formats.
An example of how The format will look is as follows:
--- !experimental-ifs-v1
IfsVersion: 1.0
Triple: x86_64-unknown-linux-gnu
ObjectFileFormat: ELF
Symbols:
_Z9nothiddenv: { Type: Func }
_Z10cmdVisiblev: { Type: Func }
...
The format is still marked experimental.
Differential Revision: https://reviews.llvm.org/D66446
llvm-svn: 369715
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
update 3 or newer"
This broke compiling some ASan tests with never versions of MSVC/the Win
SDK, see https://crbug.com/996675
> MSVC 2017 update 3 (_MSC_VER 1911) enables /Zc:twoPhase by default, and
> so should clang-cl:
> https://docs.microsoft.com/en-us/cpp/build/reference/zc-twophase
>
> clang-cl takes the MSVC version it emulates from the -fmsc-version flag,
> or if that's not passed it tries to check what the installed version of
> MSVC is and uses that, and failing that it uses a default version that's
> currently 1911. So this changes the default if no -fmsc-version flag is
> passed and no installed MSVC is detected. (It also changes the default
> if -fmsc-version is passed or MSVC is detected, and either indicates
> _MSC_VER >= 1911.)
>
> As mentioned in the MSDN article, the Windows SDK header files in
> version 10.0.15063.0 (Creators Update or Redstone 2) and earlier
> versions do not work correctly with /Zc:twoPhase. If you need to use
> these old SDKs with a new clang-cl, explicitly pass /Zc:twoPhase- to get
> the old behavior.
>
> Fixes PR43032.
>
> Differential Revision: https://reviews.llvm.org/D66394
llvm-svn: 369647
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC 2017 update 3 (_MSC_VER 1911) enables /Zc:twoPhase by default, and
so should clang-cl:
https://docs.microsoft.com/en-us/cpp/build/reference/zc-twophase
clang-cl takes the MSVC version it emulates from the -fmsc-version flag,
or if that's not passed it tries to check what the installed version of
MSVC is and uses that, and failing that it uses a default version that's
currently 1911. So this changes the default if no -fmsc-version flag is
passed and no installed MSVC is detected. (It also changes the default
if -fmsc-version is passed or MSVC is detected, and either indicates
_MSC_VER >= 1911.)
As mentioned in the MSDN article, the Windows SDK header files in
version 10.0.15063.0 (Creators Update or Redstone 2) and earlier
versions do not work correctly with /Zc:twoPhase. If you need to use
these old SDKs with a new clang-cl, explicitly pass /Zc:twoPhase- to get
the old behavior.
Fixes PR43032.
Differential Revision: https://reviews.llvm.org/D66394
llvm-svn: 369402
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an option group for all of the -mlong-double-* options and make
-mlong-double-80 restore the default long double behavior for X86. The
motivations are that GNU accepts the -mlong-double-80 option and that complex
Makefiles often need a way of undoing earlier options. Prior to this commit, if
one chooses 64-bit or 128-bit long double for X86, there is no way to undo that
choice and restore the 80-bit behavior.
Differential Revision: https://reviews.llvm.org/D66055
llvm-svn: 369183
|
|
|
|
|
|
|
| |
This reverts commit 250aafa2c4a1bc2395edfe8d4365545bbe56fffe.
Caused buildbot failures -- still investigating.
llvm-svn: 369170
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an option group for all of the -mlong-double-* options and make
-mlong-double-80 restore the default long double behavior for X86. The
motivations are that GNU accepts the -mlong-double-80 option and that complex
Makefiles often need a way of undoing earlier options. Prior to this commit, if
one chooses 64-bit or 128-bit long double for X86, there is no way to undo that
choice and restore the 80-bit behavior.
Differential Revision: https://reviews.llvm.org/D66055
llvm-svn: 369152
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
off.
This fixes a regression from r365860: As that commit message
states, there are 3 valid states targeted by the combination of
-f(no-)omit-frame-pointer and -m(no-)omit-leaf-frame-pointer.
After r365860 it's impossible to get from state 10 (omit just
leaf frame pointers) to state 11 (omit all frame pointers)
in a single command line without getting a warning.
This change restores that functionality.
Fixes PR42966.
Differential Revision: https://reviews.llvm.org/D66142
llvm-svn: 368728
|
|
|
|
| |
llvm-svn: 368328
|
|
|
|
|
|
|
|
| |
We were calculating twice ilp32/lp64. Do this in one place instead.
Differential Revision: https://reviews.llvm.org/D48357
llvm-svn: 368128
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are times when we wish to explicitly control the C++ standard
library search paths used by the driver. For example, when we're
building against the Android NDK, we might want to use the NDK's C++
headers (which have a custom inline namespace) even if we have C++
headers installed next to the driver. We might also be building against
a non-standard directory layout and wanting to specify the C++ standard
library include directories explicitly.
We could accomplish this by passing -nostdinc++ and adding an explicit
-isystem for our custom search directories. However, users of our
toolchain may themselves want to use -nostdinc++ and a custom C++ search
path (libc++'s build does this, for example), and our added -isystem
won't respect the -nostdinc++, leading to multiple C++ header
directories on the search path, which causes build failures.
Add a new driver option -stdlib++-isystem to support this use case.
Passing this option suppresses adding the default C++ library include
paths in the driver, and it also respects -nostdinc++ to allow users to
still override the C++ library paths themselves.
It's a bit unfortunate that we end up with both -stdlib++-isystem and
-cxx-isystem, but their semantics differ significantly. -cxx-isystem is
unaffected by -nostdinc++ and is added to the end of the search path
(which is not appropriate for C++ standard library headers, since they
often #include_next into other system headers), while -stdlib++-isystem
respects -nostdinc++, is added to the beginning of the search path, and
suppresses the default C++ library include paths.
Differential Revision: https://reviews.llvm.org/D64089
llvm-svn: 367982
|
|
|
|
|
|
| |
F_{None,Text,Append} are kept for compatibility since r334221.
llvm-svn: 367800
|
|
|
|
|
|
| |
Just a simple fix of Werror problem after r367165.
llvm-svn: 367177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
different approach
This morally relands r365703 (and r365714), originally reviewed at
https://reviews.llvm.org/D64527, but with a different implementation.
Relanding the same approach with a fix for the revert reason got a bit
involved (see https://reviews.llvm.org/D65108) so use a simpler approach
with a more localized implementation (that in return duplicates code
a bit more).
This approach also doesn't validate flags for the integrated assembler
if the assembler step doesn't run.
Fixes PR42066.
Differential Revision: https://reviews.llvm.org/D65233
llvm-svn: 367165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move `-ftime-trace-granularity` option to frontend options. Without patch
this option is showed up in the help for any tool that links libSupport.
Reviewers: sammccall
Subscribers: hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65202
llvm-svn: 366911
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with '-mframe-pointer'
After D56351 and D64294, frame pointer handling is migrated to tri-state
(all, non-leaf, none) in clang driver and on the function attribute.
This patch makes the frame pointer handling cc1 option tri-state.
Reviewers: chandlerc, rnk, t.p.northover, MaskRay
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D56353
llvm-svn: 366645
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with Solaris 11.4 (which is now the required minimal version), Solaris does
support __cxa_atexit. This patch reflects that.
One might consider removing the affected tests altogether instead of inverting them,
as is done on other targets.
Besides, this lets two ASan tests PASS:
AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc
Tested on x86_64-pc-solaris2.11 and sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64491
llvm-svn: 366305
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch applies clang-tidy's bugprone-argument-comment tool
to LLVM, clang and lld source trees. Here is how I created this
patch:
$ git clone https://github.com/llvm/llvm-project.git
$ cd llvm-project
$ mkdir build
$ cd build
$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \
-DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \
-DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \
-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm
$ ninja
$ parallel clang-tidy -checks='-*,bugprone-argument-comment' \
-config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \
::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h}
llvm-svn: 366177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc PowerPC supports 3 representations of long double:
* -mlong-double-64
long double has the same representation of double but is mangled as `e`.
In clang, this is the default on AIX, FreeBSD and Linux musl.
* -mlong-double-128
2 possible 128-bit floating point representations:
+ -mabi=ibmlongdouble
IBM extended double format. Mangled as `g`
In clang, this is the default on Linux glibc.
+ -mabi=ieeelongdouble
IEEE 754 quadruple-precision format. Mangled as `u9__ieee128` (`U10__float128` before gcc 8.2)
This is currently unavailable.
This patch adds -mabi=ibmlongdouble and -mabi=ieeelongdouble, and thus
makes the IEEE 754 quadruple-precision long double available for
languages supported by clang.
Reviewed By: hfinkel
Differential Revision: https://reviews.llvm.org/D64283
llvm-svn: 366044
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts r365703 (git commit 101c1afdfd1c88f05da94c6fd317b489bb704f40)
and r365714.
This broke some autoconf-style assembler flags checks in the Linux
build:
https://github.com/ClangBuiltLinux/linux/issues/598
llvm-svn: 365956
|
|
|
|
| |
llvm-svn: 365898
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes the driver option -mlong-double-128 available for X86
and PowerPC. The CC1 option -mlong-double-128 is available on all targets
for users to test on unsupported targets.
On PowerPC, -mlong-double-128 uses the IBM extended double format
because we don't support -mabi=ieeelongdouble yet (D64283).
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D64277
llvm-svn: 365866
|
|
|
|
|
|
|
| |
NetBSD, Linux, CloudABI and Hurd already omit frame pointer for PowerPC.
Make it do so for other platforms.
llvm-svn: 365862
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-m(no-)?omit-leaf-frame-pointer
Use a tri-state enum to represent shouldUseFramePointer() and
shouldUseLeafFramePointer().
This simplifies the logic and fixes PR9825:
-fno-omit-frame-pointer doesn't imply -mno-omit-leaf-frame-pointer.
and PR24003:
/Oy- /O2 should not omit leaf frame pointer: this matches MSVC x86-32.
(/Oy- is a no-op on MSVC x86-64.)
and:
when CC1 option -mdisable-fp-elim if absent, -momit-leaf-frame-pointer
can also be omitted.
The new behavior matches GCC:
-fomit-frame-pointer wins over -mno-omit-leaf-frame-pointer
-fno-omit-frame-pointer loses out to -momit-leaf-frame-pointer
The behavior makes lots of sense. We have 4 states:
- 00) leaf retained, non-leaf retained
- 01) leaf retained, non-leaf omitted (this is invalid)
- 10) leaf omitted, non-leaf retained (what -momit-leaf-frame-pointer was designed for)
- 11) leaf omitted, non-leaf omitted
"omit" options taking precedence over "no-omit" options is the only way
to make 3 valid states representable with -f(no-)?omit-frame-pointer and
-m(no-)?omit-leaf-pointer.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D64294
llvm-svn: 365860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang currently warns when passing flags for the assembler (e.g.
-Wa,-mbig-obj) to an invocation that doesn't run the assembler (e.g.
-E).
At first sight, that makes sense -- the flag really is unused. But many
other flags don't have an effect if no assembler runs (e.g.
-fno-integrated-as, -ffunction-sections, and many others), and those
currently don't warn. So this seems more like a side effect of how
CollectArgsForIntegratedAssembler() is implemented than like an
intentional feature.
Since it's a bit inconvenient when debugging builds and adding -E,
always call CollectArgsForIntegratedAssembler() to make sure assembler
args always get claimed. Currently, this affects only these flags:
-mincremental-linker-compatible, -mimplicit-it= (on ARM), -Wa, -Xassembler
It does have the side effect that assembler options now need to be valid
even if -E is passed. Previously, `-Wa,-mbig-obj` would error for
non-coff output only if the assembler ran, now it always errors. This
too makes assembler flags more consistent with all the other flags and
seems like a progression.
Fixes PR42066.
Differential Revision: https://reviews.llvm.org/D64527
llvm-svn: 365703
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-mlong-double-64 is supported on some ports of gcc (i386, x86_64, and ppc{32,64}).
On many other targets, there will be an error:
error: unrecognized command line option '-mlong-double-64'
This patch makes the driver option -mlong-double-64 available for x86
and ppc. The CC1 option -mlong-double-64 is available on all targets for
users to test on unsupported targets.
LongDoubleSize is added as a VALUE_LANGOPT so that the option can be
shared with -mlong-double-128 when we support it in clang.
Also, make powerpc*-linux-musl default to use 64-bit long double. It is
currently the only supported ABI on musl and is also how people
configure powerpc*-linux-musl-gcc.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D64067
llvm-svn: 365412
|
|
|
|
| |
llvm-svn: 364679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The changes in D59673 made the choice redundant, since we can achieve
single-file split DWARF just by not setting an output file name.
Like llc we can also derive whether to enable Split DWARF from whether
-split-dwarf-file is set, so we don't need the flag at all anymore.
The test CodeGen/split-debug-filename.c distinguished between having set
or not set -enable-split-dwarf with -split-dwarf-file, but we can
probably just always emit the metadata into the IR.
The flag -split-dwarf wasn't used at all anymore.
Reviewers: dblaikie, echristo
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D63167
llvm-svn: 364479
|
|
|
|
| |
llvm-svn: 364453
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
By default, use `.opt.yaml`, but when a format is specified with
`-fsave-optimization-record=<format>`, use `.opt.<format>`.
llvm-svn: 363627
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Use -fsave-optimization-record=<format> to specify a different format
than the default, which is YAML.
For now, only YAML is supported.
llvm-svn: 363573
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flags
The flag is useful when wanting to create .o files that are independent
from the absolute path to the build directory. -fdebug-prefix-map= can
be used to the same effect, but it requires putting the absolute path
to the build directory on the build command line, so it still requires
the build command line to be dependent on the absolute path of the build
directory. With this flag, "-fdebug-compilation-dir ." makes it so that
both debug info and the compile command itself are independent of the
absolute path of the build directory, which is good for build
determinism (in the sense that the build is independent of which
directory it happens in) and for caching compile results.
(The tradeoff is that the debugger needs explicit configuration to know
the build directory. See also http://dwarfstd.org/ShowIssue.php?issue=171130.2)
Differential Revision: https://reviews.llvm.org/D63387
llvm-svn: 363548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With Split DWARF the resulting object file (then called skeleton CU)
contains the file name of another ("DWO") file with the debug info.
This can be a problem for remote compilation, as it will contain the
name of the file on the compilation server, not on the client.
To use Split DWARF with remote compilation, one needs to either
* make sure only relative paths are used, and mirror the build directory
structure of the client on the server,
* inject the desired file name on the client directly.
Since llc already supports the latter solution, we're just copying that
over. We allow setting the actual output filename separately from the
value of the DW_AT_[GNU_]dwo_name attribute in the skeleton CU.
Fixes PR40276.
Reviewers: dblaikie, echristo, tejohnson
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D59673
llvm-svn: 363496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the first in a series of changes trying to align clang -cc1
flags for Split DWARF with those of llc. The unfortunate side effect of
having -split-dwarf-output for single file Split DWARF will disappear
again in a subsequent change.
The change is the result of a discussion in D59673.
Reviewers: dblaikie, echristo
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D63130
llvm-svn: 363494
|
|
|
|
|
|
|
|
| |
-fsymbol-partition flag.
Differential Revision: https://reviews.llvm.org/D62636
llvm-svn: 362829
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modern ELF platforms use -fuse-init-array to emit .init_array instead of
.ctors . ld.bfd and gold --ctors-in-init-array merge .init_array and
.ctors into .init_array but lld doesn't do that.
If crtbegin*.o crtend*.o don't provide .ctors/.dtors, such .ctors in
user object files can lead to crash (see PR42002. The first and the last
elements in .ctors/.dtors are ignored - they are traditionally provided
by crtbegin*.o crtend*.o).
Call addClangTargetOptions() to ensure -fuse-init-array is rendered on
modern ELF platforms. On Hexagon, this renders -target-feature
+reserved-r19 for -ffixed-r19.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D62509
llvm-svn: 362052
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
New -cc1 arguments, such as -faddrsig, have started appearing after the
input name. I personally find it convenient for the input to be the last
argument to the compile command line, since I often need to edit it when
running crash reproduction scripts.
Differential Revision: https://reviews.llvm.org/D62270
llvm-svn: 361530
|
|
|
|
|
|
|
|
|
|
| |
-fcs-profile-generate
Follows on from r360674 which added it for -fprofile-instr-generate.
Differential Revision: https://reviews.llvm.org/D62200
llvm-svn: 361368
|
|
|
|
|
|
|
|
|
|
|
| |
Defines macro ARM_FEATURE_CMSE to 1 for v8-M targets and introduces
-mcmse option which for v8-M targets sets ARM_FEATURE_CMSE to 3.
A diagnostic is produced when the option is given on architectures
without support for Security Extensions.
Reviewed By: dmgreen, snidertm
Differential Revision: https://reviews.llvm.org/D59879
llvm-svn: 361261
|
|
|
|
|
|
|
|
|
|
| |
This is needed so lld-link can find clang_rt.profile when self hosting
on Windows with PGO. Using clang-cl as a linker knows to add the library
but self hosting, using -DCMAKE_LINKER=<...>/lld-link.exe doesn't.
Differential Revision: https://reviews.llvm.org/D61742
llvm-svn: 360674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patches fixes an issue in which the __clang_cuda_cmath.h header is being included even when cmath or math.h headers are not included.
Reviewers: jdoerfert, ABataev, hfinkel, caomhin, tra
Reviewed By: tra
Subscribers: tra, mgorny, guansong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61765
llvm-svn: 360626
|
|
|
|
|
|
| |
The double dash form is documented by GNU as, used by gcc, and accepted by llvm-mc.
llvm-svn: 360495
|