| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
This patch breaks users using -fno-canonical-prefixes, for whom resolving
symlinks is not acceptable.
llvm-svn: 316195
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC tries to shorten system headers in depfiles using its real path
(resolving components like ".." and following symlinks). Mimic this
feature to ensure that the Ninja build tool detects the correct
dependencies when a symlink changes directory levels, see
https://github.com/ninja-build/ninja/issues/1330
An option to disable this feature is added in case "these changed header
paths may conflict with some compilation environments", see
https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00287.html
Note that the original feature request for GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974) also included paths
preprocessed output (-E) and diagnostics. That is not implemented now
since I am not sure if it breaks something else.
Differential Revision: https://reviews.llvm.org/D37954
llvm-svn: 316193
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 316127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch has the following changes
A new flag "-mhvx-length={64B|128B}" is introduced to specify the length of the vector.
Previously we have used "-mhvx-double" for 128 Bytes. This adds the target-feature "+hvx-length{64|128}b"
The "-mhvx" flag must be provided on command line to enable HVX for Hexagon. If no -mhvx-length flag
is specified, a default length is picked from the arch mentioned in this priority order from either -mhvx=vxx
or -mcpu. For v60 and v62 the default length is 64 Byte. For unknown versions, the length is 128 Byte. The
-mhvx flag adds the target-feature "+hvxv{hvx_version}"
The 64 Byte mode is soon going to be deprecated. A warning is emitted if 64 Byte is enabled. A warning is
still emitted for the default 64 Byte as well. This warning can be suppressed with a -Wno flag.
The "-mhvx-double" and "-mno-hvx-double" flags are deprecated. A warning is emitted if the driver sees
them on commandline. "-mhvx-double" is an alias to "-mhvx-length=128B"
The compilation will error out if -mhvx-length is specified with out an -mhvx/-mhvx= flag
The macro HVX_LENGTH is defined and is set to the length of the vector.
Eg: #define HVX_LENGTH 64
The macro HVX_ARCH is defined and is set to the version of the HVX.
Eg: #define HVX_ARCH 62
Differential Revision: https://reviews.llvm.org/D38852
llvm-svn: 316102
|
|
|
|
|
|
|
|
|
| |
For the shuffle instructions in reductions we need at least sm_30
but the user may want to customize the default architecture.
Differential Revision: https://reviews.llvm.org/D38883
llvm-svn: 315996
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The OS provides cross-dso CFI support starting with Android O.
Trapping mode does not require any runtime at all, and diagnostic mode
requires just ubsan-standalone.
Reviewers: pcc
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D38908
llvm-svn: 315921
|
|
|
|
|
|
|
|
| |
Currently all the consecutive bitfields are wrapped as a large integer unless there is unamed zero sized bitfield in between. The patch provides an alternative manner which makes the bitfield to be accessed as separate memory location if it has legal integer width and is naturally aligned. Such separate bitfield may split the original consecutive bitfields into subgroups of consecutive bitfields, and each subgroup will be wrapped as an integer. Now This is all controlled by an option -ffine-grained-bitfield-accesses. The alternative of bitfield access manner can improve the access efficiency of those bitfields with legal width and being aligned, but may reduce the chance of load/store combining of other bitfields, so it depends on how the bitfields are defined and actually accessed to choose when to use the option. For now the option is off by default.
Differential revision: https://reviews.llvm.org/D36562
llvm-svn: 315915
|
|
|
|
|
|
|
|
|
| |
If the user passes -nocudalib, we can live without it being present.
Simplify the code by just checking whether LibDeviceMap is empty.
Differential Revision: https://reviews.llvm.org/D38901
llvm-svn: 315902
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using lld on macOS the current level of detection between ld and
ld64 forces us to rename lld to ld.
For ELF targets we have the ld.lld alias so for MACHO we should have
ld64.lld so we can use lld without replacing the system compiler.
This also solves the additional issue of cross compiling for MACHO
where renaming lld to ld with only target ELF.
This is the clang driver component change to use this new alias.
Reviewers: ruiu, rnk
Differential Revision: https://reviews.llvm.org/D38290
llvm-svn: 315867
|
|
|
|
|
|
|
|
| |
Patch by: daxpedda
Differential Revision: https://reviews.llvm.org/D38123
llvm-svn: 315864
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
llvm-svn: 315536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
llvm-svn: 315530
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apple's API verification tool (tapi) checks that the symbols exported
from a program match a whitelist. When the program uses the profile
runtime, some additional symbols which are typically not part of the
regular whitelist must be exported.
If we're using symbol export directives along with the profile runtime
on Darwin, the driver needs to export the additional symbols to avoid
verification failures.
rdar://problem/30067753
llvm-svn: 315518
|
|
|
|
| |
llvm-svn: 315231
|
|
|
|
|
|
|
| |
Don't ignore these flags on Darwin. The old behavior of using the
dynamic runtime when neither flag is passed is preserved.
llvm-svn: 315142
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the logic for determining the `wchar_t` type information into the
driver. Rather than passing the single bit of information of
`-fshort-wchar` indicate to the frontend the desired type of `wchar_t`
through a new `-cc1` option of `-fwchar-type` and indicate the
signedness through `-f{,no-}signed-wchar`. This replicates the current
logic which was spread throughout Basic into the
`RenderCharacterOptions`.
Most of the changes to the tests are to ensure that the frontend uses
the correct type. Add a new test set under `test/Driver/wchar_t.c` to
ensure that we calculate the proper types for the various cases.
llvm-svn: 315126
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This raises our default past 1900, which controls whether char16_t is a
builtin type or not.
Implements PR34243
Reviewers: hans
Subscribers: STL_MSFT, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D38646
llvm-svn: 315107
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
* Rename -shared-libasan to -shared-libsan, keeping the old name as alias.
* Add -static-libsan for targets that default to shared.
* Remove an Android special case. It is now possible (but untested) to use static compiler-rt libraries there.
* Support libclang_rt.ubsan_standalone as a shared library.
Unlike GCC, this change applies -shared-libsan / -static-libsan to all sanitizers.
I don't see a point in multiple flags like -shared-libubsan, considering that most sanitizers
are not compatible with each other, and each link has basically a single shared/static choice.
Reviewers: vitalybuka, kcc, rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D38525
llvm-svn: 315015
|
|
|
|
|
|
|
|
|
|
|
| |
Passes 'new-pass-manager' option to the linker plugin when the new pass
manager is enabled.
Patch by Graham Yiu.
Differential Revision: https://reviews.llvm.org/D38517
llvm-svn: 314964
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38548
llvm-svn: 314926
|
|
|
|
|
|
|
|
|
|
| |
The recent fix in D38258 was wrong: getAuxTriple() only returns
non-null values for the CUDA toolchain. That is why the now added
test for PPC and X86 failed.
Differential Revision: https://reviews.llvm.org/D38372
llvm-svn: 314902
|
|
|
|
|
|
| |
Fixes PR34809
llvm-svn: 314743
|
|
|
|
| |
llvm-svn: 314558
|
|
|
|
|
|
|
|
|
| |
to have child entries describing the template parameters. This will
be on by default for SCE tuning.
Differential Revision: https://reviews.llvm.org/D14358
llvm-svn: 314444
|
|
|
|
|
|
|
|
|
|
| |
ToolChain::TranslateArgs() returns nullptr if no changes are performed.
This would currently mean that OpenMPArgs are lost. Patch fixes this
by falling back to simply using OpenMPArgs in that case.
Differential Revision: https://reviews.llvm.org/D38259
llvm-svn: 314330
|
|
|
|
|
|
|
|
|
|
|
| |
AuxTriple is not set if host and device share a toolchain. Also,
removing an argument modifies the DAL which needs to be returned
for future use.
(Move tests back to offload-openmp.c as they are not related to GPUs.)
Differential Revision: https://reviews.llvm.org/D38258
llvm-svn: 314329
|
|
|
|
|
|
|
|
|
|
| |
Parsing the argument after -Xopenmp-target allocates memory that needs
to be freed. Associate it with the final DerivedArgList after we know
which one will be used.
Differential Revision: https://reviews.llvm.org/D38257
llvm-svn: 314328
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: If we only use the compiler front-end, do not throw an error about the cuda device library not being found. This allows the front-end to be run on systems where no Cuda installation is found.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37914
llvm-svn: 314217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change ensures that we don't link in the XRay runtime when building
shared libraries with clang. This doesn't prevent us from building
shared libraris tht have XRay instrumentation sleds, but it does prevent
us from linking in the static XRay runtime into a shared library.
The XRay runtime currently doesn't support dynamic registration of
instrumentation sleds in shared objects, which we'll start enabling in
the future. That work has to happen in the back-end and in the runtime.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38226
llvm-svn: 314188
|
|
|
|
|
|
| |
Reverts r314177.
llvm-svn: 314178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change ensures that we don't link in the XRay runtime when building
shared libraries with clang. This doesn't prevent us from building
shared libraris tht have XRay instrumentation sleds, but it does prevent
us from linking in the static XRay runtime into a shared library.
The XRay runtime currently doesn't support dynamic registration of
instrumentation sleds in shared objects, which we'll start enabling in
the future. That work has to happen in the back-end and in the runtime.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38226
llvm-svn: 314177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Enable the -nocudalib flag for the OpenMP device offloading toolchain as well. Currently it can only be used for the CUDA toolchain.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, hfinkel, tra
Reviewed By: tra
Subscribers: hfinkel, cfe-commits
Differential Revision: https://reviews.llvm.org/D37913
llvm-svn: 314164
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
needed.
Summary: When composing the output file name, the path to the file is being dropped. The full path is required.
Reviewers: Hahnfeld, ABataev, caomhin, carlo.bertolli, hfinkel, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37912
llvm-svn: 314156
|
|
|
|
| |
llvm-svn: 314154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: If we only use the compiler front-end, do not throw an error about the cuda device library not being found. This allows the front-end to be run on systems where no Cuda installation is found.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37914
llvm-svn: 314150
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D37530
llvm-svn: 314138
|
|
|
|
|
|
|
| |
This code path is entirely untested and not really maintained. The
expected use here is with libc++ only.
llvm-svn: 313954
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38090
llvm-svn: 313820
|
|
|
|
| |
llvm-svn: 313319
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Flag is -fno-sanitize-use-after-dtor.
Reviewers: vitalybuka, eugenis, kcc
Reviewed By: vitalybuka, eugenis
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37867
llvm-svn: 313314
|
|
|
|
|
|
|
|
|
|
|
| |
These arguments don't (not yet at least) make sense for
the wasm lld port.
Subscribers: jfb, dschuff, jgravelle-google, aheejin
Differential Revision: https://reviews.llvm.org/D36595
llvm-svn: 313299
|
|
|
|
| |
llvm-svn: 313162
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Clang part of https://reviews.llvm.org/D37563
Reviewers: bkramer
Subscribers: vsk, cfe-commits
Differential Revision: https://reviews.llvm.org/D37564
llvm-svn: 313156
|
|
|
|
|
|
| |
[-Wdocumentation]
llvm-svn: 313128
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts rL313102 because it still fails some build bot tests.
On many linux bots it fails with the following error.
error: invalid linker name in argument '-fuse-ld=lld'
and on some windows bots also because there is no ld.lld.exe
lld-link.exe: warning: ignoring unknown argument: -fuse-ld=lld
llvm-svn: 313104
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In rL289668 the ability to specify the default linker at compile time
was added but because the MinGW driver used custom detection we could
not take advantage of this new CMAKE flag CLANG_DEFAULT_LINKER.
This is a re-apply of rL313082 which was reverted in rL313088
due to failing buildbot tests.
Differential Revision: https://reviews.llvm.org/D37727
llvm-svn: 313102
|
|
|
|
|
|
| |
https://reviews.llvm.org/D37598
llvm-svn: 313099
|
|
|
|
|
|
| |
This reverts rL313082
llvm-svn: 313088
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We make the same decision when compiling the kernel or kexts -- we
should do this in -ffreestanding mode as well to avoid size regressions
in a potentially large set of firmware projects.
It's still possible to get uwtable information in -ffreestanding mode by
compiling with -funwind-tables (I expect this to be a rare case: I
certainly haven't seen any projects like that).
Context: -munwind-tables was enabled by default for some arm targets in
r310006.
Testing: check-clang
rdar://problem/33934446
Differential Revision: https://reviews.llvm.org/D37777
llvm-svn: 313087
|
|
|
|
|
|
|
|
| |
In rL289668 the ability to specify the default linker at compile time
was added but because the MinGW driver used custom detection we could
not take advantage of this new CMAKE flag CLANG_DEFAULT_LINKER.
llvm-svn: 313082
|