Changes the default Windows target triple returned by
GetHostTriple.cmake from the old environment names (which we wanted to
move away from) to newer, normalized ones. This also requires updating
all tests to use the new systems names in constraints.
Differential Revision: https://reviews.llvm.org/D47381
llvm-svn: 339307
LLVM triple normalization is handling "unknown" and empty components
differently; for example given "x86_64-unknown-linux-gnu" and
"x86_64-linux-gnu" which should be equivalent, triple normalization
returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's
config.sub returns "x86_64-unknown-linux-gnu" for both
"x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the
triple normalization to behave the same way, replacing empty triple
components with "unknown".
This addresses PR37129.
Differential Revision: https://reviews.llvm.org/D50219
llvm-svn: 339294
This flag is deprecated. The preferred way to select the lld
flavor is by calling it by one of its aliases.
Differential Revision: https://reviews.llvm.org/D50395
llvm-svn: 339163
lld is the only supported linker that works for WebAssembly, so ensure
clang is using it for this test. This gets the tests passing when
configuring clang to use a different linker by default.
Differential Revision: https://reviews.llvm.org/D49897
llvm-svn: 339158
For some regression tests the path to the right toolchain is specified
using the -sysroot switch. However, if clang was configured with a
custom gcc toolchain (either by using GCC_INSTALL_PREFIX in cmake or the
equivalent configure command), the path to the custom gcc toolchain path
takes precedence to the one specified by sysroot. This causes several
regression tests to fail as they will be using an unexpected path. This
patch fixes this issue by adding --gcc-toolchain='' to all tests that
rely on that. The empty string causes the driver to pick the path from
sysroot instead.
This patch contain the same kind of fixes as done in rC225182
llvm-svn: 339112
The Fuchsia driver relies on lld so invoke clang with
-fuse-ld=lld. This gets the test passing when the clang default linker
is something other than lld.
Differential Revision: https://reviews.llvm.org/D49899
llvm-svn: 339036
Libc++ needs to know when aligned allocation is supported by clang, but is
otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up
generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with
alignment arguments.
This patch implements the following changes:
* The `__cpp_aligned_new` feature test macro to no longer be defined when
aligned allocation is otherwise enabled but unavailable.
* The Darwin driver no longer passes `-faligned-alloc-unavailable` when the
user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`.
* Instead of a warning Clang now generates a hard error when an aligned
allocation or deallocation function is referenced but unavailable.
Patch by Eric Fiselier.
Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith
Reviewed By: rsmith
Subscribers: Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D45015
llvm-svn: 338934
This adds tests for Armv8.4-A, and also some v8.2 and v8.3 tests that were
missing.
Differential Revision: https://reviews.llvm.org/D50068
llvm-svn: 338525
Tests added in r338294 implicitly assume that libgcc is the runtime library,
but that's not the case when the user configures Clang to use compiler-rt in
which case these tests will break. Explicitly request libgcc when invoking
clang in these tests to avoid that.
Differential Revision: https://reviews.llvm.org/D50123
llvm-svn: 338482
This change causes issues with distributed build systems, which may only
have compiler binaries without any runtime libraries. See discussion
about this on https://reviews.llvm.org/D15225.
llvm-svn: 338444
Summary:
The lib paths are not correctly picked up for OpenEmbedded sysroots (like arm-oe-linux-gnueabi) for 2 reasons:
1. OpenEmbedded sysroots are of the form <sysroot>/usr/lib/<triple>/x.y.z. This form is handled in clang but only for Freescale vendor.
2. 64-bit OpenEmbedded sysroots may not have a /usr/lib dir. So they cannot find /usr/lib64 as it is referenced as /usr/lib/../lib64 in clang.
This is a follow-up to the llvm patch: D48861
Reviewers: dlj, rengolin, fedor.sergeev, javed.absar, hfinkel, rsmith
Reviewed By: rsmith
Subscribers: rsmith, kristof.beyls, cfe-commits
Differential Revision: https://reviews.llvm.org/D48862
llvm-svn: 338294
This test fails if clang is configure with, for example, gold as the
default linker. It does not appear that this test really relies on lld
so make the checks accept ld, ld.gold and ld.bfd too.
llvm-svn: 338290
Summary:
C and C++ are interesting languages. They are statically typed, but weakly.
The implicit conversions are allowed. This is nice, allows to write code
while balancing between getting drowned in everything being convertible,
and nothing being convertible. As usual, this comes with a price:
```
unsigned char store = 0;
bool consume(unsigned int val);
void test(unsigned long val) {
if (consume(val)) {
// the 'val' is `unsigned long`, but `consume()` takes `unsigned int`.
// If their bit widths are different on this platform, the implicit
// truncation happens. And if that `unsigned long` had a value bigger
// than UINT_MAX, then you may or may not have a bug.
// Similarly, integer addition happens on `int`s, so `store` will
// be promoted to an `int`, the sum calculated (0+768=768),
// and the result demoted to `unsigned char`, and stored to `store`.
// In this case, the `store` will still be 0. Again, not always intended.
store = store + 768; // before addition, 'store' was promoted to int.
}
// But yes, sometimes this is intentional.
// You can either make the conversion explicit
(void)consume((unsigned int)val);
// or mask the value so no bits will be *implicitly* lost.
(void)consume((~((unsigned int)0)) & val);
}
```
Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda
noisy, since it warns on everything (unlike sanitizers, warning on an
actual issues), and second, there are cases where it does **not** warn.
So a Sanitizer is needed. I don't have any motivational numbers, but i know
i had this kind of problem 10-20 times, and it was never easy to track down.
The logic to detect whether an truncation has happened is pretty simple
if you think about it - https://godbolt.org/g/NEzXbb - basically, just
extend (using the new, not original!, signedness) the 'truncated' value
back to it's original width, and equality-compare it with the original value.
The most non-trivial thing here is the logic to detect whether this
`ImplicitCastExpr` AST node is **actually** an implicit conversion, //or//
part of an explicit cast. Because the explicit casts are modeled as an outer
`ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children.
https://godbolt.org/g/eE1GkJ
Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set
on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`.
So if that flag is **not** set, then it is an actual implicit conversion.
As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`.
There are potentially some more implicit conversions to be warned about.
Namely, implicit conversions that result in sign change; implicit conversion
between different floating point types, or between fp and an integer,
when again, that conversion is lossy.
One thing i know isn't handled is bitfields.
This is a clang part.
The compiler-rt part is D48959.
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]].
Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]].
Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions)
Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane
Reviewed By: rsmith, vsk, erichkeane
Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D48958
llvm-svn: 338288
Summary:
Some targets support only default set of the debug options and do not
support additional debug options, like NVPTX target. Patch introduced
virtual function supportsDebugInfoOptions() that can be overloaded
by the toolchain, checks if the target supports some debug
options and emits warning when an unsupported debug option is
found.
Reviewers: echristo
Subscribers: aprantl, JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D49148
llvm-svn: 338155
gcc 7.2 under Amazon Linux AMI sets its paths to x86_64-amazon-linux. Adding
this triple to the list of search, plus a test case to cover this.
The patch fixes the following bug reported in bugzilla:
https://bugs.llvm.org/show_bug.cgi?id=35992
Reviewers: echristo
Differential Revision: https://reviews.llvm.org/D46230
llvm-svn: 337811
Currently, support for debug_types is only present for ELF and trying to
pass -fdebug-types-section for other targets results in a crash in the
backend. Until this is fixed, we should emit a diagnostic in the front
end when the option is passed for non-linux targets.
Differential revision: https://reviews.llvm.org/D49594
llvm-svn: 337717
The runtime libraries of sanitizers are built in compiler-rt, and Clang
can be built without compiler-rt, or compiler-rt can be configured to
only build certain sanitizers. The driver should provide reasonable
diagnostics and not a link-time error when a runtime library is missing.
This patch changes the driver for OS X to only support sanitizers of
which we can find the runtime libraries. The discussion for this patch
explains the rationale
Differential Revision: https://reviews.llvm.org/D15225
llvm-svn: 337635
It still appears to be failing:
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/12825
$ "rm" "-rf" "C:\b\slave\clang-x86-windows-msvc2015\clang-x86-windows-msvc2015\stage1\tools\clang\test\Driver\Output/crmdir"
Error: 'rm' command failed, [Error 3] The system cannot find the path specified: 'C:\\b\\slave\\clang-x86-windows-msvc2015\\clang-x86-windows-msvc2015\\stage1\\tools\\clang\\test\\Driver\\Output/crmdir\\crash-report-modules-300567.cache\\vfs\\b\\slave\\clang-x86-windows-msvc2015\\clang-x86-windows-msvc2015\\llvm\\tools\\clang\\test\\Driver\\Inputs\\module\\module.modulemap'
error: command failed with exit status: 1
llvm-svn: 337629
There were some problems unearthed with version 5,
which I am going to look at.
Differential Revision: https://reviews.llvm.org/D49613
llvm-svn: 337612
Summary:
Support for this option is needed for building Linux kernel.
This is a very frequently requested feature by kernel developers.
More details : https://lkml.org/lkml/2018/4/4/601
GCC option description for -fdelete-null-pointer-checks:
This Assume that programs cannot safely dereference null pointers,
and that no code or data element resides at address zero.
-fno-delete-null-pointer-checks is the inverse of this implying that
null pointer dereferencing is not undefined.
This feature is implemented in as the function attribute
"null-pointer-is-valid"="true".
This CL only adds the attribute on the function.
It also strips "nonnull" attributes from function arguments but
keeps the related warnings unchanged.
Corresponding LLVM change rL336613 already updated the
optimizations to not treat null pointer dereferencing
as undefined if the attribute is present.
Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv
Reviewed By: jyknight
Subscribers: drinkcat, xbolva00, cfe-commits
Differential Revision: https://reviews.llvm.org/D47894
llvm-svn: 337433
which was reverted in r337336.
The problem that required a revert was fixed in r337338.
Also added a missing "REQUIRES: x86-registered-target" to one of
the tests.
Original commit message:
> Teach Clang to emit address-significance tables.
>
> By default, we emit an address-significance table on all ELF
> targets when the integrated assembler is enabled. The emission of an
> address-significance table can be controlled with the -faddrsig and
> -fno-addrsig flags.
>
> Differential Revision: https://reviews.llvm.org/D48155
llvm-svn: 337339
Causing multiple failures on sanitizer bots due to TLS symbol errors,
e.g.
/usr/bin/ld: __msan_origin_tls: TLS definition in /home/buildbots/ppc64be-clang-test/clang-ppc64be/stage1/lib/clang/7.0.0/lib/linux/libclang_rt.msan-powerpc64.a(msan.cc.o) section .tbss.__msan_origin_tls mismatches non-TLS reference in /tmp/lit_tmp_0a71tA/mallinfo-3ca75e.o
llvm-svn: 337336
By default, we emit an address-significance table on all ELF
targets when the integrated assembler is enabled. The emission of an
address-significance table can be controlled with the -faddrsig and
-fno-addrsig flags.
Differential Revision: https://reviews.llvm.org/D48155
llvm-svn: 337333
This diagnostic triggers when -fsanitize=object-size is explicitly
specified but will be a no-op (i.e, at -O0).
This diagnostic should not fail a -Werror build because it's just an
explanatory note to the user. It's not always actionable.
For example, a user may not be able to simply disable object-size,
because they want it enabled in optimized builds.
rdar://42128447
llvm-svn: 336937
Use getTriple.isMIPS64() to detect 64-bit MIPS ABIs in
FreeBSD::getSupportedSanitizers() instead of getTriple.isMIPS32().
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D49143
llvm-svn: 336710
is useful to omit the debug compilation dir when compiling assembly
files with -g. Part of PR38050.
Patch by Siddhartha Bagaria!
Differential Revision: https://reviews.llvm.org/D48989
llvm-svn: 336685
In this setup, skip adding all the default windows import libraries,
if linking to windowsapp (which replaces them, when targeting the
windows store/UWP api subset).
With GCC, the same is achieved by using a custom spec file, but
since clang doesn't use spec files, we have to allow other means of
overriding what default libraries to use (without going all the
way to using -nostdlib, which would exclude everything). The same
approach, in detecting certain user specified libraries and omitting
others from the defaults, was already used in SVN r314138.
Differential Revision: https://reviews.llvm.org/D49059
llvm-svn: 336655
Since SVN r314138, we check if the user has specified any particular
alternative msvcrt/ucrt version, and skip the default -lmsvcrt
in those cases.
In addition to the existing names checked, we should also treat
a plain -lucrt in the same way, mingw-w64 has now added a separate
import library named libucrt.a, in addition to libucrtbase.a.
Differential Revision: https://reviews.llvm.org/D49054
llvm-svn: 336654
Summary:
New flag causes crash reports to be written in the specified directory
rather than the temp directory.
Patch by Chijioke Kamanu.
Reviewers: hans, inglorion, rnk
Reviewed By: hans
Subscribers: zturner, hiraditya, llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D48601
llvm-svn: 336604
This moves the LTO-specific code for outlining from ToolChains/Clang.cpp to
ToolChains/Darwin.cpp. Passing -mllvm flags isn't sufficient for making sure
that the specified pass will actually run in LTO. This makes sure that when
-moutline is passed, the MachineOutliner will actually be added to the LTO
pass pipeline as expected.
llvm-svn: 336471
This patches adds support for passing -mcpu=native for AArch64. It will
get turned into the host CPU name, before we get the target features.
CPU = native is handled in a similar fashion in
getAArch64MicroArchFetauresFromMtune and getAArch64TargetCPU already.
Having a good test case for this is hard, as it depends on the host CPU
of the machine running the test. But we can check that native has been
replaced with something else.
When cross-compiling, we will get a CPU name from the host architecture
and get ` the clang compiler does not support '-mcpu=native'` as error
message, which seems reasonable to me.
Reviewers: rengolin, peter.smith, dlj, javed.absar, t.p.northover
Reviewed By: peter.smith
Tags: #clang
Differential Revision: https://reviews.llvm.org/D48931
llvm-svn: 336429
Implement support for MS-style PCH through headers.
This enables support for /Yc and /Yu where the through header is either
on the command line or included in the source. It replaces the current
support the requires the header also be specified with /FI.
This change adds a -cc1 option -pch-through-header that is used to either
start or stop compilation during PCH create or use.
When creating a PCH, the compilation ends after compilation of the through
header.
When using a PCH, tokens are skipped until after the through header is seen.
Patch By: mikerice
Differential Revision: https://reviews.llvm.org/D46652
llvm-svn: 336379
Summary:
Scudo works on PPC64 as is, so mark the architecture as supported for it. This
will also require a change to config-ix.cmake on the compiler-rt side.
Update the tests accordingly.
Reviewers: eugenis, alekseyshl
Reviewed By: alekseyshl
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48833
llvm-svn: 336202
Summary:
When clang required to infer target os version from --target option and
the os version is not specified in targets, check the host triple. If the
host and target are both macOS, use host triple to infer target os
version.
rdar://problem/41651999
Reviewers: arphaman, dexonsmith
Reviewed By: arphaman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48849
llvm-svn: 336168
Summary:
On RHEL, devtoolset provides a more up-to-date toolchain than the base
install, and we want to make sure all the tools use are from the same
toolchain.
Reviewers: rsmith, bruno
Reviewed By: bruno
Subscribers: bruno, cfe-commits
Differential Revision: https://reviews.llvm.org/D34848
llvm-svn: 336037
Summary:
It seems a bad idea to change the default in the middle of a release
branch due to possible changes in global ctor / dtor ordering between
.ctors and .init_array. With FreeBSD 11.0's release imminent lets change
the default now for FreeBSD 12 (the current development stream) and
later.
FreeBSD rtld has supported .init_array / .fini_array for many years. As
of Jan 1 2017 all supported FreeBSD releases and branches will have
support.
Reviewers: dim, brooks, arichardson
Reviewed By: dim, brooks, arichardson
Subscribers: bsdjhb, krytarowski, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D24867
llvm-svn: 336008
This updates -mno-outline so that it passes -enable-machine-outliner=never
instead of nothing. This puts it in sync with the behaviour in llc and
other tools.
llvm-svn: 336001
Remove _VPMergeHook from Darwin's automatically-exported symbol list for
PGO. As of r328987 this symbol is no longer weak.
An integration test in compiler-rt will follow.
rdar://41470205
llvm-svn: 335890
The resource dir path used for the multiarch runtimes support is
constructed in a platform independent way and therefore will use
native path separators on each platform. We need to make sure that
the per target runtime directory test handles both to not fail
when the test is being executed on Windows.
llvm-svn: 335810
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
Summary:
HIP should link the bitcodes with caller functions before callee functions. Also added lit test to check the ordering of the linked bitcodes is matches.
Reviewers: yaxunl, b-sumner
Reviewed By: yaxunl, b-sumner
Subscribers: cfe-commits, yaxunl, b-sumner, scchan
Differential Revision: https://reviews.llvm.org/D48667
llvm-svn: 335774
Summary:
Use oclc_daz_opt_on.amdgcn.bc bitcode when option fcuda-flush-denormal-to-zero is enabled, otherwise use oclc_daz_opt_off.amdgcn.bc bitcode. Added lit tests to verify that the correct bitcode is linked when -fcuda-flush-denormal-to-zero option is enabled or disabled.
Reviewers: yaxunl, scchan, b-sumner
Reviewed By: yaxunl, scchan, b-sumner
Subscribers: cfe-commits, yaxunl
Differential Revision: https://reviews.llvm.org/D48493
llvm-svn: 335765
FreeBSD's mips64 builds O32 binaries for /usr/lib32 by default and
thus needs to be able to link O32 binaries which requires an explicit
linker emulation. Go ahead and list all the linker emulation variants
for MIPS so that any supported MIPS ABI binary can be linked by any
linker supporting MIPS.
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D48507
llvm-svn: 335691
Instead of just saying "flag unused", we should tell the user that the
outliner isn't (at least officially) supported for some given architecture.
This adds a warning that will state something like
The 'blah' architecture does not support -moutline; flag ignored
when we call -moutline with the 'blah' architecture.
Since the outliner is still mostly an AArch64 thing, any architecture
other than AArch64 will emit this warning.
llvm-svn: 335672
FreeBSD defaults to mips3 for all MIPS ABIs with GCC as that is the
minimum MIPS architecture FreeBSD supports. Use mips3 for MIPS64 and
mips2 for MIPS32 to match.
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D48499
llvm-svn: 335653
Summary:
I am not sure anyone has tried to compile an application with sanitizers on
Android with `-static-libsan`, and a recent NDK, but it fails with:
```
.../i686-linux-android/bin/ld.gold: error: cannot find -lpthread
.../i686-linux-android/bin/ld.gold: error: cannot find -lrt
```
My understanding is that both are included in Bionic and as such are not needed,
and actually error out.
So remove the addition of those two in `linkSanitizerRuntimeDeps` when dealing
with Android, and update the tests.
I am unfamiliar with the evolution of the NDK and I am not sure if this has
always been the case or if this is somewhat of a recent evolution. I'll let
Android people chime in.
Reviewers: eugenis, pirama, srhines
Reviewed By: eugenis, srhines
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48570
llvm-svn: 335620
Similarly to CFI on virtual and indirect calls, this implementation
tries to use program type information to make the checks as precise
as possible. The basic way that it works is as follows, where `C`
is the name of the class being defined or the target of a call and
the function type is assumed to be `void()`.
For virtual calls:
- Attach type metadata to the addresses of function pointers in vtables
(not the functions themselves) of type `void (B::*)()` for each `B`
that is a recursive dynamic base class of `C`, including `C` itself.
This type metadata has an annotation that the type is for virtual
calls (to distinguish it from the non-virtual case).
- At the call site, check that the computed address of the function
pointer in the vtable has type `void (C::*)()`.
For non-virtual calls:
- Attach type metadata to each non-virtual member function whose address
can be taken with a member function pointer. The type of a function
in class `C` of type `void()` is each of the types `void (B::*)()`
where `B` is a most-base class of `C`. A most-base class of `C`
is defined as a recursive base class of `C`, including `C` itself,
that does not have any bases.
- At the call site, check that the function pointer has one of the types
`void (B::*)()` where `B` is a most-base class of `C`.
Differential Revision: https://reviews.llvm.org/D47567
llvm-svn: 335569
Summary:
This adds an option -gsplit-dwarf=<arg>. LLVM can create .dwo files in the given directory
during the implicit ThinLTO link stage.
Reviewers: tejohnson, dblaikie, pcc
Reviewed By: pcc
Subscribers: steven_wu, aprantl, JDevlieghere, yunlian, probinson, mehdi_amini, inglorion, cfe-commits
Differential Revision: https://reviews.llvm.org/D44788
llvm-svn: 335546
Pass -enable-linkonceodr-outlining by default when LTO is enabled.
The outliner shouldn't compete with any sort of linker deduplication
on linkonceodr functions when LTO is enabled. Therefore, this behaviour
should be the default.
llvm-svn: 335504
The expected behaviour of command-line flags to clang is to have
the last of -m(whatever) and -mno-(whatever) win. The outliner
didn't do that. This fixes that and updates the test.
llvm-svn: 335503
With MSVC, PCH files are created along with an object file that needs to
be linked into the final library or executable. That object file
contains the code generated when building the headers. In particular, it
will include definitions of inline dllexport functions, and because they
are emitted in this object file, other files using the PCH do not need
to emit them. See the bug for an example.
This patch makes clang-cl match MSVC's behaviour in this regard, causing
significant compile-time savings when building dlls using precompiled
headers.
For example, in a 64-bit optimized shared library build of Chromium with
PCH, it reduces the binary size and compile time of
stroke_opacity_custom.obj from 9315564 bytes to 3659629 bytes and 14.6
to 6.63 s. The wall-clock time of building blink_core.dll goes from
38m41s to 22m33s. ("user" time goes from 1979m to 1142m).
Differential Revision: https://reviews.llvm.org/D48426
llvm-svn: 335466
Summary:
This is the clang side of the change, there is a compiler-rt counterpart.
Scudo works with UBSan using `-fsanitize=scudo,integer` for example, and to do
so it embeds UBSan runtime. This makes it not compatible with the UBSan minimal
runtime, but this is something we want for production purposes.
The idea is to have a Scudo minimal runtime on the compiler-rt side that will
not embed UBSan. This is basically the runtime that is currently in use for
Fuchsia, without coverage, stacktraces or symbolization. With this, Scudo
becomes compatible with `-fsanitize-minimal-runtime`.
If this approach is suitable, I'll add the tests as well, otherwise I am open
to other options.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D48373
llvm-svn: 335352
The test makes %t.fake a symlink to %t.real by running `ln -sf %t.real
%t.fake`. If %t.fake already is a symlink to %t.real when this runs (e.g. if
the test has run before), then this effectively becomes `ln -sf %t.real %t.real`,
symlinking the directory to itself. At least on my mac, this leads to the
directory containing itself.
As fix, just remove %t.fake before creating the symlink. To clean up build dirs
on bots, also remove %t.real for a while.
https://reviews.llvm.org/D48224
llvm-svn: 334972
This code was introduced back in r178148, a change to introduce
-module-file-info - which still exists & seems like it's still tested (&
this change didn't cause any of those tests to fail).
It doesn't look like this change was necessary there - since it's about
pcm output, whereas -module-file-info looks like it's for pcm /input/.
So I'm not really sure what the original motivation was.
I'm open to ideas though, if it turns out the original change was
necessary/useful.
llvm-svn: 334778
Diasble the use of the type __float128 for PPC machines older
than Power9.
The use of -mfloat128 for PPC machine older than Power9 will result
in an error.
Differential Revision: https://reviews.llvm.org/D48088
llvm-svn: 334613
Register x20 is a callee-saved register which may be used for other
purposes in certain contexts, for example to hold special variables
within the kernel. This change adds support for reserving this register
both to frontend and backend to make this register usable for these
purposes.
Differential Revision: https://reviews.llvm.org/D46552
llvm-svn: 334531
The tests fail on Windows bots, and for me locally.
> Enable crash recovery tests on Windows, globs work in the lit internal shell now
llvm-svn: 334493
-fseh-exceptions is only meaningful for MinGW targets, and that driver
already has logic to pass either -fdwarf-exceptions or -fseh-exceptions
as appropriate. -fseh-exceptions is just a no-op for MSVC triples, and
passing it to cc1 causes unnecessary confusion.
Differential Revision: https://reviews.llvm.org/D47850
llvm-svn: 334145
HIP uses clang-offload-bundler to bundle intermediate files for host
and different gpu archs together. When a file is unbundled,
clang-offload-bundler should be called only once, and the objects
for host and different gpu archs should be passed to the next
jobs. This is because Driver maintains CachedResults which maps
triple-arch string to output files for each job.
This patch fixes a bug in Driver::BuildJobsForActionNoCache which
uses incorrect key for CachedResults for HIP which causes
clang-offload-bundler being called mutiple times and incorrect
output files being used.
It only affects HIP.
Differential Revision: https://reviews.llvm.org/D47555
llvm-svn: 334128
NFC for targets other than PS4.
Simplify users' workflow when enabling asan or ubsan and calling the linker separately.
Differential Revision: https://reviews.llvm.org/D47375
llvm-svn: 334096
Even though we use lld by default for Fuchsia, we use Gold plugin
arguments like all other drivers as lld supports Gold plugin options.
Differential Revision: https://reviews.llvm.org/D47668
llvm-svn: 333979
-no-canonical-prefixes is a weird flag: In gcc, it controls whether realpath()
is called on the path of the driver binary. It's needed to support some
usecases where gcc is symlinked to, see
https://gcc.gnu.org/ml/gcc/2011-01/msg00429.html for some background.
In clang, the resource dir is found relative to the compiler binary, and
without -no-canonical-prefixes that's an absolute path. For clang, the main use
case for -no-canonical-prefixes is to make the -resource-dir path added by the
driver relative instead of absolute. Making it relative seems like the better
default, but since neither clang not gcc have -canonical-prefixes without no-
which makes changing the default tricky, and since some symlink behaviors do
depend on the realpath() call at least for gcc, just expose
-no-canonical-prefixes in clang-cl mode.
Alternatively we could default to no-canonical-prefix-mode for clang-cl since
it's less likely to be used in symlinked scenarios, but since you already need
to about -no-canonical-prefixes for the non-clang-cl bits of your build, not
hooking this of driver mode seems better to me.
https://reviews.llvm.org/D47480
llvm-svn: 333761
Codebases that need to be compatible with the Microsoft ABI can pass
this flag to avoid issues caused by the lack of a fixed ABI for
incomplete member pointers.
Differential Revision: https://reviews.llvm.org/D47503
llvm-svn: 333498
This patch adds HIP toolchain to support HIP language mode. It includes:
Create specific compiler jobs for HIP.
Choose specific libraries for HIP.
With contribution from Greg Rodgers.
Differential Revision: https://reviews.llvm.org/D45212
llvm-svn: 333484
To support separate compile/link and linking across device IR in different source files,
a new HIP action builder is introduced. Basically it compiles/links host and device
code separately, and embed fat binary in host linking stage through linker script.
Differential Revision: https://reviews.llvm.org/D46476
llvm-svn: 333483
An intrinsic for an old instruction, as described in the Intel SDM.
Reviewers: craig.topper, rnk
Reviewed By: craig.topper, rnk
Differential Revision: https://reviews.llvm.org/D47142
llvm-svn: 333256
Summary: This allows the use of the casa instruction available in most Leon3's.
Reviewers: jyknight
Reviewed By: jyknight
Subscribers: joerg, fedor.sergeev, jrtc27, cfe-commits
Differential Revision: https://reviews.llvm.org/D47138
llvm-svn: 333157
Summary:
When https://reviews.llvm.org/D46776 landed to improve the behavior of
`llvm::OptTable::findNearest`, a PS4 buildbot began failing due to an
assertion that a suggestion "-debug-info-macro" should be provided for
the unrecognized option `clang -cc1as -debug-info-macros`. All other
buildbots succeeded in this check, and the PS4 buildbot succeeded in the
other `findNearest` tests.
Temporarily loosen this check in order to reland the `findNearest`
change.
Test Plan: check-clang
llvm-svn: 332804
NFC for targets other than PS4.
This patch is a change in behavior for PS4, in that PS4 will no longer enable
RTTI when -fexceptions is specified (RTTI and Exceptions are disabled by default
on PS4). RTTI will remain disabled except for types being thrown or caught.
Also, '-fexceptions -fno-rtti' (previously prohibited on PS4) is now accepted,
as it is for other targets.
This patch removes some PS4 specific code, making the code cleaner.
Also, in the test file rtti-options.cpp, PS4 tests where the behavior is the
same as the generic x86_64-linux are removed, making the test cleaner.
Differential Revision: https://reviews.llvm.org/D46982
llvm-svn: 332784
in gcc by https://gcc.gnu.org/ml/gcc-cvs/2018-04/msg00534.html.
The -mibt feature flag is being removed, and the -fcf-protection
option now also defines a CET macro and causes errors when used
on non-X86 targets, while X86 targets no longer check for -mibt
and -mshstk to determine if -fcf-protection is supported. -mshstk
is now used only to determine availability of shadow stack intrinsics.
Comes with an LLVM patch (D46882).
Patch by mike.dvoretsky
Differential Revision: https://reviews.llvm.org/D46881
llvm-svn: 332704
Certain tests in rtti-options.cpp are not really testing anything because they are testing for the absence of -frtti option to the cc1 process. Since the cc1 process does not take -frtti option, these tests are passing tautologically.
The RTTI mode is enabled by default in cc1, and -fno-rtti disables it. Therefore the correct way to check for enabling of RTTI is to check for the absence of -fno-rtti to cc1, and the correct way to check for disabling of RTTI is to check for the presence of -fno-rtti to cc1.
This patch fixes those tests.
Differential Revision: https://reviews.llvm.org/D46836
llvm-svn: 332384
The PS4 requires clang ABI version 6 for compatibility reasons. This change forces this and if the user specifies a different version when the PS4 target is specified, the compiler emits a warning that the specified version is being ignored.
Reviewers: probinson
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D46767
llvm-svn: 332160
The fact that libc++ depends on libc++abi and libunwind is an internal
detail that's captured by the libc++.so linker script.
Differential Revision: https://reviews.llvm.org/D46768
llvm-svn: 332138
This reverts commit SVN r331666.
It was afterwards pointed out in https://reviews.llvm.org/D46520
that #line directives lose information about what parts come from a
system header. That means the result of -E usually won't compile,
since Windows headers are typically full of warnings and
default-error warnings.
llvm-svn: 331858
Since we're working on turning the MachineOutliner by default under -Oz for
AArch64, it makes sense to have an -mno-outline flag available. This currently
doesn't do much (it basically just undoes -moutline).
When the MachineOutliner is on by default under AArch64, this flag should
set -mllvm -enable-machine-outliner=never.
llvm-svn: 331810
-dwarf-column-info is omitted if -gcodeview is specified for msvc
targets at the moment, but since -gcodeview is an option that can be
specified for any target, there's little reason to restrict this
handling to msvc targets.
This allows getting proper codeview debug info by passing -gcodeview
for e.g. MinGW targets as well.
Differential Revision: https://reviews.llvm.org/D46287
llvm-svn: 331807
Nitpicky, but the MachineOutliner is a machine-level pass, and so we should
reflect that by using "m" instead of "n".
Figured we should get this in before people get used to the letter f. :)
llvm-svn: 331806
Currently LLVM CFI tries to use an implicit blacklist file, currently
in /usr/lib64/clang/<version>/share. If the file is not there, LLVM
happily continues, which causes CFI to add checks to files/functions
that are known to fail, generating binaries that fail. This CL causes
LLVM to die (I hope) if it can't find these implicit blacklist files.
Patch by Caroline Tice!
Differential Revision: https://reviews.llvm.org/D46403
llvm-svn: 331674
In order to disable PIC and to match GCC behaviour, -mno-abicalls
option is neccessary. When -fno-[pic/PIC] is used witout -mno-abicalls,
warning is reported. An error is reported when -fno-pic or -fno-PIC is
used in combination with -mabicalls.
In this commit, test case is added.
Depends on D44381.
Differential Revision: https://reviews.llvm.org/D44684
llvm-svn: 331640
In order to disable PIC and to match GCC behaviour, -mno-abicalls
option is neccessary. When -fno-[pic/PIC] is used witout -mno-abicalls,
warning is reported. An error is reported when -fno-pic or -fno-PIC is
used in combination with -mabicalls.
Depends on D44381.
Differential Revision: https://reviews.llvm.org/D44684
llvm-svn: 331636
This replicates 'cl.exe' behavior and allows for both preprocessor output and
dependency information to be extraced with a single compiler invocation.
This is especially useful for compiler caching with tools like Mozilla's sccache.
See: https://github.com/mozilla/sccache/issues/246
Patch By: fxb
Differential Revision: https://reviews.llvm.org/D46394
llvm-svn: 331533
This avoids warnings about unused linker parameters, just like
other flags are ignored if they're from config files.
Differential Revision: https://reviews.llvm.org/D46286
llvm-svn: 331504
Since we've been working on productizing the MachineOutliner in AArch64, it
makes sense to provide a more user-friendly way to enable it.
This allows users of AArch64 to enable the outliner using -foutline instead
of -mllvm -enable-machine-outliner. Other, less mature implementations (e.g,
x86-64) can still enable the pass using the -mllvm option.
Also add a test to make sure it works.
llvm-svn: 331370
As suggested in the post-commit thread for rL331056, we should match these
clang options with the established vocabulary of the corresponding sanitizer
option. Also, the use of 'strict' is well-known for these kinds of knobs,
and we can improve the descriptive text in the docs.
So this intends to match the logic of D46135 but only change the words.
Matching LLVM commit to match this spelling of the attribute to follow shortly.
Differential Revision: https://reviews.llvm.org/D46236
llvm-svn: 331209
As discussed in the post-commit thread for:
rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html )
We need a way to opt-out of a float-to-int-to-float cast optimization because too much
existing code relies on the platform-specific undefined result of those casts when the
float-to-int overflows.
The LLVM changes associated with adding this function attribute are here:
rL330947
rL330950
rL330951
Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that
catches this problem:
rL330958
Differential Revision: https://reviews.llvm.org/D46135
llvm-svn: 331041
Implementation of `InputArgList` assumes its field `ArgStrings` contains
strings for each argument exactly in the same order. This condition was
broken when arguments from config file and from invocation were merged.
This change fixes https://bugs.llvm.org/show_bug.cgi?id=37196 (Clang
config files can crash argument handling).
llvm-svn: 330926
Supporting additional rules for parsing ISA string.
- RISC-V ISA strings must be lowercase.
E.g.: rv32IMC is not supported, rv32imc is correct.
- Multi-letter extensions are to be separated by a single
underscore '_'. The extension prefix counts as a letter.
This means extensions that start with 's', 'sx' and 'sx'
are all multi-letter.
E.g.:
xasb is a single non-standard extension named 'xasb'
xa_sb are two extensions, the non-standard user level extension
'xa', and the supervisor level extension 'sb'.
- Standard user-level extensions are specified following
a canonical order, according to Table 22.1 in
RISC-V User-Level ISA V2.2.
- Non-standard user-level 'x' extensions,
standard supervisor-level 's' extensions and
non-standard supervisor-level 'sx' extensions
are also specified following a canonical order according
to Table 22.1 in RISC-V User-Level ISA V2.2:
'x' extensions, follwed by 's' extensions and then 'sx' extensions.
- Extensions might have a version number.
Underscores may be used to separate ISA subset components to
improve readability and to provide disambiguation.
E.g.: rv32i2_m3_a1_f2_d2
- Version numbers are divided into major and minor numbers,
separated by a 'p'. If the minor version is 0, then 'p0' can
be omitted.
- Additional checks for dependent extensions and invalid
extensions combinations.
E.g.:
'e' requires rv32
'e' can't be combined with 'f' nor 'd'
'q' requires rv64
- TODO items have also been marked with comments in the code.
Reviewers: asb, kito-cheng
Reviewed By: asb
Subscribers: edward-jones, mgrang, zzheng, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, shiva0217, cfe-commits
Differential Revision: https://reviews.llvm.org/D45284
llvm-svn: 330880
Fixed directory separators in tests to be compatible with both
Windows and !Windows.
This reverts commit aa423850afa4c16a53c4c492fe254dcad3d5a53e.
llvm-svn: 330873
If -no-canonical-prefixes isn't used, the clang executable name used
is the one of the actual executable, not the name of the symlink that
the user invoked.
In these cases, the target prefix was overridden based on the clang
executable name. (On the other hand the implicit -target option
that such a symlink adds, is added as an actual command line parameter
in tools/driver/driver.cop, before resolving the symlink and finding
the actual clang executable.
Use the original ClangNameParts (set from argv[0] in
tools/driver/driver.cpp) if it seems to be initialized propery.
All existing tests of this feature used -no-canonical-prefixes
(possibly because it also makes the driver look in the directory
of the symlink instead of the directory of the executable); add
another one that uses --config-user-dir= to specify the directory
instead. (For actual users of such symlinks, outisde of the test
suite, the directory is probably the same for both.)
This makes this feature work more like what the documentation
describes.
Differential Revision: https://reviews.llvm.org/D45964
llvm-svn: 330871
Previously it would only accept a string as a GCC version if it had
either two components and no suffix, or three components with an
optional suffix.
Debian and ubuntu provided mingw compilers have lib/gcc/target entries
like "5.3-posix" and "5.3-win32". This doesn't try to make any specific
preference between them (other than lexical sorting of the suffix).
Differential Revision: https://reviews.llvm.org/D45505
llvm-svn: 330696
This patch updates AddGoldPlugin to pass stats-file to the Gold plugin,
if -save-stats is passed. It also moves the save-stats option handling
to a helper function tools::getStatsFileName.
Reviewers: tejohnson, mehdi_amini, compnerd
Reviewed By: tejohnson, compnerd
Differential Revision: https://reviews.llvm.org/D45771
llvm-svn: 330422
This implements support for the previously ignored flag
`-falign-functions`. This allows the frontend to request alignment on
function definitions in the translation unit where they are not
explicitly requested in code. This is compatible with the GCC behaviour
and the ICC behaviour.
The scalar value passed to `-falign-functions` aligns functions to a
power-of-two boundary. If flag is used, the functions are aligned to
16-byte boundaries. If the scalar is specified, it must be an integer
less than or equal to 4096. If the value is not a power-of-two, the
driver will round it up to the nearest power of two.
llvm-svn: 330378
After r300027 implicit builds might fail when updating the SDK on
darwin. Make validation of system headers default when implicit modules
is on and allow modules to be rebuild when system headers change.
rdar://problem/19767523
llvm-svn: 330240
Summary:
Android sysroots contain libraries for each OS version, as well as a
handful of unversioned libraries in the typical multiarch directory.
Reviewers: srhines, eugenis, george.burgess.iv
Reviewed By: eugenis
Subscribers: javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D45290
llvm-svn: 330213
register destructor functions annotated with __attribute__((destructor))
using __cxa_atexit or atexit.
Register destructor functions annotated with __attribute__((destructor))
calling __cxa_atexit in a synthesized constructor function instead of
emitting references to the functions in a special section.
The primary reason for adding this option is that we are planning to
deprecate the __mod_term_funcs section on Darwin in the future. This
feature is enabled by default only on Darwin. Users who do not want this
can use command line option 'fno_register_global_dtors_with_atexit' to
disable it.
rdar://problem/33887655
Differential Revision: https://reviews.llvm.org/D45578
llvm-svn: 330199
Summary:
The clang driver option -save-temps was not passed to the LTO config,
so when invoking the ThinLTO backends via clang during distributed
builds there was no way to get LTO to save temp files.
Getting this to work with ThinLTO distributed builds also required
changing the driver to avoid a separate compile step to emit unoptimized
bitcode when the input was already bitcode under -save-temps. Not only is
this unnecessary in general, it is problematic for ThinLTO backends since
the temporary bitcode file to the backend would not match the module path
in the combined index, leading to incorrect ThinLTO backend index-based
optimizations.
Reviewers: pcc
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D45217
llvm-svn: 330194
MIPS does not use PIC level 2 for historical reasons,
even with -fPIC/-mxgot/multigot options. This patch
prevents PIC to be set to level 2 for MIPS.
Differential Revision: https://reviews.llvm.org/D44381
llvm-svn: 330118
When profiling is enabled and -exported_symbols_list is specified for
the Darwin linker, export the requisite set of profiling symbols.
rdar://39427167
llvm-svn: 330077
Summary:
This allows us to do the following:
clang -fxray-modes=none ... -fxray-modes=xray-basic
It's important to be able to do this in cases where we'd like to
specialise the configuration for the invocation of the compiler, in
various scripting environments.
This is related to llvm.org/PR37066, a follow-up to D45474.
Reviewers: eizan, kpw, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D45610
llvm-svn: 329989
It means the same thing as -mllvm; there isn't any reason to have two
options which do the same thing.
Differential Revision: https://reviews.llvm.org/D45109
llvm-svn: 329965
This makes it consistent with libstdc++ and the other default
include directories.
If these headers are found in both locations and one isn't a
symlink to the other, this will cause errors due to libc++ headers
having wrapper headers for some standard C headers, wrappers that
do #include_next the actual one.
If the same libc++ standard C wrapper header exists in more than one
include directory before the real system one, the header include
guard will stop it from doing another #include_next to pick up the
real one, breaking things.
As this is a rather uncommon situation, this should be acceptable
and toolchain maintainers can adapt accordingly if necessary.
Also simplify some of the existing code with a local variable.
Differential Revision: https://reviews.llvm.org/D45500
llvm-svn: 329946
Summary: The logic was broken for Linux triples as it returns true in the switch for Triple.isOSLinux().
Reviewers: asb, apazos
Reviewed By: asb
Subscribers: kito-cheng, shiva0217, cfe-commits
Differential Revision: https://reviews.llvm.org/D45237
llvm-svn: 329941
The WBNOINVD instruction writes back all modified
cache lines in the processor’s internal cache to main memory
but does not invalidate (flush) the internal caches.
Reviewers: craig.topper, zvi, ashlykov
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D43817
llvm-svn: 329848
Summary:
This patch implements the `-fxray-modes=` flag which allows users
building with XRay instrumentation to decide which modes to pre-package
into the binary being linked. The default is the status quo, which will
link all the available modes.
For this to work we're also breaking apart the mode implementations
(xray-fdr and xray-basic) from the main xray runtime. This gives more
granular control of which modes are pre-packaged, and picked from
clang's invocation.
This fixes llvm.org/PR37066.
Note that in the future, we may change the default for clang to only
contain the profiling implementation under development in D44620, when
that implementation is ready.
Reviewers: echristo, eizan, chandlerc
Reviewed By: echristo
Subscribers: mgorny, mgrang, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D45474
llvm-svn: 329772
Currently we always include PTX into the fatbin along
with the GPU code.It about doubles the size of the GPU binary
we need to carry in the executable. These options allow control
inclusion of PTX into GPU binary.
This patch does not change the defaults, though we may consider
making no-PTX the default in the future.
Differential Revision: https://reviews.llvm.org/D45495
llvm-svn: 329737
Summary:
1. Find GCC's LDPATH from the actual GCC config file.
2. Avoid picking libraries from a similar named tuple if the exact
tuple is installed.
Reviewers: mgorny, chandlerc, thakis, rnk
Reviewed By: mgorny, rnk
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D45233
llvm-svn: 329512
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
This is a follow-up to D45354, which we should have only been running on
Linux and FreeBSD for specific targets.
Differential Revision: https://reviews.llvm.org/D45354
llvm-svn: 329378
Summary:
This change introduces `-fxray-link-deps` and `-fnoxray-link-deps`. The
`-fnoxray-link-deps` allows for directly controlling which specific XRay
runtime to link. The default is for clang to link the XRay runtime that
is shipped with the compiler (if there are any), but users may want to
explicitly add the XRay dependencies from other locations or other
means.
Reviewers: eizan, echristo, chandlerc
Reviewed By: eizan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D45354
llvm-svn: 329376
Summary:
"-fmerge-all-constants" is a non-conforming optimization and should not
be the default. It is also causing miscompiles when building Linux
Kernel (https://lkml.org/lkml/2018/3/20/872).
Fixes PR18538.
Reviewers: rjmccall, rsmith, chandlerc
Reviewed By: rsmith, chandlerc
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D45289
llvm-svn: 329300
Memory sanitizer compatibility are already done in
MemorySanitizer::doInitialization. It verifies whether the necessary offsets
exist and bails out if not. For this reason it is no good to duplicate two
checks in two projects. This patch removes clang check and postpones msan
compatibility validation till MemorySanitizer::doInitialization.
Another reason for this patch is to allow using msan with any CPU (given
compatible runtime) and custom mapping provided via the arguments added by
https://reviews.llvm.org/D44926.
Patch by vit9696.
Differential Revision: https://reviews.llvm.org/D44927
llvm-svn: 329241
The implementation of shadow call stack on aarch64 is quite different to
the implementation on x86_64. Instead of reserving a segment register for
the shadow call stack, we reserve the platform register, x18. Any function
that spills lr to sp also spills it to the shadow call stack, a pointer to
which is stored in x18.
Differential Revision: https://reviews.llvm.org/D45239
llvm-svn: 329236
Summary:
Most Android headers live in a single directory, but a small handful
live in multiarch directories.
Reviewers: srhines
Reviewed By: srhines
Subscribers: javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D44995
llvm-svn: 329234
The test additions in r329110 are Darwin-specific, as they rely
on a code path that is reachabled when driver is invoked without
-target. Instead of making the old test checks Darwin-specific too,
let's simply split it into two files to ensure that the old
checks are still platform-agnostic. Thanks Chandler for
suggesting this!
llvm-svn: 329141
Summary:
Add support for the -fsanitize=shadow-call-stack flag which causes clang
to add ShadowCallStack attribute to functions compiled with that flag
enabled.
Reviewers: pcc, kcc
Reviewed By: pcc, kcc
Subscribers: cryptoad, cfe-commits, kcc
Differential Revision: https://reviews.llvm.org/D44801
llvm-svn: 329122
D30700 added the -f[no-]rtlib-add-rpath flag, but that flag was never
wired up in the driver and tests were updated to check whether it
actually does anything. This patch wires up the flag and updates test.
Differential Revision: https://reviews.llvm.org/D45145
llvm-svn: 329032
Summary: Fixing clang-test on FreeBSD as a follow-up of https://reviews.llvm.org/D43378 to handle the revert happened in r325749.
Reviewers: devnexen, krytarowski, dberris
Subscribers: emaste, dberris, cfe-commits
Differential Revision: https://reviews.llvm.org/D45002
llvm-svn: 328797
Summary:
This patch doing more check and verify the -march= string and will issue
an error if it's a invalid combination.
Reviewers: asb, apazos
Differential Revision: https://reviews.llvm.org/D44189
Patch by Kito Cheng.
llvm-svn: 328690
Summary: Porting HWASan to Linux x86-64, the third of the three patches, clang part.
Reviewers: eugenis
Subscribers: cryptoad, cfe-commits
Differential Revision: https://reviews.llvm.org/D44745
llvm-svn: 328361
This fixes host-side LTO during CUDA compilation. Before, LTO
pipeline construction was clashing with CUDA pipeline construction.
At the moment there's no point doing LTO on device side as each
device-side TU is a complete program. We will need to figure out
compilation pipeline construction for the device-side LTO when we
have working support for multi-TU device-side CUDA compilation.
Differential Revision: https://reviews.llvm.org/D44691
llvm-svn: 328161
This is needed to avoid the test failure in case when compiler-rt
is set as the default runtime library for Clang.
Differential Revision: https://reviews.llvm.org/D44655
llvm-svn: 327932
Summary: This patch adds an additional flag to the OpenMP device offloading toolchain to link in the runtime library bitcode.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, grokos, hfinkel
Reviewed By: ABataev, grokos
Subscribers: jholewinski, guansong, cfe-commits
Differential Revision: https://reviews.llvm.org/D43197
llvm-svn: 327460
Summary: This patch adds an additional flag to the OpenMP device offloading toolchain to link in the runtime library bitcode.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, grokos, hfinkel
Reviewed By: ABataev, grokos
Subscribers: jholewinski, guansong, cfe-commits
Differential Revision: https://reviews.llvm.org/D43197
llvm-svn: 327438
Summary:
Android, in particular, got PIE enabled by default in r316606. It resulted in
relocatable links passing both -r and -pie to the linker, which is not allowed.
Reviewers: srhines
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D44229
llvm-svn: 327165
Previously, we passed "#" to --autocomplete to indicate to enable cc1
flags. For example, when -cc1 or -Xclang was passed to bash, bash
executed `clang --autocomplete=#-<flag they want to complete>`.
However, this was not a good implementation because it depends -Xclang
and -cc1 parsing to shell. So I changed this to pass all flags shell
has, so that Clang can handle them internally.
I had to change many testcases because API spec changed quite a lot.
Reviewers: teemperor, v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39342
llvm-svn: 326684
This causes failures on buildbots:
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/Driver/fsanitize.c:18:29: error: expected string not found in input
// CHECK-UNDEFINED-OPENBSD: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){18}"}}
^
<stdin>:1:1: note: scanning from here
clang version 7.0.0 (trunk 326648)
^
This will be investigated.
llvm-svn: 326652
I discovered that '-i' is a command line option for the driver,
however it actually does not do anything and is not supported by any
other compiler. In fact, it is completely undocumented for Clang.
I found a couple of instances of people confusing it with one of
the variety of other command line options that control the driver.
Because of this, we should delete this option so that it is clear
that it isn't valid.
HOWEVER, I found that GCC DOES support -imultilib, which the -i
was hiding our lack of support for. We currently only use imultilib
for the purpose of forwarding to gfortran (in a specific test written
by chandlerc for this purpose).
imultilib is a rarely used (if ever?) feature that I could find no
references to on the internet, and in fact, my company's massive test
suite has zero references to it ever being used.
SO, this patch removes the -i option so that we will now give an error
on its usage (so that it won't be confused with -I), and replaces it with
-imultilib, which is now specified as a gfortran_group option.
Differential Revision: https://reviews.llvm.org/D44032
llvm-svn: 326623
This makes it easier to debug crashes and hangs in block functions since
users can easily find out where the block is called from. The option
doesn't disable tail-calls from non-escaping blocks since non-escaping
blocks are not as hard to debug as escaping blocks.
rdar://problem/35758207
Differential Revision: https://reviews.llvm.org/D43841
llvm-svn: 326530
Since LLVM r326341, default EmulatedTLS mode is decided in backend
according to target triple. Any front-end should pass -f[no]-emulated-tls
to backend and set up ExplicitEmulatedTLS only when the flags are used.
Differential Revision: https://reviews.llvm.org/D43965
llvm-svn: 326499
This is needed for building with the GNU driver (`clang++`) when
targeting Windows and using msvcprt. This flag is the equivalent of
`/GR-`.
llvm-svn: 326469
/X makes cl stop looking in %INCLUDE%. Implement this for clang-cl.
As it turns out, the return in ToolChains/MSVC.cpp, AddClangSystemIncludeArgs()
for -nostdlibinc is already in the right place (but -nostdlibinc isn't exposed
by clang-cl), so just alias /X to that.
https://reviews.llvm.org/D43888
llvm-svn: 326357
Binaries for multiple architectures are combined by fatbinary,
so the current code was effectively not needed.
Differential Revision: https://reviews.llvm.org/D43461
llvm-svn: 326342
- Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.)
- This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601)
- Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables
- Add HasFastFMA, HasFastFMAF to GPUInfo tables
- Add missing tests
llvm-svn: 326254
In these combinations, link a DLL as usual, but pass -Bstatic instead
of -Bdynamic to indicate prefering static libraries.
Differential Revision: https://reviews.llvm.org/D43811
llvm-svn: 326235
macOS home directory paths begin with /Users, and clang-cl interprets
the /U portion as a macro undefine rather than a path, causing test
failures on macOS. Use a -- to explicitly treat the input file as a path
and fix the test.
This effectively reverts r326168 and adds an alternative fix.
llvm-svn: 326171
clang used to require adding an ".exe" suffix when targeting ELF systems on Windows.
Differential Revision: https://reviews.llvm.org/D43621
llvm-svn: 326164
This allows reporting an error when user tries to use SafeStack with
incompatible sanitizers.
Differential Revision: https://reviews.llvm.org/D43606
llvm-svn: 326151
Update min deployment target in some tests so that they don't try
to link against libarclite and don't fail when it's not available.
rdar://problem/29253617
Reviewers: vsk, kubamracek
Reviewed By: vsk
Subscribers: jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43787
llvm-svn: 326145
This reverts commit e17911006548518634fad66bb8648bcad49a1d64.
This is failing on ASAN bots because asan expects column info,
and it's also failing on some linux bots for unknown reasons which
i need to investigate.
llvm-svn: 326116
Windows debuggers don't work properly when column info is emitted
with lines. We handled this by checking if the driver mode was
cl, but it's possible to cause the gcc driver to emit codeview as
well, and in that path we were emitting column info with codeview.
Differential Revision: https://reviews.llvm.org/D43700
llvm-svn: 326113
In DWARF v5 the Line Number Program Header is extensible, allowing values with
new content types. This vendor extension to DWARF v5 allows source text to be
embedded directly in the line tables of the debug line section.
Add new flag (-g[no-]embed-source) to Driver and CC1 which indicates
that source should be passed through to LLVM during CodeGen.
Differential Revision: https://reviews.llvm.org/D42766
llvm-svn: 326102
Summary:
If the flag -fforce-enable-int128 is passed, it will enable support for __int128_t and __uint128_t types.
This flag can then be used to build compiler-rt for RISCV32.
Reviewers: asb, kito-cheng, apazos, efriedma
Reviewed By: asb, efriedma
Subscribers: shiva0217, efriedma, jfb, dschuff, sdardis, sbc100, jgravelle-google, aheejin, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, cfe-commits
Differential Revision: https://reviews.llvm.org/D43105
llvm-svn: 326045
Summary:
OpenCL 2.0 specification defines '-cl-uniform-work-group-size' option,
which requires that the global work-size be a multiple of the work-group
size specified to clEnqueueNDRangeKernel and allows optimizations that
are made possible by this restriction.
The patch introduces the support of this option.
To keep information about whether an OpenCL kernel has uniform work
group size or not, clang generates 'uniform-work-group-size' function
attribute for every kernel:
- "uniform-work-group-size"="true" for OpenCL 1.2 and lower,
- "uniform-work-group-size"="true" for OpenCL 2.0 and higher if
'-cl-uniform-work-group-size' option was specified,
- "uniform-work-group-size"="false" for OpenCL 2.0 and higher if no
'-cl-uniform-work-group-size' options was specified.
If the function is not an OpenCL kernel, 'uniform-work-group-size'
attribute isn't generated.
Patch by: krisb
Reviewers: yaxunl, Anastasia, b-sumner
Reviewed By: yaxunl, Anastasia
Subscribers: nhaehnle, yaxunl, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D43570
llvm-svn: 325771
Summary:
- Using -lpthread instead, with -pthread the linkage does not work.
-Warning about the -fxray-instrument usage outside of the working cases.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka, dberris, emaste
Reviewed By: krytarowski, emaste
Subscribers: srhines, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D43378
llvm-svn: 325746
This patch provides mitigation for CVE-2017-5715, Spectre variant two,
which affects the P5600 and P6600. It provides the option
-mindirect-jump=hazard, which instructs the LLVM backend to replace
indirect branches with their hazard barrier variants.
This option is accepted when targeting MIPS revision two or later.
The migitation strategy suggested by MIPS for these processors is to
use two hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard
barrier variants of the 'jalr' and 'jr' instructions respectively.
These instructions impede the execution of instruction stream until
architecturally defined hazards (changes to the instruction stream,
privileged registers which may affect execution) are cleared. These
instructions in MIPS' designs are not speculated past.
These instructions are used with the option -mindirect-jump=hazard
when branching indirectly and for indirect function calls.
These instructions are defined by the MIPS32R2 ISA, so this mitigation
method is not compatible with processors which implement an earlier
revision of the MIPS ISA.
Implementation note: I've opted to provide this as an
-mindirect-jump={hazard,...} style option in case alternative
mitigation methods are required for other implementations of the MIPS
ISA in future, e.g. retpoline style solutions.
Reviewers: atanasyan
Differential Revision: https://reviews.llvm.org/D43487
llvm-svn: 325651
Ideally, we'd only use the ubsan blacklist for ubsan sanitizers, and only use
the other-sanitizer blacklist for its sanitizers, but this at least enables the
intended suppressions.
llvm-svn: 325640
To be compatible with GCC if soft floating point is in effect any FPU
specified is effectively ignored, eg,
-mfloat-abi=soft -fpu=neon
If any floating point features which require FPU hardware are enabled
they must be disable.
There was some support for doing this for NEON, but it did not handle
VFP, nor did it prevent the backend from emitting the build attribute
Tag_FP_arch describing the generated code as using the floating point
hardware if a FPU was specified (even though soft float does not use
the FPU).
Disabling the hardware floating point features for targets which are
compiling for soft float has meant that some tests which were incorrectly
checking for hardware support also needed to be updated. In such cases,
where appropriate the tests have been updated to check compiling for
soft float and a non-soft float variant (usually softfp). This was
usually because the target specified in the test defaulted to soft float.
Differential Revision: https://reviews.llvm.org/D42569
llvm-svn: 325492
Petr Hosek