Commit Graph

234 Commits

Author SHA1 Message Date
Dan Albert 2715b28716 [Driver] Default Android toolchains to noexecstack.
Android does not support executable stacks.

Reviewers: srhines, pirama

Reviewed By: pirama

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D53343

llvm-svn: 357197
2019-03-28 18:08:28 +00:00
Sterling Augustine 6271606969 Add --unwindlib=[libgcc|compiler-rt] to parallel --rtlib= [take 2]
"clang++ hello.cc --rtlib=compiler-rt"

now can works without specifying additional unwind or exception
handling libraries.

This reworked version of the feature no longer modifies today's default
unwind library for compiler-rt: which is nothing. Rather, a user
can specify -DCLANG_DEFAULT_UNWINDLIB=libunwind when configuring
the compiler.

This should address the issues from the previous version.

Update tests for new --unwindlib semantics.

Differential Revision: https://reviews.llvm.org/D59109

llvm-svn: 356508
2019-03-19 20:01:59 +00:00
Petr Hosek 930d46a2ef [Driver] Support object files in addition to static and shared libraries in compiler-rt
This change introduces support for object files in addition to static
and shared libraries which were already supported which requires
changing the type of the argument from boolean to an enum.

Differential Revision: https://reviews.llvm.org/D56044

llvm-svn: 355891
2019-03-12 02:12:48 +00:00
Matthew Voss 1262e52e16 Revert "[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/"
This broke the windows bots.

This reverts commit 28302c66d2.

