| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
Even though these deps weren't needed, this makes Fuchsia driver
better match other drivers, and it may be necessary when trying to
use different C libraries on Fuchsia.
Differential Revision: https://reviews.llvm.org/D54741
llvm-svn: 347378
|
|
|
|
|
|
|
|
|
|
| |
Because SCS relies on system-provided runtime support, we can use it
together with any other sanitizer simply by linking the runtime for
the other sanitizer.
Differential Revision: https://reviews.llvm.org/D54735
llvm-svn: 347282
|
|
|
|
|
|
| |
OpenBSD/powerpc only supports Secure PLT.
llvm-svn: 347179
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
filter the files to instrument with gcov (after revert https://reviews.llvm.org/rL346659)
Summary:
the previous patch (https://reviews.llvm.org/rC346642) has been reverted because of test failure under windows.
So this patch fix the test cfe/trunk/test/CodeGen/code-coverage-filter.c.
Reviewers: marco-c
Reviewed By: marco-c
Subscribers: cfe-commits, sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D54600
llvm-svn: 347144
|
|
|
|
|
|
| |
This reverts commit r347070
llvm-svn: 347075
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Experience has shown that the functionality is useful. It makes linking
optimized clang with debug info for me a lot faster, 20s to 13s. The
type merging phase of PDB writing goes from 10s to 3s.
This removes the LLVM cl::opt and replaces it with a metadata flag.
After this change, users can do the following to use ghash:
- add -gcodeview-ghash to compiler flags
- replace /DEBUG with /DEBUG:GHASH in linker flags
Reviewers: zturner, hans, thakis, takuto.ikuta
Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D54370
llvm-svn: 347072
|
|
|
|
|
|
|
|
| |
Make the default -fno-PIC on Power PC.
Differential Revision: https://reviews.llvm.org/D53384
llvm-svn: 347070
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should be NFC change.
SplitDebugName recently started to accept the `Output` that
can be used to simplify the logic a bit, also it
seems that code in SplitDebugName that uses
OPT_fdebug_compilation_dir is simply dead.
Differential revision: https://reviews.llvm.org/D54576
llvm-svn: 347035
|
|
|
|
|
|
|
|
|
|
| |
-frewrite-imports already implies -frewrite-includes (it piggy-backs
on/extends the implementation) so there's no need to conditionally pass
-frewrite-includes when already using -frewrite-imports (& especially I
don't think these would want to be different between crash reporting and
not crash reporting)
llvm-svn: 346927
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If you're using the Microsoft ABI, chances are that you want PDBs and
codeview debug info. Currently, everyone has to remember to specific
-gcodeview by default, when it would be nice if the standard -g option
did the right thing by default.
Also, do some related cleanup of -cc1 options. When targetting the MS
C++ ABI, we probably shouldn't pass -debugger-tuning=gdb. We were also
passing -gcodeview twice, which is silly.
Reviewers: smeenai, zturner
Subscribers: aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D54499
llvm-svn: 346907
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This unfortunately results in a substantial breaking change when
switching to C++20, but it's not yet clear what / how much we should
do about that. We may want to add a compatibility conversion from
u8 string literals to const char*, similar to how C++98 provided a
compatibility conversion from string literals to non-const char*,
but that's not handled by this patch.
The feature can be disabled in C++20 mode with -fno-char8_t.
llvm-svn: 346892
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
option.
The DWARF5 specification says(Appendix F.1):
"The sections that do not require relocation, however, can be
written to the relocatable object (.o) file but ignored by the
linker or they can be written to a separate DWARF object (.dwo)
file that need not be accessed by the linker."
The first part describes a single file split DWARF feature and there
is no way to trigger this behavior atm.
Fortunately, no many changes are required to keep *.dwo sections
in a .o, the patch does that.
Differential revision: https://reviews.llvm.org/D52296
llvm-svn: 346837
|
|
|
|
|
|
|
|
| |
Fix a bug causing host code being compiled when --cude-device-only is set.
Differential Revision: https://reviews.llvm.org/D54496
llvm-svn: 346828
|
|
|
|
|
|
|
|
|
|
| |
ray's gcc installation puts C++ headers in PREFIX/include/g++ without
indicating a gcc version at all. Typically this is because the version
is encoded somewhere in PREFIX.
Differential Revision: https://reviews.llvm.org/D53770
llvm-svn: 346802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This saves a lot of relocations in optimized object files (at the cost
of some cost/increase in linked executable bytes), but gold's 32 bit
gdb-index support has a bug (
https://sourceware.org/bugzilla/show_bug.cgi?id=21894 ) so we can't
switch to this unconditionally. (& even if it weren't for that bug, one
might argue that some users would want to optimize in one direction or
the other - prioritizing object size or linked executable size)
Differential Revision: https://reviews.llvm.org/D54243
llvm-svn: 346789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: /Zc:dllexportInlines with /fallback may cause unexpected linker error. It is better to disallow compile rather than warn for this combination.
Reviewers: hans, thakis
Reviewed By: hans
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D54426
llvm-svn: 346733
|
|
|
|
|
|
| |
test/CodeGen/code-coverage-filter.c is failing under windows
llvm-svn: 346659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
filter the files to instrument with gcov
Summary:
These options are taking regex separated by colons to filter files.
- if both are empty then all files are instrumented
- if -fprofile-filter-files is empty then all the filenames matching any of the regex from exclude are not instrumented
- if -fprofile-exclude-files is empty then all the filenames matching any of the regex from filter are instrumented
- if both aren't empty then all the filenames which match any of the regex in filter and which don't match all the regex in filter are instrumented
- this patch is a follow-up of https://reviews.llvm.org/D52033
Reviewers: marco-c, vsk
Reviewed By: marco-c, vsk
Subscribers: cfe-commits, sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D52034
llvm-svn: 346642
|
|
|
|
|
|
|
|
|
|
|
| |
clang-offload-bundler creates __CLANG_OFFLOAD_BUNDLE__* sections in the bundles,
which get into the linked files. These sections are useless after linking. They waste disk
space and cause confusion for clang when directly linked with other object files, therefore
should be removed.
Differential Revision: https://reviews.llvm.org/D54275
llvm-svn: 346536
|
|
|
|
|
|
|
|
| |
-fsanitize-minimal-runtime.
Differential Revision: https://reviews.llvm.org/D54330
llvm-svn: 346526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/fallback
Summary:
This is followup of
https://reviews.llvm.org/D51340
Reviewers: hans, thakis
Reviewed By: hans
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D54298
llvm-svn: 346491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This was disabled way back in 2011, in the dark times before Driver was VFS-aware.
Also, make driver more VFS-aware :-)
This breaks one ClangTidy test (we improved the error message), will fix when
submitting.
Reviewers: ioeric
Subscribers: cfe-commits, alexfh
Differential Revision: https://reviews.llvm.org/D53958
llvm-svn: 346414
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The clang-cl driver disables access to command line options outside of the
"Core" and "CLOption" sets of command line arguments. This filtering makes it
impossible to pass arguments that are interpreted by the clang driver and not
by either 'cc1' (the frontend) or one of the other tools invoked by the driver.
An example driver-level flag is the '-fno-slp-vectorize' flag, which is
processed by the driver in Clang::ConstructJob and used to set the cc1 flag
"-vectorize-slp". There is no negative cc1 flag or -mllvm flag, so it is not
currently possible to disable the SLP vectorizer from the clang-cl driver.
This change introduces the "/clang:" argument that is available when the
driver mode is set to CL compatibility. This option works similarly to the
"-Xclang" option, except that the option values are processed by the clang
driver rather than by 'cc1'. An example usage is:
clang-cl /clang:-fno-slp-vectorize /O2 test.c
Another example shows how "/clang:" can be used to pass a flag where there is
a conflict between a clang-cl compat option and an overlapping clang driver
option:
clang-cl /MD /clang:-MD /clang:-MF /clang:test_dep_file.dep test.c
In the previous example, the unprefixed /MD selects the DLL version of the msvc
CRT, while the prefixed -MD flag and the -MF flags are used to create a make
dependency file for included headers.
One note about flag ordering: the /clang: flags are concatenated to the end of
the argument list, so in cases where the last flag wins, the /clang: flags
will be chosen regardless of their order relative to other flags on the driver
command line.
Patch by Neeraj K. Singh!
Differential revision: https://reviews.llvm.org/D53457
llvm-svn: 346393
|
|
|
|
|
|
|
|
|
|
|
| |
Some weak external symbols were added to the profile runtime in D49953,
and on Darwin, these need to be exported for tapi verification purposes.
I've tightened the test so that future breakages can be caught earlier.
rdar://45831054
llvm-svn: 346276
|
|
|
|
|
|
|
|
| |
Landed more fixes to the compiler-rt Android tests.
Original review was https://reviews.llvm.org/D53109.
llvm-svn: 346167
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r345963. We have a path forward now.
Original commit message:
The driver accidentally stopped passing the input filenames on to -cc1
in this mode due to confusion over what action was being requested.
This change also fixes a couple of crashes I encountered when passing
multiple files to such a -cc1 invocation.
llvm-svn: 346130
|
|
|
|
|
|
|
|
|
| |
-static relies on lld's behavior, but -Bstatic/dynamic is supported
across all linkers.
Differential Revision: https://reviews.llvm.org/D54082
llvm-svn: 346107
|
|
|
|
| |
llvm-svn: 346103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This CL adds /Zc:DllexportInlines flag to clang-cl.
When Zc:DllexportInlines- is specified, inline class member function is not exported if the function does not have local static variables.
By not exporting inline function, code for those functions are not generated and that reduces both compile time and obj size. Also this flag does not import inline functions from dllimported class if the function does not have local static variables.
On my 24C48T windows10 machine, build performance of chrome target in chromium repository is like below.
These stats are come with 'target_cpu="x86" enable_nacl = false is_component_build=true dcheck_always_on=true` build config and applied
* https://chromium-review.googlesource.com/c/chromium/src/+/1212379
* https://chromium-review.googlesource.com/c/v8/v8/+/1186017
Below stats were taken with this patch applied on https://github.com/llvm-project/llvm-project-20170507/commit/a05115cd4c57ff76b0f529e38118765b58ed7f2e
| config | build time | speedup | build dir size |
| with patch, PCH on, debug | 1h10m0s | x1.13 | 35.6GB |
| without patch, PCH on, debug | 1h19m17s | | 49.0GB |
| with patch, PCH off, debug | 1h15m45s | x1.16 | 33.7GB |
| without patch, PCH off, debug | 1h28m10s | | 52.3GB |
| with patch, PCH on, release | 1h13m13s | x1.22 | 26.2GB |
| without patch, PCH on, release | 1h29m57s | | 37.5GB |
| with patch, PCH off, release | 1h23m38s | x1.32 | 23.7GB |
| without patch, PCH off, release | 1h50m50s | | 38.7GB |
This patch reduced obj size and the number of exported symbols largely, that improved link time too.
e.g. link time stats of blink_core.dll become like below
| | cold disk cache | warm disk cache |
| with patch, PCH on, debug | 71s | 30s |
| without patch, PCH on, debug | 111s | 48s |
This patch's implementation is based on Nico Weber's patch. I modified to support static local variable, added tests and took stats.
Bug: https://bugs.llvm.org/show_bug.cgi?id=33628
Reviewers: hans, thakis, rnk, javed.absar
Reviewed By: hans
Subscribers: kristof.beyls, smeenai, dschuff, probinson, cfe-commits, eraman
Differential Revision: https://reviews.llvm.org/D51340
llvm-svn: 346069
|
|
|
|
|
|
|
|
|
|
| |
This avoids introducing unnecessary DT_NEEDED entries when using
C++ driver for linking C code or C++ code that doesn't use C++
standard library.
Differential Revision: https://reviews.llvm.org/D53854
llvm-svn: 346064
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fsanitize-address-poison-custom-array-cookie
Handle it in the driver and propagate it to cc1
Reviewers: rjmccall, kcc, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52615
llvm-svn: 346001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target/teams/distribute regions.
Target/teams/distribute regions exist for all the time the kernel is
executed. Thus, if the variable is declared in their context and then
escape it, we can allocate global memory statically instead of
allocating it dynamically.
Patch captures all the globalized variables in target/teams/distribute
contexts, merges them into the records, one per each target region.
Those records are then joined into the union, one per compilation unit
(to save the global memory). Those units are organized into
2 x dimensional arrays, where the first dimension is
the number of blocks per SM and the second one is the number of SMs.
Runtime functions manage this global memory space between the executing
teams.
llvm-svn: 345978
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r345803 and r345915 (a follow-up fix to r345803).
Reason: r345803 blocks our internal integrate because of the new
warnings showing up in too many places. The fix is actually correct,
we will reland it after figuring out how to integrate properly.
llvm-svn: 345963
|
|
|
|
|
|
|
|
|
| |
source files.
This suppresses certain warnings (eg, '#include_next in main source
file').
llvm-svn: 345915
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fsyntax-only.
The driver accidentally stopped passing the input filenames on to -cc1
in this mode due to confusion over what action was being requested.
This change also fixes a couple of crashes I encountered when passing
multiple files to such a -cc1 invocation.
llvm-svn: 345803
|
|
|
|
|
|
|
|
|
| |
Unwind tables are necessary even in code that doesn't support
exceptions. The tables are used for setjmp(), and by debuggers.
Differential Revision: https://reviews.llvm.org/D53618
llvm-svn: 345781
|
|
|
|
|
|
|
|
|
|
| |
When using sanitizers, add <resource_dir>/<target>/lib/<sanitizer>
to the list of library paths to support using sanitized version of
runtime libraries if available.
Differential Revision: https://reviews.llvm.org/D53487
llvm-svn: 345537
|
|
|
|
| |
llvm-svn: 345470
|
|
|
|
|
|
| |
builds timeout.
llvm-svn: 345446
|
|
|
|
|
|
| |
one of the tests can be fixed on !OpenBSD hosts.
llvm-svn: 345443
|
|
|
|
| |
llvm-svn: 345439
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r345370, as it uncovered even more issues in
tests with partial/inconsistent path normalization:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/13562
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/886
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20994
In particular, these tests seem to have failed:
Clang :: CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll
Clang :: CodeGen/thinlto-multi-module.ll
Clang :: Driver/cuda-external-tools.cu
Clang :: Driver/cuda-options.cu
Clang :: Driver/hip-toolchain-no-rdc.hip
Clang :: Driver/hip-toolchain-rdc.hip
Clang :: Driver/openmp-offload-gpu.c
At least the Driver tests could potentially be fixed by extending
the path normalization to even more places, but the issues with the
CodeGen tests are still unknown.
In addition, a number of other tests seem to have been broken in
other clang dependent tools such as clang-tidy and clangd.
llvm-svn: 345372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libtool inspects the output of $CC -v to detect what object files and
libraries are linked in by default. When clang is built as a native
windows executable, all paths are formatted with backslashes, and
the backslashes cause each argument to be enclosed in quotes. The
backslashes and quotes break further processing within libtool (which
is implemented in shell script, running in e.g. msys) pretty badly.
Between unix style pathes (that only work in tools that are linked
to the msys runtime, essentially the same as cygwin) and proper windows
style paths (with backslashes, that can easily break shell scripts
and msys environments), the best compromise is to use windows style
paths (starting with e.g. c:) but with forward slashes, which both
msys based tools, shell scripts and native windows executables can
cope with. This incidentally turns out to be the form of paths that
GCC prints out when run with -v on windows as well.
This change potentially makes the output from clang -v a bit more
inconsistent, but it is isn't necessarily very consistent to begin with.
Compared to the previous attempt in SVN r345004, this now does
the same transformation on more paths, hopefully on the right set
of paths so that all tests pass (previously some tests failed, where
path fragments that were required to be identical turned out to
use different path separators in different places). This now also
is done only for non-windows, or cygwin/mingw targets, to preserve
all backslashes for MSVC cases (where the paths can end up e.g. embedded
into PDB files. (The transformation function itself,
llvm::sys::path::convert_to_slash only has an effect when run on windows.)
Differential Revision: https://reviews.llvm.org/D53066
llvm-svn: 345370
|
|
|
|
|
|
|
|
|
|
|
| |
- Add support for -mbranch-protection=<type>[+<type>]* where
- <type> ::= [standard, none, bti, pac-ret[+b-key,+leaf]*]
- The protection emits relevant function attributes
- sign-return-address=<scope>
- sign-return-address-key=<key>
- branch-protection
llvm-svn: 345273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new driver level flag `-fcf-runtime-abi=` that allows one to specify the
runtime ABI for CoreFoundation. This controls the language interoperability.
In particular, this is relevant for generating the CFConstantString classes
(primarily through the `__builtin___CFStringMakeConstantString` builtin) which
construct a reference to the "CFObject"'s `isa` field. This type differs
between swift 4.1 and 4.2+.
Valid values for the new option include:
- objc [default behaviour] - enable ObjectiveC interoperability
- swift-4.1 - enable interoperability with swift 4.1
- swift-4.2 - enable interoperability with swift 4.2
- swift-5.0 - enable interoperability with swift 5.0
- swift [alias] - target the latest swift ABI
Furthermore, swift 4.2+ changed the layout for the CFString when building
CoreFoundation *without* ObjectiveC interoperability. In such a case, a field
was added to the CFObject base type changing it from: <{ const int*, int }> to
<{ uintptr_t, uintptr_t, uint64_t }>.
In swift 5.0, the CFString type will be further adjusted to change the length
from a uint32_t on everything but BE LP64 targets to uint64_t.
Note that the default behaviour for clang remains unchanged and the new layout
must be explicitly opted into via `-fcf-runtime-abi=swift*`.
llvm-svn: 345222
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow other generators of LLVM IR to use the auto-vectorizer
without having to change that flag.
Note: on its own, this patch will disable auto-vectorization on Hexagon
in all cases, regardless of the -fvectorize flag. There is a companion
LLVM patch that together with this one forms an NFC for clang users.
llvm-svn: 345170
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Distinguish "--autocomplete=-someflag" and "--autocomplete=-someflag,"
because the latter indicates that the user put a space before pushing tab
which should end up in a file completion.
Differential Revision: https://reviews.llvm.org/D53639
llvm-svn: 345133
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a bug that when a flag ends with '=' and no value was suggested,
clang autocompletes the flag itself.
For example, in bash, it looked like this:
```
$ clang -fmodule-file=[tab]
-> $clang -fmodule-file=-fmodule-file
```
This is not what we expect. We expect a file autocompletion when no value
was found. With this patch, pressing tab suggests files in the current
directory.
Reviewers: teemperor, ruiu
Subscribers: cfe-commits
llvm-svn: 345121
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r345004, as it broke tests when actually run
on windows; see e.g.
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/763.
This broke tests that had captured a variable containing a path
with backslashes, which failed to match cases in the output
where the path separators had been changed into forward slashes.
llvm-svn: 345005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libtool inspects the output of $CC -v to detect what object files and
libraries are linked in by default. When clang is built as a native
windows executable, all paths are formatted with backslashes, and
the backslashes cause each argument to be enclosed in quotes. The
backslashes and quotes break further processing within libtool (which
is implemented in shell script, running in e.g. msys) pretty badly.
Between unix style pathes (that only work in tools that are linked
to the msys runtime, essentially the same as cygwin) and proper windows
style paths (with backslashes, that can easily break shell scripts
and msys environments), the best compromise is to use windows style
paths (starting with e.g. c:) but with forward slashes, which both
msys based tools, shell scripts and native windows executables can
cope with. This incidentally turns out to be the form of paths that
GCC prints out when run with -v on windows as well.
This change potentially makes the output from clang -v a bit more
inconsistent, but it is isn't necessarily very consistent to begin with.
Differential Revision: https://reviews.llvm.org/D53066
llvm-svn: 345004
|