This clang-cl driver change removes the PCH options when we are only generating
preprocessed output. This is similar to the behavior of Y-.
Patch by: mikerice
Differential Revision: https://reviews.llvm.org/D50640
llvm-svn: 340025
- Add a command line options -msign-return-address to enable return address
signing
- Armv8.3a added instructions to sign the return address to help mitigate
against ROP attacks
- This patch adds command line options to generate function attributes that
signal to the back whether return address signing instructions should be
added
Differential revision: https://reviews.llvm.org/D49793
llvm-svn: 340019
"-fno-use-cxa-atexit" was a default provided by the initial
commit offering hexagon support. This is no longer required.
Reviewers: bcahoon, sidneym
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50816
llvm-svn: 339979
In r339807, I broke linking the builtins libraries for simulator targets, which itself was bad, but turns out it was all completely untested and marked with FIXME in the test suite.
This fixes all the test cases so they actually work, and fixes the bug I introduced in r339807.
llvm-svn: 339829
Summary:
In r335809, Petr Hosek lays out support for what he calls the multiarch
runtimes layout. This new way of laying out the directories for runtime
libraries is workable for all platforms. Petr did some of the common
infrastructure and made it work for Linux and Fuscia. This patch is a
cleanup to the Darwin and MachO drivers to serve as a step toward
supporting it in Darwin.
This patch does primarily two things:
(1) Changes the APIs for how the Darwin driver refers to compiler-rt
libraries to use the component names, similar to how Linux and Fuscia do
(2) Removes some legacy functionality for supporting macOS versions
before 10.6. This functionality is effectively dead code because in
r339277, the support was removed from compiler-rt for generating the 10.4
runtime support library, and Xcode 10 (currently in beta) removes
libgcc_s.10.4 and libgcc_s.10.5 from the macOS SDK.
With this patch landed a subsequent patch can modify
MachO::AddLinkRuntimeLib to support the multiarch runtimes layout.
Worth noting: None of the removed functionality was actually covered in
the test suite. So no test case updates are required.
Reviewers: phosek, bruno, arphaman
Reviewed By: phosek, arphaman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50618
llvm-svn: 339807
Summary:
Darwin support does not appear to be used as evidenced by the fact that
the runtime has never supported non-trivial programs.
Reviewers: pcc, kubamracek
Reviewed By: pcc
Subscribers: cfe-commits, kcc
Differential Revision: https://reviews.llvm.org/D50724
llvm-svn: 339720
Summary:
Introduces funclet-based unwinding for Objective-C and fixes an issue
where global blocks can't have their isa pointers initialised on
Windows.
After discussion with Dustin, this changes the name mangling of
Objective-C types to prevent a C++ catch statement of type struct X*
from catching an Objective-C object of type X*.
Reviewers: rjmccall, DHowett-MSFT
Reviewed By: rjmccall, DHowett-MSFT
Subscribers: mgrang, mstorsjo, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D50144
llvm-svn: 339428
This extension emits the guard cf table without inserting the
instrumentation. Currently that's what clang-cl does with /guard:cf
anyway, but this allows a user to request that explicitly.
Differential Revision: https://reviews.llvm.org/D50513
llvm-svn: 339420
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
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 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
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
This ports the profiling runtime on Fuchsia and enables the
instrumentation. Unlike on other platforms, Fuchsia doesn't use
files to dump the instrumentation data since on Fuchsia, filesystem
may not be accessible to the instrumented process. We instead use
the data sink to pass the profiling data to the system the same
sanitizer runtimes do.
Differential Revision: https://reviews.llvm.org/D47208
llvm-svn: 337881
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
This reverts commit r336467: libatomic is not available on all Linux
systems and this commit completely breaks OpenMP on them, even if there
are no atomic operations or all of them can be lowered to hardware
instructions.
See http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180716/234816.html
for post-commit discussion.
llvm-svn: 337722
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
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
Wmsvc-not-found was added in r297851 to help diagnose why link.exe can't be
executed. However, it's emitted even when using -fuse-ld=lld, and in cross
builds there's no way to get rid of the warning other than disabling it.
Instead, emit it when we look up link.exe and it ends up not being executable.
That way, when passing -fuse-ld=lld it will never be printed.
It will also not be printed if we find link.exe on PATH.
(We might want to eventually default to lld one day, at least when running on a
non-Win host, but that's for another day.)
Fixes PR38016.
llvm-svn: 337290
Summary: Add a flag `-fno-digraphs` to disable digraphs in the lexer, similar to `-fno-operator-names` which disables alternative names for C++ operators.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D48266
llvm-svn: 337232
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
This happened during a recent refactor. toStringRefArray() returns
a vector<StringRef>, which was being implicitly converted to an
ArrayRef<StringRef>, and then the vector was immediately being
destroyed, so the ArrayRef<> was losing its backing storage.
Fix this by making sure the vector gets permanent storage.
llvm-svn: 336219
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
Erich Keane