llvm-svn: 355725
2019-03-08 20:33:55 +00:00
Petr Hosek 28302c66d2 [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory.  Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/<target> and include/ directories, leaving resource directory only
for compiler-rt runtimes and Clang builtin headers.

Differential Revision: https://reviews.llvm.org/D59013

llvm-svn: 355665
2019-03-08 05:35:22 +00:00
Manman Ren 394d4ccf69 Order File Instrumentation: add clang support for -forder-file-instrumentation
When -forder-file-instrumentation is on, we pass llvm flag to enable the order file instrumentation pass.

https://reviews.llvm.org/D58751

llvm-svn: 355333
2019-03-04 20:30:30 +00:00
Rong Xu a4a09b2398 [PGO] Clang part of change for context-sensitive PGO (part1)
Part 1 of CSPGO change in Clang. This includes changes in clang options
and calls to llvm PassManager. Tests will be committed in part2.
This change needs the PassManager change in llvm.

Differential Revision: https://reviews.llvm.org/D54176

llvm-svn: 355331
2019-03-04 20:21:31 +00:00
Pierre Gousseau ae5303d010 [Driver] Allow enum SanitizerOrdinal to represent more than 64 different sanitizer checks, NFC.
enum SanitizerOrdinal has reached maximum capacity, this change extends the capacity to 128 sanitizer checks.
This can eventually allow us to add gcc 8's options "-fsanitize=pointer-substract" and "-fsanitize=pointer-compare".

This is a recommit of r354873 but with a fix for unqualified lookup error in lldb cmake build bot.

Fixes: https://llvm.org/PR39425

Differential Revision: https://reviews.llvm.org/D57914

llvm-svn: 355190
2019-03-01 10:05:15 +00:00
Pierre Gousseau 40ad3d2aa4 revert r354873 as this breaks lldb builds.
llvm-svn: 354875
2019-02-26 13:50:29 +00:00
Pierre Gousseau 44fad947a5 [Driver] Allow enum SanitizerOrdinal to represent more than 64 different sanitizer checks, NFC.
enum SanitizerOrdinal has reached maximum capacity, this change extends the capacity to 128 sanitizer checks.
This can eventually allow us to add gcc 8's options "-fsanitize=pointer-substract" and "-fsanitize=pointer-compare".

Fixes: https://llvm.org/PR39425

Differential Revision: https://reviews.llvm.org/D57914

llvm-svn: 354873
2019-02-26 13:30:14 +00:00
Sterling Augustine 5be3dbdb08 Rollback unwindlib patch.
llvm-svn: 352524
2019-01-29 18:27:51 +00:00
Sterling Augustine 9490fcc191 Add --unwindlib=[libgcc|compiler-rt] to parallel --rtlib=
Summary:
"clang++ hello.cc --rtlib=compiler-rt"

now works without specifying additional unwind or exception
handling libraries.

Reviewers: rsmith

Subscribers: srhines, dberris, aheejin, llvm-commits

Differential Revision: https://reviews.llvm.org/D57128

llvm-svn: 352404
2019-01-28 18:56:43 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Raphael Isemann b23ccecbb0 Misc typos fixes in ./lib folder
Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned`

Reviewers: teemperor

Reviewed By: teemperor

Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits

Differential Revision: https://reviews.llvm.org/D55475

llvm-svn: 348755
2018-12-10 12:37:46 +00:00
Vedant Kumar 6b062cd694 [gcov/Darwin] Ensure external symbols are exported when using an export list
Make sure that symbols needed to implement runtime support for gcov are
exported when using an export list on Darwin.

Without the clang driver exporting these symbols, the linker hides them,
resulting in tapi verification failures.

rdar://45944768

Differential Revision: https://reviews.llvm.org/D55151

llvm-svn: 348187
2018-12-03 20:53:58 +00:00
Martin Storsjo b547ef2a29 Revert "Reapply: [Driver] Use forward slashes in most linker arguments"
This reverts commit r345370, as it uncovered even more issues in
tests with partial/inconsistent path normalization:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/13562
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/886
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20994

In particular, these tests seem to have failed:
    Clang :: CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll
    Clang :: CodeGen/thinlto-multi-module.ll
    Clang :: Driver/cuda-external-tools.cu
    Clang :: Driver/cuda-options.cu
    Clang :: Driver/hip-toolchain-no-rdc.hip
    Clang :: Driver/hip-toolchain-rdc.hip
    Clang :: Driver/openmp-offload-gpu.c

At least the Driver tests could potentially be fixed by extending
the path normalization to even more places, but the issues with the
CodeGen tests are still unknown.

In addition, a number of other tests seem to have been broken in
other clang dependent tools such as clang-tidy and clangd.

llvm-svn: 345372
2018-10-26 08:33:29 +00:00
Martin Storsjo cbd73574e4 Reapply: [Driver] Use forward slashes in most linker arguments
libtool inspects the output of $CC -v to detect what object files and
libraries are linked in by default. When clang is built as a native
windows executable, all paths are formatted with backslashes, and
the backslashes cause each argument to be enclosed in quotes. The
backslashes and quotes break further processing within libtool (which
is implemented in shell script, running in e.g. msys) pretty badly.

Between unix style pathes (that only work in tools that are linked
to the msys runtime, essentially the same as cygwin) and proper windows
style paths (with backslashes, that can easily break shell scripts
and msys environments), the best compromise is to use windows style
paths (starting with e.g. c:) but with forward slashes, which both
msys based tools, shell scripts and native windows executables can
cope with. This incidentally turns out to be the form of paths that
GCC prints out when run with -v on windows as well.

This change potentially makes the output from clang -v a bit more
inconsistent, but it is isn't necessarily very consistent to begin with.

Compared to the previous attempt in SVN r345004, this now does
the same transformation on more paths, hopefully on the right set
of paths so that all tests pass (previously some tests failed, where
path fragments that were required to be identical turned out to
use different path separators in different places). This now also
is done only for non-windows, or cygwin/mingw targets, to preserve
all backslashes for MSVC cases (where the paths can end up e.g. embedded
into PDB files. (The transformation function itself,
llvm::sys::path::convert_to_slash only has an effect when run on windows.)

Differential Revision: https://reviews.llvm.org/D53066

llvm-svn: 345370
2018-10-26 07:01:59 +00:00
Martin Storsjo e133c7867e Revert "[Driver] Use forward slashes in most linker arguments"
This reverts commit r345004, as it broke tests when actually run
on windows; see e.g.
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/763.

This broke tests that had captured a variable containing a path
with backslashes, which failed to match cases in the output
where the path separators had been changed into forward slashes.

llvm-svn: 345005
2018-10-23 07:01:55 +00:00
Martin Storsjo 965a361f57 [Driver] Use forward slashes in most linker arguments
libtool inspects the output of $CC -v to detect what object files and
libraries are linked in by default. When clang is built as a native
windows executable, all paths are formatted with backslashes, and
the backslashes cause each argument to be enclosed in quotes. The
backslashes and quotes break further processing within libtool (which
is implemented in shell script, running in e.g. msys) pretty badly.

Between unix style pathes (that only work in tools that are linked
to the msys runtime, essentially the same as cygwin) and proper windows
style paths (with backslashes, that can easily break shell scripts
and msys environments), the best compromise is to use windows style
paths (starting with e.g. c:) but with forward slashes, which both
msys based tools, shell scripts and native windows executables can
cope with. This incidentally turns out to be the form of paths that
GCC prints out when run with -v on windows as well.

This change potentially makes the output from clang -v a bit more
inconsistent, but it is isn't necessarily very consistent to begin with.

Differential Revision: https://reviews.llvm.org/D53066

llvm-svn: 345004
2018-10-23 06:33:26 +00:00
Jonas Devlieghere fc51490baf Lift VFS from clang to llvm (NFC)
This patch moves the virtual file system form clang to llvm so it can be
used by more projects.

Concretely the patch:
 - Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support.
 - Moves the corresponding unit test from clang to llvm.
 - Moves the vfs namespace from clang::vfs to llvm::vfs.
 - Formats the lines affected by this change, mostly this is the result of
   the added llvm namespace.

RFC on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html

Differential revision: https://reviews.llvm.org/D52783

llvm-svn: 344140
2018-10-10 13:27:25 +00:00
Martin Storsjo f32a0fc80d [MinGW] Allow using ASan
Linking to ASan for MinGW is similar to MSVC, but MinGW always links
the MSVCRT dynamically, so there is only one of the MSVC cases to
consider.

When linking to a shared compiler runtime library on MinGW, the suffix
of the import library is .dll.a.

The existing case of .dll as suffix for windows in general doesn't
seem correct (since this is used for linking). As long as callers never
actually set the Shared flag, the default static suffix of .lib also
worked fine for import libraries as well.

Differential Revision: https://reviews.llvm.org/D52538

llvm-svn: 343537
2018-10-01 20:53:25 +00:00
Richard Smith cd35eff395 [modules] Driver support for precompiling a collection of files as a single
action.

llvm-svn: 342305
2018-09-15 01:21:16 +00:00
Petr Hosek 678c1c6ccc [Driver] Check normalized triples for multiarch runtime path
Previously we only used target triple as provided which matches the
GCC behavior, but it also means that all clients have to be consistent
in their spelling of target triples since e.g. x86_64-linux-gnu and
x86_64-unknown-linux-gnu will result in Clang driver looking at two
different paths when searching for runtime libraries.

Unfortunatelly, as it turned out many clients aren't consistent in
their spelling of target triples, e.g. many Linux distributions use
the shorter spelling but config.guess and rustc insist on using the
normalized variant which is causing issues. To avoid having to ship
multiple copies of runtimes for different triple spelling or rely on
symlinks which are not portable, we should also check the normalized
triple when constructing paths for multiarch runtimes.

Differential Revision: https://reviews.llvm.org/D50547

llvm-svn: 340471
2018-08-22 22:56:46 +00:00
Fangrui Song 6907ce2f8f Remove trailing space
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338291
2018-07-30 19:24:48 +00:00
Roman Lebedev b69ba22773 [clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang part
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
2018-07-30 18:58:30 +00:00
Petr Hosek 887f26d470 Support for multiarch runtimes layout
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
2018-06-28 03:11:52 +00:00
Pavel Labath d8c6290ba4 Move VersionTuple from clang/Basic to llvm/Support
Summary:
This kind of functionality is useful to other project apart from clang.
LLDB works with version numbers a lot, but it does not have a convenient
abstraction for this. Moving this class to a lower level library allows
it to be freely used within LLDB.

Since this class is used in a lot of places in clang, and it used to be
in the clang namespace, it seemed appropriate to add it to the list of
adopted classes in LLVM.h to avoid prefixing all uses with "llvm::".

Also, I didn't find any tests specific for this class, so I wrote a
couple of quick ones for the more interesting bits of functionality.

Reviewers: zturner, erik.pilkington

Subscribers: mgorny, cfe-commits, llvm-commits

Differential Revision: https://reviews.llvm.org/D47887

llvm-svn: 334399
2018-06-11 10:28:04 +00:00
Shoaib Meenai 09edbddee7 [Driver] Stop passing -fseh-exceptions for x86_64-windows-msvc
-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
2018-06-06 23:09:02 +00:00
Sunil Srivastava 2ada2499ea Do not enable RTTI with -fexceptions, for PS4
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
2018-05-18 23:32:01 +00:00
Adrian Prantl 9fc8faf9e6 Remove \brief commands from doxygen comments.
This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

Differential Revision: https://reviews.llvm.org/D46320

llvm-svn: 331834
2018-05-09 01:00:01 +00:00
Nico Weber 1865df4996 s/LLVM_ON_WIN32/_WIN32/, clang
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too.  Just use the
default macro instead of a reinvented one.

See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.

llvm-svn: 331069
2018-04-27 19:11:14 +00:00
Peter Collingbourne f11eb3ebe7 AArch64: Implement support for the shadowcallstack attribute.
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
2018-04-04 21:55:44 +00:00
Vlad Tsyrklevich e55aa03ad4 Add the -fsanitize=shadow-call-stack flag
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
2018-04-03 22:33:53 +00:00
Eugene Zelenko 5e4511cfc7 [Driver] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).
llvm-svn: 328044
2018-03-20 21:08:59 +00:00
Kamil Rytarowski 150a377704 Better OpenBSD frontend support
Summary:
- Like other *BSD, conditioning certain flags to pass
- To prepare future OpenBSD sanitisers.

Patch by: David CARLIER

Reviewers: dlj, krytarowski, vitalybuka

Reviewed By: vitalybuka

Subscribers: krytarowski, cfe-commits

Differential Revision: https://reviews.llvm.org/D43818

llvm-svn: 326645
2018-03-03 11:47:27 +00:00
Kamil Rytarowski 9b1996ec86 Handle the NetBSD case in ToolChain::getOSLibName()
Return a new CompilerRT Path on NetBSD: "netbsd", instead of
getOS(), which returns a string like "netbsd8.9.12".

Sponsored by <The NetBSD Foundation>

llvm-svn: 326219
2018-02-27 18:16:47 +00:00
Igor Kudrin a49182aa5a [Driver] Allow using a canonical form of '-fuse-ld=' when cross-compiling on Windows.
clang used to require adding an ".exe" suffix when targeting ELF systems on Windows.

Differential Revision: https://reviews.llvm.org/D43621

llvm-svn: 326164
2018-02-27 02:51:30 +00:00
Alex Shlyapnikov 85da0f6fb5 [Sanitizers] Basic Solaris sanitizer support (PR 33274)
Summary:
This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary
to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898,
https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900).

A few features of note:

* While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places
  the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to
  the OS part of the target triplet (solaris2.11 in the case at hand).  The patch makes
  them agree on compiler-rt's idea.

* While Solaris ld accepts a considerable number of GNU ld options for compatibility,
  it only does so for the double-dash forms.  clang unfortunately is inconsistent here
  and sometimes uses the double-dash form, sometimes the single-dash one that
  confuses the hell out of Solaris ld.  I've changed the affected places to use the double-dash
  form that should always work.

* As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the
  __start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm
  including additional runtime libs into the link that provide them.

* One test uses -fstack-protector, but unlike other systems libssp hasn't been folded
  into Solaris libc, but needs to be linked with separately.

* For now, only 32-bit x86 asan is enabled on Solaris.  64-bit x86 should follow, but
  sparc (which requires additional compiler-rt changes not yet submitted) fails miserably
  due to a llvmsparc backend limitation:

fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.

  However, inside the gcc tree, Solaris/sparc asan works almost as well as x86.

Reviewers: rsmith, alekseyshl

Reviewed By: alekseyshl

Subscribers: jyknight, fedor.sergeev, cfe-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D40903

llvm-svn: 324296
2018-02-05 23:59:13 +00:00
Alex Lorenz 6cdef0efb7 [driver] Set the 'simulator' environment for Darwin when compiling for
iOS/tvOS/watchOS simulator

rdar://35135215

Differential Revision: https://reviews.llvm.org/D40682

llvm-svn: 320073
2017-12-07 19:04:10 +00:00
Martell Malone c950c651a4 Toolchain: Normalize dwarf, sjlj and seh eh
This is a re-apply of r319294.

adds -fseh-exceptions and -fdwarf-exceptions flags

clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1

-fno-exceptions has a higher priority then specifying the model

move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag

move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check

remove unused USESEHExceptions from the MinGW Driver

fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models

Reviewers: rnk, mstorsjo

Differential Revision: https://reviews.llvm.org/D39673

llvm-svn: 319297
2017-11-29 07:25:12 +00:00
Martell Malone 2fa25706ed Revert "Toolchain: Normalize dwarf, sjlj and seh eh"
This reverts rL319294.
The windows sanitizer does not like seh on x86.
Will re apply with None type for x86

llvm-svn: 319295
2017-11-29 06:51:27 +00:00
Martell Malone 390cfcb0b1 Toolchain: Normalize dwarf, sjlj and seh eh
adds -fseh-exceptions and -fdwarf-exceptions flags

clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1

clang cc1 assumes dwarf is the default if none is passed
and -fno-exceptions has a higher priority then specifying the model

move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag

move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check

remove unused USESEHExceptions from the MinGW Driver

fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models

Reviewers: rnk, mstorsjo

Differential Revision: https://reviews.llvm.org/D39673

llvm-svn: 319294
2017-11-29 06:25:13 +00:00
Petr Hosek 5668d83e0e [Driver] Make the use of relax relocations a per target option
The support for relax relocations is dependent on the linker and
different toolchains within the same compiler can be using different
linkers some of which may or may not support relax relocations.

Give toolchains the option to control whether they want to use relax
relocations in addition to the existing (global) build system option.

Differential Revision: https://reviews.llvm.org/D39831

llvm-svn: 318816
2017-11-22 01:38:31 +00:00
Jonas Hahnfeld 7c78cc5273 [OpenMP] Consistently use cubin extension for nvlink
This was previously done in some places, but for example not for
bundling so that single object compilation with -c failed. In
addition cubin was used for all file types during unbundling which
is incorrect for assembly files that are passed to ptxas.
Tighten up the tests so that we can't regress in that area.

Differential Revision: https://reviews.llvm.org/D40250

llvm-svn: 318763
2017-11-21 14:44:45 +00:00
Peter Smith 3947cb3cf0 [ARM] For assembler files recognize -Xassembler or -Wa, -mthumb
The Unified Arm Assembler Language is designed so that the majority of
assembler files can be assembled for both Arm and Thumb with the choice
made as a compilation option.

The way this is done in gcc is to pass -mthumb to the assembler with either
-Wa,-mthumb or -Xassembler -mthumb. This change adds support for these
options to clang. There is no assembler equivalent of -mno-thumb, -marm or
-mno-arm so we don't need to recognize these.

Ideally we would do all of the processing in
CollectArgsForIntegratedAssembler(). Unfortunately we need to change the
triple and at that point it is too late. Instead we look for the option
earlier in ComputeLLVMTriple().
    
Fixes PR34519
    
Differential Revision: https://reviews.llvm.org/D40127

llvm-svn: 318647
2017-11-20 13:43:55 +00:00
Sam Clegg 471d7afdf0 [WebAssembly] Add crt1.o with calling lld
Also, for OS unknown targets like wasm, don't include
'unknown' in the library path. This is a fix for rL316719.

Differential Revision: https://reviews.llvm.org/D39354

llvm-svn: 316777
2017-10-27 18:10:19 +00:00
Sam Clegg a08631ec6c [WebAssembly] Include libclang_rt.builtins in the standard way
Differential Revision: https://reviews.llvm.org/D39218

llvm-svn: 316719
2017-10-27 00:26:07 +00:00
Martell Malone e5639e9dd9 Driver: use ld64.lld when -fuse-ld=lld for darwin
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
2017-10-15 17:53:45 +00:00
Jonas Hahnfeld bbf56fb621 [OpenMP] Fix passing of -m arguments correctly
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
2017-10-04 13:32:59 +00:00
Jonas Hahnfeld 757e61fa4f [OpenMP] Fix passing of -m arguments to device toolchain
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
2017-09-27 18:12:34 +00:00