The commit r310291 introduced the failure. r310332 was a test fix commit and
r310300 was a followup commit. I reverted these two to avoid merge conflicts
when reverting.
The 'openmp-offload.c' test is failing on Darwin because the following
run lines:
// RUN: touch %t1.o
// RUN: touch %t2.o
// RUN: %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -save-temps -no-canonical-prefixes %t1.o %t2.o 2>&1 \
// RUN: | FileCheck -check-prefix=CHK-TWOCUBIN %s
trigger the following assertion:
Driver.cpp:3418:
assert(CachedResults.find(ActionTC) != CachedResults.end() &&
"Result does not exist??");
llvm-svn: 310345
Summary: When device offloading is enabled and the device is an NVIDIA GPU, OpenMP target regions must be compiled with relocation enabled by passing the "-c" flag to the PTXAS invocation.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, Hahnfeld, jlebar, hfinkel, tstellar
Reviewed By: Hahnfeld
Subscribers: Hahnfeld, rengolin, mkuron, cfe-commits
Differential Revision: https://reviews.llvm.org/D29642
llvm-svn: 310300
Summary: When compiling code being offloaded by OpenMP to an NVIDIA GPU, pass the -v to PTXAS if it was passed to the CLANG driver.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar
Reviewed By: jlebar
Subscribers: Hahnfeld, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D29644
llvm-svn: 310295
Summary:
OpenMP has the ability to offload target regions to devices which may have different architectures.
A new -fopenmp-target-arch flag is introduced to specify the device architecture.
In this patch I use the new flag to specify the compute capability of the underlying NVIDIA architecture for the OpenMP offloading CUDA tool chain.
Only a host-offloading test is provided since full device offloading capability will only be available when [[ https://reviews.llvm.org/D29654 | D29654 ]] lands.
Reviewers: hfinkel, Hahnfeld, carlo.bertolli, caomhin, ABataev
Reviewed By: hfinkel
Subscribers: guansong, cfe-commits
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D34784
llvm-svn: 310263
Summary:
Verified to work and useful to run check-asan, as this target tests 32-bit and 64-bit execution.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, filcab, dim, vitalybuka
Reviewed By: vitalybuka
Subscribers: #sanitizers, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36378
llvm-svn: 310245
This is causing failures when compiling clang with -O3
as one of the structures used by clang is passed by
value and uses the fastcc calling convention.
Faliures manifest for stage2 mips build.
llvm-svn: 310057
Summary:
M-class profiles do not support ARM execution mode, so providing
-marm/-mno-thumb does not make sense in combination with -mcpu/-march
options that support the M-profile.
This is a follow-up patch to D35569 and it seemed pretty clear that we
should emit an error in the driver in this case.
We probably also should warn/error if the provided -mcpu/-march options
do not match, e.g. -mcpu=cortex-m0 -march=armv8-a is invalid, as
cortex-m0 does not support armv8-a. But that should be a separate patch
I think.
Reviewers: echristo, richard.barton.arm, rengolin, labrinea, charles.baylis
Reviewed By: rengolin
Subscribers: aemerson, javed.absar, kristof.beyls, cfe-commits
Differential Revision: https://reviews.llvm.org/D35826
llvm-svn: 310047
The .gnu_hash format is superior, and all versions of the Fuchsia
dynamic linker support it.
Differential Revision: https://reviews.llvm.org/D36254
llvm-svn: 310017
This commit fixes a bug where clang/llvm doesn't emit an unwind table
for a function when it is marked noexcept. Without this patch, the
following code terminates with an uncaught exception on ARM64:
int foo1() noexcept {
try {
throw 0;
} catch (int i) {
return 0;
}
return 1;
}
int main() {
return foo1();
}
rdar://problem/32411865
Differential Revision: https://reviews.llvm.org/D35693
llvm-svn: 310006
This option when combined with -mgpopt and -membedded-data places all
uninitialized constant variables in the read-only section.
Reviewers: atanasyan, nitesh.jain
Differential Revision: https://reviews.llvm.org/D35917
llvm-svn: 309940
Add support for the -membedded-data option which places constant data in
the .rodata section, rather than the .sdata section.
Reviewers: atanasyan, nitesh.jain
Differential Revision: https://reviews.llvm.org/D35914
llvm-svn: 309935
Summary:
This is to provide a default blacklist filename for UBSan.
While UBSan is turned on, it's better that clang pick up a blacklist file (when exists), just as what ASan / MSan does, so we do not end up adding the "-fsanitize-blacklist" option to every command line.
Reviewers: chandlerc, echristo, vsk, eugenis
Reviewed By: vsk, eugenis
Subscribers: vsk, eugenis, echristo, cfe-commits
Differential Revision: https://reviews.llvm.org/D35849
llvm-svn: 309873
In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I
did not see the need for the two checks to have separate null checking logic
for the same pointer. I expected the two checks to either always be enabled
together, or to be mutually compatible.
In the mailing list discussion re: r309007 it became clear that that isn't the
case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean,
it's useful to have -fsanitize=vptr emit its own null check. That's what this
patch does: with it, -fsanitize=vptr can be used without -fsanitize=null.
Differential Revision: https://reviews.llvm.org/D36112
llvm-svn: 309846
This just adds the CPU to a list of commands passed to GAS when not using the
integrated assembler.
Differential Revision: https://reviews.llvm.org/D33820
llvm-svn: 309256
Summary:
`clang --autocomplete=-std` will show
```
-std: Language standard to compile for
-std= Language standard to compile for
-stdlib= C++ standard library to use
```
after this change.
However, showing HelpText with completion in bash seems super tricky, so
this feature will be used in other shells (fish, zsh...).
Reviewers: v.g.vassilev, teemperor, ruiu
Subscribers: cfe-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35759
llvm-svn: 309113
The instrumentation generated by -fsanitize=vptr does not null check a
user pointer before loading from it. This causes crashes in the face of
UB member calls (this=nullptr), i.e it's causing user programs to crash
only after UBSan is turned on.
The fix is to make run-time null checking a prerequisite for enabling
-fsanitize=vptr, and to then teach UBSan to reuse these run-time null
checks to make -fsanitize=vptr safe.
Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build
Differential Revision: https://reviews.llvm.org/D35735https://bugs.llvm.org/show_bug.cgi?id=33881
llvm-svn: 309007
Projects that want to statically link their own C++ standard library currently
need to pass -nostdlib or -nodefaultlibs, which also disables linking of the
builtins library, -lm, and so on. Alternatively, they could use `clang` instead
of `clang++`, but that already disables implicit addition of -lm on some
toolchains.
Add a dedicated flag -nostdlib++ that disables just linking of libc++ /
libstdc++. This is analogous to -nostdinc++.
https://reviews.llvm.org/D35780
llvm-svn: 308997
Add support for -m(no-)extern-data when using -mgpopt in the driver. It is
enabled by default in the backend.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35550
llvm-svn: 308879
All but one place are checking options::OPT_nostdlib instead of looking at
this field, so convert that one other place to doing that as well.
No behavior change.
llvm-svn: 308848
The driver ignores -fsanitize-coverage=... flags when also given
-fsanitize=... flags for sanitizer flavors that don't support the
coverage runtime. This logic failed to account for subsequent
-fno-sanitize=... flags that disable the sanitizer flavors that
conflict with -fsanitize-coverage=... flags.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D35603
llvm-svn: 308707
This patch teaches the driver to pass -mgpopt by default to the backend when it
is supported, i.e. we are using -mno-abicalls.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35548
This version fixes a logic error that generated warnings incorrectly and
gets rid of spurious arguments to the backend when -mgpopt is not used.
llvm-svn: 308619
allocation functions.
This changes the error message Sema prints when an unavailable C++17
aligned allocation function is selected.
Original message: "... possibly unavailable on x86_64-apple-macos10.12"
New message: "... only available on macOS 10.13 or newer"
This is a follow-up to r306722.
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D35520
llvm-svn: 308496
This patch teaches the driver to pass -mgpopt by default to the backend when it
is supported, i.e. we are using -mno-abicalls.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35548
This version fixes a logic error that generated warnings incorrectly.
llvm-svn: 308458
This patch teaches the driver to pass -mgpopt by default to the backend when it
is supported, i.e. we are using -mno-abicalls.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35548
llvm-svn: 308431
platforms.
Set the target OS based on -target if it is present on the command
line and -arch is not.
With this commit, "-target x86_64-apple-ios8.0" does the same thing as
"-arch x86_64 -mios-version-min=8.0".
rdar://problem/21012522
llvm-svn: 307982
Several improvements to the Fuchsia driver:
* Search for C++ library headers and libraries in directories that
are part of the toolchain distribution rather than sysroot.
* Use LLVM support utlities to construct paths to make sure the driver
is also usable on Windows for cross-compiling.
* Change the driver to inherit directly from ToolChain rather than
Generic_GCC since we don't need any of the GCC related multilib logic.
Differential Revision: https://reviews.llvm.org/D35328
llvm-svn: 307856
Several improvements to the Fuchsia driver:
* Search for C++ library headers and libraries in directories that
are part of the toolchain distribution rather than sysroot.
* Use LLVM support utlities to construct paths to make sure the driver
is also usable on Windows for cross-compiling.
* Change the driver to inherit directly from ToolChain rather than
Generic_GCC since we don't need any of the GCC related multilib logic.
Differential Revision: https://reviews.llvm.org/D32613
llvm-svn: 307830
Summary:
We don't want to autocomplete flags whose Flags class has `NoDriverOption` when argv[1] is not `-cc1`.
Another idea for this implementation is to make --autocomplete a cc1
option and handle it in clang Frontend, by porting --autocomplete
handler from Driver to Frontend, so that we can handle Driver options
and CC1 options in unified manner.
Differential Revision: https://reviews.llvm.org/D34770
llvm-svn: 307479
deployment target if the SDK is newer than the system
This commit reverts the revert commit r305891. Now the change from r305678
should be correct because `llvm::sys::getProcessTriple` now returns the correct
macOS version of the system after the LLVM change r307372.
Original commit message:
This commit improves the driver by making sure that it picks the system version
for the deployment target when the version of the macOS SDK is newer than the
system version.
rdar://29449467
Differential Revision: https://reviews.llvm.org/D34175
llvm-svn: 307388
Check the `-mlong-calls` command line option and pass the `long-calls`
feature flag to the backend. Handling of this feature flag in the backend
needs to be implemented by a separate commit.
llvm-svn: 307386
Summary: Pass the type of the device offloading when building the tool chain for a particular target architecture. This is required when supporting multiple tool chains that target a single device type. In our particular use case, the OpenMP and CUDA tool chains will use the same ```addClangTargetOptions ``` method. This enables the reuse of common options and ensures control over options only supported by a particular tool chain.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar, Hahnfeld
Reviewed By: hfinkel
Subscribers: jgravelle-google, aheejin, rengolin, jfb, dschuff, sbc100, cfe-commits
Differential Revision: https://reviews.llvm.org/D29647
llvm-svn: 307272
Summary:
Enable LLVM asan sanitizer for NetBSD/amd64.
Don't generate -ldl for dlopen(3)-like functions on NetBSD.
These features are available in libc on NetBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, eugenis, kcc, dim
Reviewed By: dim
Subscribers: #clang, #sanitizers
Tags: #clang, #sanitizers
Differential Revision: https://reviews.llvm.org/D34960
llvm-svn: 307104
-fslp-vectorize-aggressive and -fno-slp-vectorize-aggressive flags back
under this group and test for the warning. Document the future removal
in the ReleaseNotes.
Differential Revision: https://reviews.llvm.org/D34926
llvm-svn: 306965
Summary:
Un-revert https://reviews.llvm.org/D34868, but with a slight tweak to the
documentation to fix an error -- I had used the wrong syntax for a link.
llvm-svn: 306948
Summary:
Depends on https://reviews.llvm.org/D34867.
Add a Clang frontend option to enable optimization remark hotness
thresholds, which were added to LLVM in https://reviews.llvm.org/D34867.
This prevents diagnostics that do not meet a minimum hotness
threshold from being output. When generating optimization remarks for large
codebases with a ton of cold code paths, this option can be used
to limit the optimization remark output at a reasonable size.
Discussion of this change can be read here:
http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html
Reviewers: anemet, davidxl, hfinkel
Reviewed By: anemet
Subscribers: fhahn, cfe-commits
Differential Revision: https://reviews.llvm.org/D34868
llvm-svn: 306945
the target is 32-bit.
The following changes are made to the driver since 32-bit apps do not
run on iOS 11 or later:
- If the deployment target is set explicitly, either with a command-line
option or an environment variable, the driver should report an error
if the version is greater than iOS 10.
- In the case where the deployment target is not set explicitly and the
default is inferred from the target triple or SDK version, it should
use a maximum default of iOS 10.99.99.
rdar://problem/32230613
Differential Revision: https://reviews.llvm.org/D34529
llvm-svn: 306922
This changes CrossWindows to look for -nostdinc instead of -nostdlibinc.
In addition, fixes a bug where -isystem-after options would be dropped
when called with -nostdinc.
Patch by Dave Lee!
llvm-svn: 306829
This is a more principled version of r303756. That change was both very
brittle about the state of the Diags object going into the driver and
also broke tooling in funny ways.
In particular it prevented tools from capturing diagnostics properly and
made the compilation database logic fail to provide arguments to the
tool, falling back to scanning directories for JSON files.
llvm-svn: 306822
basic block vectorizer. This vectorizer has had no known users for many,
many years and is completely surpassed by the normal
'-fvectorize-slp'-controlled SLP vectorizer in LLVM.
Hal proposed this back in 2014 to no objections:
http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html
While this patch completely removes the flag, Joerg is working on
a patch that will add it back in a way that warns users and ignores the
flag in a clear and well factored way (so that we can keep doing this
going forward).
Differential Revision: https://reviews.llvm.org/D34846
llvm-svn: 306786
a c++17 aligned allocation/deallocation function that is unavailable in
the standard library on Apple platforms.
The aligned functions are implemented only in the following versions or
later versions of the OSes, so clang issues diagnostics if the deployment
target being targeted is older than these:
macosx: 10.13
ios: 11.0
tvos: 11.0
watchos: 4.0
The diagnostics are issued whenever the aligned functions are selected
except when the selected function has a definition in the same file.
If there is a user-defined function available somewhere else, option
-Wno-aligned-allocation-unavailable can be used to silence the
diagnostics.
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D34574
llvm-svn: 306722
Summary: The preprocessing and code generation and optimization stages of the compiler are also passed the "-fopenmp-is-device" flag. This is used to trigger machine specific preprocessing and code generation when performing device offloading to an NVIDIA GPU via OpenMP directives.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, Hahnfeld, hfinkel, tstellar
Reviewed By: Hahnfeld
Subscribers: Hahnfeld, rengolin
Differential Revision: https://reviews.llvm.org/D29645
llvm-svn: 306691
Summary: Device offloading requires the specification of an additional flag containing the triple of the //other// architecture the code is being compiled on if such an architecture exists. If compiling for the host, the auxiliary triple flag will contain the triple describing the device and vice versa.
Reviewers: arpith-jacob, sfantao, caomhin, carlo.bertolli, ABataev, Hahnfeld, jlebar, hfinkel, tstellar
Reviewed By: Hahnfeld
Subscribers: rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D29339
llvm-svn: 306689
IAS is already used for MIPS64 in majority of Android projects.
Android MIPS64 uses N64 ABI. Set IAS as a default now.
Differential Revision: https://reviews.llvm.org/D34514
llvm-svn: 306280
Ananas is a home-brew operating system, mainly for amd64 machines. After
using GCC for quite some time, it has switched to clang and never looked
back - yet, having to manually patch things is annoying, so it'd be much
nicer if this was in the official tree.
More information:
https://github.com/zhmu/ananas/https://rink.nu/projects/ananas.html
Submitted by: Rink Springer
Differential Revision: https://reviews.llvm.org/D32936
llvm-svn: 306239
This check currently isn't able to diagnose any issues at -O0, not is it
likely to [1]. Disabling the check at -O0 leads to substantial compile
time and binary size savings.
[1] [cfe-dev] Disabling ubsan's object size check at -O0
Differential Revision: https://reviews.llvm.org/D34563
llvm-svn: 306181
Currently, autocompleted options are displayed in the same order as we
wrote them in .td files. This patch sort them out in clang so that they
are sorted alphabetically. This should improve usability.
Differential Revision: https://reviews.llvm.org/D34557
llvm-svn: 306116
Restore the `-gz` option to the driver with some minor tweaks to handle
the additional case for `-Wa,--compress-debug-sections`.
This intends to make the compression of the debug information
controllable from the driver. The following is the behaviour:
-gz enable compression (ambiguous for format, will default to zlib-gnu)
-gz=none disable compression
-gz=zlib-gnu enable compression (deprecated GNU style zlib compression)
-gz=zlib enable compression (zlib based compression)
Although -Wa,-compress-debug-sections works, it should be discouraged
when using the driver to invoke the assembler. However, we permit the
assembler to accept the GNU as style argument --compress-debug-sections
to maintain compatibility.
Note, -gz/-gz= does *NOT* imply -g. That is, you need to additionally
specific -g for debug information to be generated.
llvm-svn: 306115
Also, don't use the outdated lib32/lib64 naming of files
within the sysroot. The more modern/flexible approach
IIUC is to use seperate sysroots or /lib/<target-tripple>
and /include/<target-tripple>.
Differential Revision: https://reviews.llvm.org/D33565
llvm-svn: 306074
deployment target if the SDK is newer than the system
This commit also reverts follow-up commits r305680 and r305685 that have
buildbot fixes.
The change in r305678 wasn't correct because it relied on
`llvm::sys::getProcessTriple`, which uses a pre-configured OS version. We should
lookup the actual macOS version of the system on which the compiler is running.
llvm-svn: 305891
This is patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
In this patch, Options.td was mainly changed in order to add value class
in Options.inc.
llvm-svn: 305805
That commit failed on non-macOS buildbots as I've forgotten to make sure that
the system on which Clang is running on is actually macOS.
llvm-svn: 305680
if the SDK is newer than the system
This commit improves the driver by making sure that it picks the system version
for the deployment target when the version of the macOS SDK is newer than the
system version.
rdar://29449467
Differential Revision: https://reviews.llvm.org/D34175
llvm-svn: 305678
This is a patch for bug: https://bugs.llvm.org/show_bug.cgi?id=6817
Warnings should not be emitted with -M and -MM flags, because this mode
is only used for generate MakeFiles.
llvm-svn: 305561
cc1as does not currently access the "--" version of this flag. At the
very least this needs to be fixed and proper test cases need to be
added.
Simple reproducer:
clang -Wa,--compress-debug-sections /tmp/test.cc
Result:
error: unknown argument: '--compress-debug-sections'
llvm-svn: 305182
Split the no-ias tests and give them a target to ensure that they go
down the GNU toolchain path. Adjust the no compression support tests.
llvm-svn: 305167
These options control the behaviour of the compression of debug info
sections on ELF targets. Our behaviour slightly diverges from the
behaviour of GCC. `-gz` maps to the `-compress-debug-sections` rather
than `-compress-debug-sections=zlib` or
`-compress-debug-sections=zlib-gnu`. This small divergence allows us to
be compatible across versions of binutils (=zlib support was introduced
in 2.26, while earlier versions only support =zlib-gnu). This also
allows users to not have to worry about the version of the assembler
they may be using if they are not using the IAS. Previously, users
would have had to go through the internal option
`-compress-debug-sectionss` and pass that through to the assembler,
which is no longer needed.
llvm-svn: 305165
Rather than validating the flags, pass them through without any
validation. Arguments passed via -Wa or -Xassembler are passed directly
to the assembler without validation. The validation was previously
required since we did not provide proper driver level support for
controlling the debug compression on ELF targets. A subsequent change
will add support for the `-gz` and `-gz=` flags which provide proper
driver level control of the ELF compressed debug sections.
llvm-svn: 305164
If specified, when preprocessing, the contents of imported .pcm files will be
included in preprocessed output. The resulting preprocessed file can then be
compiled standalone without the module sources or .pcm files.
llvm-svn: 305116
The test in r304929 broke multiple buildbots as it expected mips target to
be registered and available (which is not necessarily true). Updating the
test with this condition.
Original commit:
[mips] Add runtime options to enable/disable madd.fmt and msub.fmt
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
llvm-svn: 304953
Revert r304929 since the test broke buildbots.
Original commit:
[mips] Add runtime options to enable/disable madd.fmt and msub.fmt
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
llvm-svn: 304935
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D33401
llvm-svn: 304929
Summary:
In D33900, I added printing of the registered targets in clang's
`PrintVersion` function, which is not only used for `--version` output,
but also for `-v` (verbose mode) and `-###`. Especially the latter
seems to trip up some test cases, so it is probably better to only print
the registered targets for `--version`.
Reviewers: nemanjai, mehdi_amini
Reviewed By: nemanjai
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33981
llvm-svn: 304899
Summary:
Other llvm tools display their registered targets when showing version
information, but for some reason clang has never done this.
To support this, D33899 adds the llvm parts, which make it possible to
print version information to arbitrary raw_ostreams. This change adds
a call to printRegisteredTargetsForVersion in clang's PrintVersion, and
adds a raw_ostream parameter to two other PrintVersion functions.
Reviewers: beanz, chandlerc, dberris, mehdi_amini, zturner
Reviewed By: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33900
llvm-svn: 304836
When cross-compiling to Windows using lld, we want the driver to invoke
it as lld-link rather than lld-link.exe. On Windows, the LLVM fs
functions take care of adding the .exe suffix where necessary, so we can
just drop the addition in the toolchain entirely.
Differential Revision: https://reviews.llvm.org/D33923
llvm-svn: 304761
separate section, by Sergey Dmitriev
Linker script that is generated by the clang driver for creating fat binary puts target binaries for all offload targets into a single ELF section .omp_offloading. This is not convenient because it greatly complicates operations with the final fat binary once it is linked. For example extracting target binary for a particular target from such fat executable would not be an easy task if you have more than one offload target.
Attached patch changes clang driver to put target binary for each
offload target into a separate ELF section .omp_offloading.<target
triple>.
Differential Revision: https://reviews.llvm.org/D33254
llvm-svn: 304229
Also comes with a cmake cache for building the runtime bits:
$ cmake <normal cmake flags> \
-DBAREMETAL_ARMV6M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7EM_SYSROOT=/path/to/sysroot \
-C /path/to/clang/cmake/caches/BaremetalARM.cmake \
/path/to/llvm
https://reviews.llvm.org/D33259
llvm-svn: 303873
This is recommit of r302775, reverted in r302777 due to a fail in
clang-tidy. Original mesage is below.
Now if clang driver is given wrong arguments, in some cases it
continues execution and returns zero code. This change fixes this
behavior.
The fix revealed some errors in clang test set.
File test/Driver/gfortran.f90 added in r118203 checks forwarding
gfortran flags to GCC. Now driver reports error on this file, because
the option -working-directory implemented in clang differs from the
option with the same name implemented in gfortran, in clang the option
requires argument, in gfortran does not.
In the file test/Driver/arm-darwin-builtin.c clang is called with
options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed
in r191435 and now clang reports error on this test.
File arm-default-build-attributes.s uses option -verify, which is not
supported by driver, it is cc1 option.
Similarly, the file split-debug.h uses options -fmodules-embed-all-files
and -fmodule-format=obj, which are not supported by driver.
Other revealed errors are mainly mistypes.
Differential Revision: https://reviews.llvm.org/D33013
llvm-svn: 303756
Summary:
This is a first patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
Simple flag completion and path completion is available in this patch.
Reviewers: teemperor, v.g.vassilev, ruiu, Bigcheese, efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33237
llvm-svn: 303670
Now if clang driver is given wrong arguments, in some cases it
continues execution and returns zero code. This change fixes this
behavior.
The fix revealed some errors in clang test set.
File test/Driver/gfortran.f90 added in r118203 checks forwarding
gfortran flags to GCC. Now driver reports error on this file, because
the option -working-directory implemented in clang differs from the
option with the same name implemented in gfortran, in clang the option
requires argument, in gfortran does not.
In the file test/Driver/arm-darwin-builtin.c clang is called with
options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed
in r191435 and now clang reports error on this test.
File arm-default-build-attributes.s uses option -verify, which is not
supported by driver, it is cc1 option.
Similarly, the file split-debug.h uses options -fmodules-embed-all-files
and -fmodule-format=obj, which are not supported by driver.
Other revealed errors are mainly mistypes.
Differential Revision: https://reviews.llvm.org/D33013
llvm-svn: 302775
This feature is subtly broken when the linker is gold 2.26 or
earlier. See the following bug for details:
https://sourceware.org/bugzilla/show_bug.cgi?id=19002
Since the decision needs to be made at compilation time, we can not
test the linker version. The flag is off by default on ELF targets,
and on otherwise.
llvm-svn: 302591
Add the toolchain installation directory to the program
path so that lld can be found.
Change -flavor to wasm. Although this new flavor hasn't
yet landed in upstream lld yet there are no point in
passing wasm objects the gnu flavor.
Differential Revision: https://reviews.llvm.org/D32976
llvm-svn: 302558
When enabling any sanitizer, -fsanitize-use-after-scope is enabled by
default. This doesn't actually turn ASan on, because we've been getting
lucky and there are extra checks in BackendUtil that stop this from
happening.
However, this has been causing a behavior change: extra lifetime markers
are emitted in some cases where they aren't needed or expected.
llvm-svn: 302468
This is because -print-multi-lib depends on them being flags for correctness.
Fixes a case of this in the arm-android multilib selection logic.
llvm-svn: 302207
When building with libc++ don't bother with injecting the libstdc++
search paths into the linker search path. This will make it easier to
switch between ld and lld.
llvm-svn: 302184
Since -gsplit-dwarf is specified on a backend compile (in ThinLTO
parlance) it isn't passed during the frontend compile (because no ELF
object/dwo file is produced then), yet the -fno-split-dwarf-inlining
value needs to be encoded in the LLVM DebugInfo metadata to have
effect...
So let it be specified & it'll be silently ignored if -gsplit-dwarf
isn't used in the end, otherwise it'll be used on a per-cu basis
depending on where it's specified in the frontend compile actions.
llvm-svn: 301684
Previously, adding libfuzzer to a project was a multi-step procedure,
involving libfuzzer compilation, linking the library, and specifying
coverage flags.
With this change,libfuzzer can be enabled by adding a single
-fsanitize=fuzzer flag instead.
llvm-svn: 301212
Since Split DWARF needs to name the actual .dwo file that is generated,
it can't be known at the time the llvm::Module is produced as it may be
merged with other Modules before the object is generated and that object
may be generated with any name.
By passing the Split DWARF file name when LLVM is producing object code
the .dwo file name in the object file can match correctly.
The support for Split DWARF for implicit modules remains the same -
using metadata to store the dwo name and dwo id so that potentially
multiple skeleton CUs referring to different dwo files can be generated
from one llvm::Module.
llvm-svn: 301063
Summary:
Support for leak sanitizer on darwin has been added to
compiler-rt, this patch adds compiler support.
Reviewers: dexonsmith, compnerd
Subscribers: alekseyshl, kubamracek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32192
llvm-svn: 300894
This commit teaches Clang to recognize editor placeholders that are produced
when an IDE like Xcode inserts a code-completion result that includes a
placeholder. Now when the lexer sees a placeholder token, it emits an
'editor placeholder in source file' error and creates an identifier token
that represents the placeholder. The parser/sema can now recognize the
placeholders and can suppress the diagnostics related to the placeholders. This
ensures that live issues in an IDE like Xcode won't get spurious diagnostics
related to placeholders.
This commit also adds a new compiler option named '-fallow-editor-placeholders'
that silences the 'editor placeholder in source file' error. This is useful
for an IDE like Xcode as we don't want to display those errors in live issues.
rdar://31581400
Differential Revision: https://reviews.llvm.org/D32081
llvm-svn: 300667
The driver needs to know whether it's building a module interface or
implementation unit because it affects which outputs it produces and how it
builds the command pipeline. But the frontend doesn't need to know and should
not care: all it needs to know is what action it is being asked to perform on
the input.
(This is in preparation for permitting -emit-obj to be used on a module
interface unit to produce object code without going via a "full" PCM file.)
llvm-svn: 300611
This passes an option to the ARM assembly parser to emit build
attributes for the hardware selected by command line options, when
assembling an assembly file.
This is not enabled for C/C++, as this would result in duplicate build
attribute directives being emitted in each inline assembly block, when
emitting assembly.
This also adds an option to allow disabling this behaviour for assembly
files, for users who were relying on the old behaviour.
Differential revision: https://reviews.llvm.org/D31813
llvm-svn: 300550
The config-*triple* file handling isn't tolerant of
leading/trailing whitespace, making it not terribly
obvious when a single extraneous tab/space/etc will
cause the override to be ignored. This patch simply
trims the lines to ensure that it is tolerant of
whitespace.
llvm-svn: 300328
Remove "REQUIRES: long_tests" from test/Driver/response-file.c since it is now about 10x faster. (We can add that back if it's still too slow for some buildbot.)
llvm-svn: 300136
One way to currently test the reproducers is to setup
"FORCE_CLANG_DIAGNOSTICS_CRASH=1" before invoking clang. This simulates
a crash and produces the same contents needed by the reproducers. The
reproducers are specially useful when triaging Modules issues, not only
on crashes, but also for reproducing misleading warnings, errors, etc.
Add a '-gen-reproducer' driver option to clang (or any similar name) and
give users a flag option.
Note that clang already has a -fno-crash-diagnostics, which disables the
crash reproducers. I've decided not to propose "-fcrash-diagnostics"
since it doesn't convey the ideia of reproduction despite a crash.
rdar://problem/24114619
Differential Revision: https://reviews.llvm.org/D27604
llvm-svn: 300109
crtbegin is not really a proper windows support thing. This was
duplicated when the toolchain was initially built. If the injection of
crtbegin is needed, it can be done via the `/include` directive.
Furthermore, since `-fPIC` doesnt make sense on PE/COFF, crtbegin and
crtbeginS dont really need to be different.
llvm-svn: 299800
The commit yesterday (r299473) to add the `-print-resource-dir`
option was supposed to emit a newline after the resource dir.
Differential Revision: https://reviews.llvm.org/D31447
llvm-svn: 299597
This patch adds the option -print-resource-dir. It simply
prints the resource directory. This information will eventually
be used in compiler-rt to setup COMPILER_RT_LIBRARY_INSTALL_DIR.
Patch by Catherine Moore!
Differential Revision: https://reviews.llvm.org/D31447
llvm-svn: 299473
Summary:
The refactoring introduced a regression in the flag processing for
-fxray-instruction-threshold which causes it to not get passed properly.
This change should restore the previous behaviour.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31491
llvm-svn: 299126
Summary:
The -fxray-always-instrument= and -fxray-never-instrument= flags take
filenames that are used to imbue the XRay instrumentation attributes
using a whitelist mechanism (similar to the sanitizer special cases
list). We use the same syntax and semantics as the sanitizer blacklists
files in the implementation.
As implemented, we respect the attributes that are already defined in
the source file (i.e. those that have the
[[clang::xray_{always,never}_instrument]] attributes) before applying
the always/never instrument lists.
Reviewers: rsmith, chandlerc
Subscribers: jfb, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30388
llvm-svn: 299041
Summary:
This change depends on D31381 where we change the implementation to use
sanitizer_common provided atomic operations library.
Fixes http://llvm.org/PR32274.
Reviewers: pelikan, dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31382
llvm-svn: 298835
Summary:
Now that XRay doesn't require a runtime dependency on a C++ standard
library, we remove that dependency from the clang linker flags.
Reviewers: saugustine, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31313
llvm-svn: 298670
The alias was only ever used on darwin and had some issues there,
and isn't used in practice much. Also fixes a problem with -mno-altivec
not turning off -maltivec.
Also add a diagnostic for faltivec/fno-altivec that directs users to use
maltivec options and include the altivec.h file explicitly.
llvm-svn: 298449
Summary: We need to be able to disable samplepgo for specific files by supporting -fno-auto-profile and -fno-profile-sample-use
Reviewers: davidxl, dnovillo, echristo
Reviewed By: echristo
Subscribers: echristo, cfe-commits
Differential Revision: https://reviews.llvm.org/D31213
llvm-svn: 298446
clang-cl works best when the user runs vcvarsall to set up
an environment before running, but even this is not enough
on VC 2017 when cross compiling (e.g. using an x64 toolchain
to target x86, or vice versa).
The reason is that although clang-cl itself will have a
valid environment, it will shell out to other tools (such
as link.exe) which may not. Generally we solve this through
adding the appropriate linker flags, but this is not enough
in VC 2017.
The cross-linker and the regular linker both link against
some common DLLs, but these DLLs live in the binary directory
of the native linker. When setting up a cross-compilation
environment through vcvarsall, it will add *both* directories
to %PATH%, so that when cl shells out to any of the associated
tools, those tools will be able to find all of the dependencies
that it links against. If you don't do this, link.exe will
fail to run because the loader won't be able to find all of
the required DLLs that it links against.
To solve this we teach the driver how to spawn a process with
an explicitly specified environment. Then we modify the
PATH before shelling out to subtools and run with the modified
PATH.
Patch by Hamza Sood
Differential Revision: https://reviews.llvm.org/D30991
llvm-svn: 298098
Currently the two flags can not work together.
To illustrate the issue, we can have an one line file a.cl contains only an empty function
cat a.cl
void test(){}
Then use
clang -v -save-temps -x cl -Xclang -cl-std=CL2.0 -Xclang -finclude-default-header -target amdgcn -S -c a.cl
we will get redefinition errors for various things.
The reason is that the -finclude-default-header flag is not meant to be on cc1 command other than the preprocessor.
The fix is modeled after the code just below the change to filter the -finclude-default-header flag out when we are not in the preprocess phase.
Differential Revision: https://reviews.llvm.org/D30743
llvm-svn: 297890
-m(i|tv|watch)os-simulator-version-min is on the command line.
Previously the driver would treat -m(i|tv|watch)os-simulator-version-min
as an alias of -m(i|tv|watch)os-version-min. This no longer works since
we now need to distinguish between the two options (the latter is used
for iOS running in a VM, for example).
This commit stops making the simulator options the aliases of the OS
options and defines a macro to differentiate between the two groups of
options.
rdar://problem/28872911
llvm-svn: 297866
2017 changes the way you find an installed copy of
Visual Studio as well as its internal directory layout.
As a result, clang-cl was unable to find VS2017 even
when you had run vcvarsall to set up a toolchain
environment. This patch updates everything for 2017
and cleans up the way we handle a tiered search a la
environment -> installation -> PATH for which copy
of Visual Studio to bind to.
Patch originally by Hamza Sood, with some fixups for landing.
Differential Revision: https://reviews.llvm.org/D30758
llvm-svn: 297851
The way -ffast-math and the various related options to tweak floating-point
handling are handled is inflexible and rather confusing. This patch restructures
things so that we go through the options adjusting our idea of what's enabled as
we go, instead of trying to figure each individual thing out by working
backwards from the end, as this makes the behaviour of each individual option
more clear.
Doing it this way also means we get gcc-compatible behaviour for when the
__FAST_MATH__ and __FINITE_MATH_ONLY__ macros are defined, as they should depend
on the final set of features that are enabled and not just on -ffast-math and
-ffinite-math-only specifically.
Differential Revision: http://reviews.llvm.org/D30582
llvm-svn: 297837
Summary:
This patch adds -f[no-]rtlib-add-rpath, which if enabled, embeds the
arch-specific subdirectory in resource directory using -rpath (instead
of doing so only during native compilation).
This patch also re-enables test arch-specific-libdir.c which was
silently unsupported because of the REQUIRES tag 'linux'.
Reviewers: bkramer, rnk, mgorny
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D30700
llvm-svn: 297751
Teach UBSan to detect when a value with the _Nonnull type annotation
assumes a null value. Call expressions, initializers, assignments, and
return statements are all checked.
Because _Nonnull does not affect IRGen, the new checks are disabled by
default. The new driver flags are:
-fsanitize=nullability-arg (_Nonnull violation in call)
-fsanitize=nullability-assign (_Nonnull violation in assignment)
-fsanitize=nullability-return (_Nonnull violation in return stmt)
-fsanitize=nullability (all of the above)
This patch builds on top of UBSan's existing support for detecting
violations of the nonnull attributes ('nonnull' and 'returns_nonnull'),
and relies on the compiler-rt support for those checks. Eventually we
will need to update the diagnostic messages in compiler-rt (there are
FIXME's for this, which will be addressed in a follow-up).
One point of note is that the nullability-return check is only allowed
to kick in if all arguments to the function satisfy their nullability
preconditions. This makes it necessary to emit some null checks in the
function body itself.
Testing: check-clang and check-ubsan. I also built some Apple ObjC
frameworks with an asserts-enabled compiler, and verified that we get
valid reports.
Differential Revision: https://reviews.llvm.org/D30762
llvm-svn: 297700
- Mips is architecture, not a toolchain
- Might help eliminate the confusion in the future by not having header files with the same name
Differential Revision: https://reviews.llvm.org/D30753
llvm-svn: 297312
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
Summary:
This change adds an arch-specific subdirectory in <ResourceDir>/lib/<OS>
to the linker search path. This path also gets added as '-rpath' for
native compilation if a runtime is linked in as a shared object. This
allows arch-specific libraries to be installed alongside clang.
Reviewers: danalbert, cbergstrom, javed.absar
Subscribers: srhines
Differential Revision: https://reviews.llvm.org/D30015
llvm-svn: 296927
As is the case on platforms like Mips, X86 and SystemZ, the -fomit-frame-pointer
should be enabled by default on PPC when optimizing at -O1 and above. This
brings the behaviour of LLVM on PPC in line with GCC.
Committing on behalf of Hiroshi Inoue.
Differential Revision: https://reviews.llvm.org/D29750
llvm-svn: 296861
The option -mexecute-only is translated into the backend option
-arm-execute-only. But this option only makes sense for the compiler and
the assembler does not recognize it. This patch stops clang from passing
this option to the assembler.
Change-Id: I4f4cb1162c13cfd50a0a36702a4ecab1bc0324ba
Review: https://reviews.llvm.org/D30414
llvm-svn: 296454
Summary: This enables LTO to be used with the clang-cl frontend.
Reviewers: rnk, hans
Reviewed By: hans
Subscribers: pcc, cfe-commits, mehdi_amini, Prazek
Differential Revision: https://reviews.llvm.org/D30239
llvm-svn: 296373
This get the resource dir string to match with the one from libclang (which is not adding '/../'),
and allows clang to accept a modules-enabled PCH that was created by libclang.
llvm-svn: 296262
The runtime support is provided directly by the Fuchsia system C
library.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D30238
llvm-svn: 296082
This patch moves helper functions that are CPU-specific out of Driver.cpp and to
separate implementation files. The new files are named for the architecture,
e.g. ARMArch.cpp.
The next step after this will be to move OS-specific code, which I expect will
include many of the tool implementations, to similarly separate files.
Some CPU-specific functions are not being moved just yet. In cases where the
only caller is the platform-specific tools, I plan to move them together. An
example is Hexagon, where the only caller of the architecture-specific functions
are the tools themselves. (I'm happy to revise this choice, it just seems like
less churn to me.)
This does mean that some functions which were previously static are now exposed
through the library header Driver.h.
Reviewers: rsmith, javed.absar
Subscribers: aemerson, danalbert, srhines, dschuff, jyknight, nemanjai, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30315
llvm-svn: 296056
freescale triple.
On multiarch systems, this previously caused us to stat every file in
/usr/lib/<triple> (typically several thousand files). This change halves
the runtime of a clang invocation on an empty file on my system.
llvm-svn: 295140
On Windows the filename might have an extension, namely
`.exe`, so the search will fail. Sorry, I don't have a
good way to test this as it seems to fail only in some
weird configurations. r284430 has the same modification
for Fuchsia.
llvm-svn: 294879
Summary:
powerpc64 big-endian is not supported, but I believe that most logic can
be shared, except for xray_powerpc64.cc.
Also add a function InvalidateInstructionCache to xray_util.h, which is
copied from llvm/Support/Memory.cpp. I'm not sure if I need to add a unittest,
and I don't know how.
Reviewers: dberris, echristo, iteratee, kbarton, hfinkel
Subscribers: mehdi_amini, nemanjai, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29742
llvm-svn: 294781
We need -wholearchive for asan_cxx, the same than for asan.
Clang Driver will add asan_cxx at the beginning of the arg list that we pass to
the linker. To ensure that all the static libraries are linked to asan_cxx, we
force the linker to include the object files in asan_cxx.
This fixes some linker errors when compiling with address sanitizer for MT and
passing the static library libFuzzer.
Differential Revision: https://reviews.llvm.org/D29754
llvm-svn: 294604
While there is nothing to do at link time to get pthreads support on
darwin, specifying the argument is fine and we should not warn about
unused arguments.
llvm-svn: 294065
Summary:
The patch updates the MSVC ToolChain for the changes made in Visual
Studio 2017[1].
Other notable changes:
- Path handling code has been centralised to make potential future
changes less painful.
- A compiler error is emitted if the driver is unable to locate a
usable MSVC toolchain. (Previously it'd fail with a cryptic error
such as "link.exe is not executable")
- Support for the new Setup Config Server API[2] has been added,
albeit block commented out with a preprocessor conditional. This can
probably be re-evaluated when the API is officially released (it's
currently at the RC stage), but it's left in to make it easy for
anyone familiar with the API to give it a go with Clang.
Patch by Hamza Sood.
[1] https://blogs.msdn.microsoft.com/vcblog/2016/10/07/compiler-tools-layout-in-visual-studio-15/
[2] https://blogs.msdn.microsoft.com/heaths/2016/09/15/changes-to-visual-studio-15-setup/
Reviewers: ruiu, hans, rnk
Reviewed By: rnk
Subscribers: awson, RKSimon, amccarth, cfe-commits
Differential Revision: https://reviews.llvm.org/D28365
llvm-svn: 293923
In Windows, when the sanitizer is implemented as a static library, we use
auxiliary static library dll_thunk that will be linked to the dlls that have
instrumentation, so they can refer to the runtime in the main executable.
It uses interception to get a pointer the function in the main executable and
override its function with that pointer.
Because of that, we need to ensure that the main executable exports all the
sanitizers' interface, otherwise the initialization in dll_thunk will fail.
In this commit we add the flag -wholearchive to clang driver to ensure that
the linker does not omit any object files from asan library.
Differential Revision: https://reviews.llvm.org/D29334
llvm-svn: 293668
I modify clang driver for windows to include:
"-wholearchive:asan_dynamic_runtime_thunk", so all object files in the
static library: asan_dynamic_runtime_thunk are considered by the linker.
This is necessary, because some object files only include linker pragmas,
and doesn't resolve any symbol. If we don't include that flag, the
linker will ignore them, and won't read the linker pragmas.
Differential Revision: https://reviews.llvm.org/D29159
llvm-svn: 293420
In r279546 I disabled all frame pointer elimination at the front-end on
ARM-Darwin (and warned about it) because before that the backend had been
silently ignoring these options. It turns out we didn't ignore
-momit-leaf-frame-pointer though, just the more general -fomit-frame-pointer.
So this re-enables passing that down to CodeGen so that everything really does
continue working as before (with better diagnostics).
llvm-svn: 293311
Both on Mac and Windows, it's common to have a 'Users' directory in the
root of the filesystem, so one might specify a filename as
'/Users/me/myfile.c'. clang-cl (as well as MSVC's cl.exe) will interpret
that as invoking the '/U' option, which is probably not what the user
wanted. Add a warning about this.
Differential Revision: https://reviews.llvm.org/D29198
llvm-svn: 293305
The patch teaches the Clang driver how to handle the N64 static
relocation model properly. It enforces the correct target feature
(+noabicalls) when -fno-pic is used. This is required as non-pic
N64 code as the abi extension to call PIC code (CPIC) is unsupported.
Make PIC the default for mips64 and mips64el, this affects both N32
& N64 ABIs, to better match GCC.
As part of this effort, clean up the assembler invocation command
builder, so the correct flags are used.
This and r293279 in LLVM resolves PR/23485.
Thanks to Brooks Davis for reporting the issue!
Reviewers: slthakur, seanbruno
Differential Revision: https://reviews.llvm.org/D29031
llvm-svn: 293285
Sometime clang would be supplied -fobjc-arc -f(no)objc-arc-exceptions
and then later disable ARC with -fno-objc-arc, which only negate first
option, but not the latter, resulting usused argument warning. Silence
this warning only when -fno-objc-arc option is present.
Patch by Onha Choe!
llvm-svn: 293014
Summary: These accessors maps directly to the command line option.
Reviewers: steven_wu
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D29065
llvm-svn: 292960
Summary:
SamplePGO uses profile with debug info to collect profile. Unlike the traditional debugging purpose, sample pgo needs more accurate debug info to represent the profile. We add -femit-accurate-debug-info for this purpose. It can be combined with all debugging modes (-g, -gmlt, etc). It makes sure that the following pieces of info is always emitted:
* start line of all subprograms
* linkage name of all subprograms
* standalone subprograms (functions that has neither inlined nor been inlined)
The impact on speccpu2006 binary size (size increase comparing with -g0 binary, also includes data for -g binary, which does not change with this patch):
-gmlt(orig) -gmlt(patched) -g
433.milc 4.68% 5.40% 19.73%
444.namd 8.45% 8.93% 45.99%
447.dealII 97.43% 115.21% 374.89%
450.soplex 27.75% 31.88% 126.04%
453.povray 21.81% 26.16% 92.03%
470.lbm 0.60% 0.67% 1.96%
482.sphinx3 5.77% 6.47% 26.17%
400.perlbench 17.81% 19.43% 73.08%
401.bzip2 3.73% 3.92% 12.18%
403.gcc 31.75% 34.48% 122.75%
429.mcf 0.78% 0.88% 3.89%
445.gobmk 6.08% 7.92% 42.27%
456.hmmer 10.36% 11.25% 35.23%
458.sjeng 5.08% 5.42% 14.36%
462.libquantum 1.71% 1.96% 6.36%
464.h264ref 15.61% 16.56% 43.92%
471.omnetpp 11.93% 15.84% 60.09%
473.astar 3.11% 3.69% 14.18%
483.xalancbmk 56.29% 81.63% 353.22%
geomean 15.60% 18.30% 57.81%
Debug info size change for -gmlt binary with this patch:
433.milc 13.46%
444.namd 5.35%
447.dealII 18.21%
450.soplex 14.68%
453.povray 19.65%
470.lbm 6.03%
482.sphinx3 11.21%
400.perlbench 8.91%
401.bzip2 4.41%
403.gcc 8.56%
429.mcf 8.24%
445.gobmk 29.47%
456.hmmer 8.19%
458.sjeng 6.05%
462.libquantum 11.23%
464.h264ref 5.93%
471.omnetpp 31.89%
473.astar 16.20%
483.xalancbmk 44.62%
geomean 16.83%
Reviewers: davidxl, andreadb, rob.lougher, dblaikie, echristo
Reviewed By: dblaikie, echristo
Subscribers: hfinkel, rob.lougher, andreadb, gbedwell, cfe-commits, probinson, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25435
llvm-svn: 292458
In ThinLTO mode, type metadata will require the module to be written as a
multi-module bitcode file, which is currently incompatible with the Darwin
linker. It is also useful to be able to enable or disable multi-module bitcode
for testing purposes. This introduces a cc1-level flag, -f{,no-}lto-unit,
which is used by the driver to enable multi-module bitcode on all but
Darwin+ThinLTO, and can also be used to enable/disable the feature manually.
Differential Revision: https://reviews.llvm.org/D28877
llvm-svn: 292448
-mglobal-merge is translated to the appropriate backend option in
the driver. r277322 changed the AArch64 option name in the backend,
but the driver was never updated.
llvm-svn: 292192
- Don't break using '-mllvm -disable-llvm-optzns' (yet).
- Don't add support for '-mllvm -disable-llvm-passes'.
This is important for LLVM 4 as we haven't yet really told folks this is
coming. I'll add release notes about this.
I've also added some explicit testing of this so its more obvious what
is happening here.
llvm-svn: 291850
Summary:
openSuse has AArch64 support, with images running on the Raspberry Pi 3.
The libraries and headers live under the aarch64-suse-linux subdirectory,
which is currently not in the AArch64 triples list. Address this by adding
the corresponding string to AArch64Triples.
Reviewers: chandlerc, bruno, bkramer, rengolin
Subscribers: aemerson, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D28238
llvm-svn: 291598
Summary:
For the most part this is straightforward: Just add a CudaInstallation
object to the MSVC and MinGW toolchains.
CudaToolChain has to override computeMSVCVersion so that
Clang::constructJob passes the right version flag to cc1. We have to
modify IsWindowsMSVC and friends in Clang::constructJob to be true when
compiling CUDA device code on Windows for the same reason.
Depends on: D28319
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28320
llvm-svn: 291131
Summary:
Previously it was taking the true target triple, which is not really
what it needs: The location of the CUDA installation depends on the host
OS.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28319
llvm-svn: 291130
Summary:
Authored by Senthil Kumar Selvaraj
This patch adds barebones support in Clang for the (experimental) AVR target. It uses the integrated assembler for assembly, and the GNU linker for linking, as lld doesn't know about the target yet.
The DataLayout string is the same as the one in AVRTargetMachine.cpp. The alignment specs look wrong to me, as it's an 8 bit target and all types only need 8 bit alignment. Clang failed with a datalayout mismatch error when I tried to change it, so I left it that way for now.
Reviewers: rsmith, dylanmckay, cfe-commits, rengolin
Subscribers: rengolin, jroelofs, wdng
Differential Revision: https://reviews.llvm.org/D27123
llvm-svn: 291082
in non-void functions that fall off at the end without returning a value when
compiling C++.
Clang uses the new compiler flag to determine when it should treat control flow
paths that fall off the end of a non-void function as unreachable. If
-fno-strict-return is on, the code generator emits the ureachable and trap
IR only when the function returns either a record type with a non-trivial
destructor or another non-trivially copyable type.
The primary goal of this flag is to avoid treating falling off the end of a
non-void function as undefined behaviour. The burden of undefined behaviour
is placed on the caller instead: if the caller ignores the returned value then
the undefined behaviour is avoided. This kind of behaviour is useful in
several cases, e.g. when compiling C code in C++ mode.
rdar://13102603
Differential Revision: https://reviews.llvm.org/D27163
llvm-svn: 290960
to be specified for a template template parameter whenever the parameter is at
least as specialized as the argument (when there's an obvious and correct
mapping from uses of the parameter to uses of the argument). For example, a
template with more parameters can be passed to a template template parameter
with fewer, if those trailing parameters have default arguments.
This is disabled by default, despite being a DR resolution, as it's fairly
broken in its current state: there are no partial ordering rules to cope with
template template parameters that have different parameter lists, meaning that
code that attempts to decompose template-ids based on arity can hit unavoidable
ambiguity issues.
The diagnostics produced on a non-matching argument are also pretty bad right
now, but I aim to improve them in a subsequent commit.
llvm-svn: 290792
Windows uses PE/COFF which is inherently position independent. The use
of the PIC model is unnecessary. In fact, we would generate invalid
code using the ELF PIC model when PIC was enabled previously. Now that
we no longer accept -fPIC and -fpoc, this switches the internal
representation to the static model to permit us to make PIC modules
invalid when targeting Windows. This should not change the code
generation, only the internal state management.
llvm-svn: 290569
Use of these flags would result in the use of ELF-style PIE/PIC code
which is incorrect on Windows. Windows is inherently PIC by means of
the DLL slide that occurs at load. This also mirrors the behaviour on
GCC for MinGW. Currently, the Windows x86_64 forces the relocation
model to PIC (Level 2). This is unchanged for now, though we should
remove any assumptions on that and change it to a static relocation
model.
llvm-svn: 290533
manager, and a code path to use it.
The option is actually a top-level option but does contain
'experimental' in the name. This is the compromise suggested by Richard
in discussions. We expect this option will be around long enough and
have enough users towards the end that it merits not being relegated to
CC1, but it still needs to be clear that this option will go away at
some point.
The backend code is a fresh codepath dedicated to handling the flow with
the new pass manager. This was also Richard's suggested code structuring
to essentially leave a clean path for development rather than carrying
complexity or idiosyncracies of how we do things just to share code with
the parts of this in common with the legacy pass manager. And it turns
out, not much is really in common even though we use the legacy pass
manager for codegen at this point.
I've switched a couple of tests to run with the new pass manager, and
they appear to work. There are still plenty of bugs that need squashing
(just with basic experiments I've found two already!) but they aren't in
this code, and the whole point is to expose the necessary hooks to start
experimenting with the pass manager in more realistic scenarios.
That said, I want to *strongly caution* anyone itching to play with
this: it is still *very shaky*. Several large components have not yet
been shaken down. For example I have bugs in both the always inliner and
inliner that I have already spotted and will be fixing independently.
Still, this is a fun milestone. =D
One thing not in this patch (but that might be very reasonable to add)
is some level of support for raw textual pass pipelines such as what
Sean had a patch for some time ago. I'm mostly interested in the more
traditional flow of getting the IR out of Clang and then running it
through opt, but I can see other use cases so someone may want to add
it.
And of course, *many* features are not yet supported!
- O1 is currently more like O2
- None of the sanitizers are wired up
- ObjC ARC optimizer isn't wired up
- ...
So plenty of stuff still lef to do!
Differential Revision: https://reviews.llvm.org/D28077
llvm-svn: 290450
Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.
There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.
This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.
This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.
Differential Revision: https://reviews.llvm.org/D28047
llvm-svn: 290392
The parameter to ParsePICOpts passed the effective triple and then used
that in a few places and used the actual triple in others. This was
slightly confusing. Rename the parameter to make it more obvious.
llvm-svn: 290303
gtest is a widely-used unit-testing API. It provides macros for unit test
assertions:
ASSERT_TRUE(p != nullptr);
that expand into an if statement that constructs an object representing
the result of the assertion and returns when the assertion is false:
if (AssertionResult gtest_ar_ = AssertionResult(p == nullptr))
;
else
return ...;
Unfortunately, the analyzer does not model the effect of the constructor
precisely because (1) the copy constructor implementation is missing from the
the header (so it can't be inlined) and (2) the boolean-argument constructor
is constructed into a temporary (so the analyzer decides not to inline it since
it doesn't reliably call temporary destructors right now).
This results in false positives because the analyzer does not realize that the
the assertion must hold along the non-return path.
This commit addresses the false positives by explicitly modeling the effects
of the two un-inlined constructors on the AssertionResult state.
I've added a new package, "apiModeling", for these kinds of checkers that
model APIs but don't emit any diagnostics. I envision all the checkers in
this package always being on by default.
This addresses the false positives reported in PR30936.
Differential Revision: https://reviews.llvm.org/D27773
rdar://problem/22705813
llvm-svn: 290143
Summary:
This lets you build with one CUDA installation but use ptxas from
another install.
This is useful e.g. if you want to avoid bugs in an old ptxas without
actually upgrading wholesale to a newer CUDA version.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27788
llvm-svn: 289847
Summary:
This implements execute-only support for ARM code generation, which
prevents the compiler from generating data accesses to code sections.
The following changes are involved:
* Add the CodeGen option "-arm-execute-only" to the ARM code generator.
* Add the clang flag "-mexecute-only" as well as the GCC-compatible
alias "-mpure-code" to enable this option.
* When enabled, literal pools are replaced with MOVW/MOVT instructions,
with VMOV used in addition for floating-point literals. As the MOVT
instruction is required, execute-only support is only available in
Thumb mode for targets supporting ARMv8-M baseline or Thumb2.
* Jump tables are placed in data sections when in execute-only mode.
* The execute-only text section is assigned section ID 0, and is
marked as unreadable with the SHF_ARM_PURECODE flag with symbol 'y'.
This also overrides selection of ELF sections for globals.
Reviewers: t.p.northover, rengolin
Subscribers: llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D27450
llvm-svn: 289786
Most of the PowerPC64 code generation already creates PIC access. This
changes to a full PIC default, similar to what GCC is doing.
Overall, a monolithic clang binary shrinks by 600KB (about 1%). This can
be a slight regression for TLS access and will use the TOC more
aggressively instead of synthesizing immediates. It is expected to be
performance neutral.
Differential Revision: https://reviews.llvm.org/D26564
llvm-svn: 289744
This change allows setting the default linker used by the Clang
driver when configuring the build.
Differential Revision: https://reviews.llvm.org/D25263
llvm-svn: 289668
Collect the necessary input PCH files.
Do not try to validate the AST before copying it out because if the
crash is in this path, we won't be able to collect it. Instead only
check if it's a file containg an AST.
rdar://problem/27913709
llvm-svn: 289460
Fix the gcc-config code to support multilib gcc installs properly. This
solves two problems: -mx32 using the 64-bit gcc directory (due to matching
installation triple), and -m32 not respecting gcc-config at all (due to
mismatched installation triple).
In order to fix the former issue, split the multilib scan out of
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple() (the code
is otherwise unchanged), and call it for each installation found via
gcc-config.
In order to fix the latter issue, split the gcc-config processing out of
Generic_GCC::GCCInstallationDetector::init() and repeat it for all
triples, including extra and biarch triples. The only change
in the gcc-config code itself is adding the call to multilib scan.
Convert the gentoo_linux_gcc_multi_version_tree test input to multilib
x86_64+32+x32 install, and add appropriate tests to linux-header-search
and linux-ld.
Differential Revision: https://reviews.llvm.org/D26887
llvm-svn: 289436
I made the wrong assumption that execution would continue after an error Diag
which led to unneeded complex code.
This patch aligns with the better implementation of ToolChain::GetRuntimeLibType.
Differential Revision: https://reviews.llvm.org/D25669
llvm-svn: 289422
This allows us to negate preceding --cuda-gpu-arch=X.
This comes handy when user needs to override default
flags set for them by the build system.
Differential Revision: https://reviews.llvm.org/D27631
llvm-svn: 289287
The most common workflow with module reproducers involves deleting the
module cache before running the script. This happens because leftovers
from the crash are present in the cache and could trigger unrelated and
confusing errors, misleading from the initial reproduction intent.
Change this to point to a clean path but leave the leftovers untouched.
rdar://problem/28655070
llvm-svn: 289176
When -fmodules is on, the reproducer invocation currently leave paths
for include-like flags as is. If the path is relative, the reproducer
doesn't know how to access that file during reproduction time because
the VFS cannot reason about relative paths.
Expand relative paths to absolute ones when creating the reproducer
command line. This allows, for example, the reproducer to work for
crashes while building clang with modules; this wasn't possible before
because building clang requires using relative inc dir from within the
build directory.
rdar://problem/28655070
llvm-svn: 289174
Currently -fstack-protector is on by default when using -ffreestanding.
Change the default behavior to have it off when using -ffreestanding.
rdar://problem/14089363
llvm-svn: 289005
Summary:
The MSVC toolchain and Clang driver combination currently uses a fairly complex
sequence of steps to determine the MS compatibility version to pass to cc1.
There is some oddness in this sequence currently, with some code which inspects
flags in the toolchain, and some code which inspects the triple and local
environment in the driver code.
This change is an attempt to consolidate most of this logic so that
Win32-specific code lives in MSVCToolChain.cpp. I'm not 100% happy with the
split, so any suggestions are welcome.
There are a few things you might want to watch for for specifically:
- On all platforms, if MSVC compatibility flags are provided (and valid), use
those.
- The fallback sequence should be the same as before, but is now consolidated
into MSVCToolChain::getMSVCVersion:
- Otherwise, try to use the Triple.
- Otherwise, on Windows, check the executable.
- Otherwise, on Windows or with --fms-extensions, default to 18.
- Otherwise, we can't determine the version.
- MSVCToolChain::ComputeEffectiveTriple no longer calls the base
ToolChain::ComputeEffectiveClangTriple. The only thing it would change for
Windows the architecture, which we don't care about for the compatibility
version.
- I'm not sure whether this is philosophically correct (but it should
be easy to add back to MSVCToolChain::getMSVCVersionFromTriple if not).
- Previously, Tools.cpp just called getTriple() anyhow, so it doesn't look
like the effective triple was always being used previously anyhow.
Reviewers: hans, compnerd, llvm-commits, rnk
Subscribers: amccarth
Differential Revision: https://reviews.llvm.org/D27477
llvm-svn: 288998
As a first step toward removing Objective-C garbage collection from
Clang, remove support from the driver. I'm hoping this will flush out
any expected bots/configurations/whatever that might rely on it.
I've left the options behind temporarily in -cc1 to keep tests passing.
I'll kill them off entirely in a follow up when I've had a chance to
update/delete the rest of Clang.
llvm-svn: 288872
When integrating compilation database output into existing build
systems, two approaches dominate so far. Ad-hoc implementation of the
JSON output rules or using compiler wrappers. This patch adds a new
option "-MJ foo.json" which gives a slightly cleaned up compilation
record. The output is a fragment, i.e. you still need to add the array
markers, but it allows multiple files to be easy merged.
This way the only change in a build system is adding the option with
potentially a per-target output file and merging the files with
something like
(echo '['; cat *.o.json; echo ']' > compilation_database.json
or some additional filtering to remove the trailing comma for strict
JSON compliance.
Differential Revision: https://reviews.llvm.org/D27140
llvm-svn: 288821
This is to match the behavior of non-LTO;
when -fsave-optimization-record is passed and PGO is available we enable
the generation of hotness information in the optimization records.
Differential Revision: https://reviews.llvm.org/D27332
llvm-svn: 288520
Summary:
This is an improvement on rL288448 where address sanitization was listed
as supported for the CudaToolChain. Since the intent is for the
CudaToolChain not to reject any flags supported by the host compiler,
this patch switches to forwarding the CudaToolChain sanitizer support to
the host toolchain rather than explicitly whitelisting address
sanitization.
Thanks to hfinkel for this suggestion.
Reviewers: jlebar
Subscribers: hfinkel, cfe-commits
Differential Revision: https://reviews.llvm.org/D27351
llvm-svn: 288512
This fixes a bug that was introduced in rL287285. The bug made it
illegal to pass -fsanitize=address during CUDA compilation because the
CudaToolChain class was switched from deriving from the Linux toolchain
class to deriving directly from the ToolChain toolchain class. When
CudaToolChain derived from Linux, it used Linux's getSupportedSanitizers
method, and that method allowed ASAN, but when it switched to deriving
directly from ToolChain, it inherited a getSupportedSanitizers method
that didn't allow for ASAN.
This patch fixes that bug by creating a getSupportedSanitizers method
for CudaToolChain that supports ASAN.
This patch also fixes the test that checks that -fsanitize=address is
passed correctly for CUDA builds. That test didn't used to notice if an
error message was emitted, and that's why it didn't catch this bug when
it was first introduced. With the fix from this patch, that test will
now catch any similar bug in the future.
llvm-svn: 288448
Summary: This patch adds a check and an error message to gnutools::Linker::ConstructJob in case the architecture is not supported. For most other operating systems, the error message is created in lib/Basic/Targets.cpp:AllocateTarget, but when construction the linker arguments for the gnutools linker a supported architecture is required.
Reviewers: rafael, joerg, echristo
Subscribers: mehdi_amini, joerg, dschuff, cfe-commits
Differential Revision: https://reviews.llvm.org/D27066
llvm-svn: 288327
Fix recognizing newer OpenSUSE versions that combine the two version
components into 'VERSION = x.y'. The check was written against an older
version that kept those two split as VERSION and PATCHLEVEL.
Differential Revision: https://reviews.llvm.org/D26850
llvm-svn: 288061
Refactor the Distro enum along with helper functions into a full-fledged
Distro class, inspired by llvm::Triple, and make it a public API.
The new class wraps the enum with necessary comparison operators, adding
the convenience Is*() methods and a constructor performing
the detection. The public API is needed to run the unit tests (D25869).
Differential Revision: https://reviews.llvm.org/D25949
llvm-svn: 288060
https://reviews.llvm.org/D25932 made it so that clang always checks if
libLTO.dylib is present on disk, even if -flto is not being used. The
motivation for that change was that if a dependency happens to contain bitcode,
ld64 will try to load libLTO without -flto explicitly being enabled. However,
the change had the undesirable side effect of warning if libLTO.dylib doesn't
exist even if it isn't needed.
Change things so that -lto_library is always passes, independent of if it
exists or not. ld64 only looks at this flag if it uses LTO. If the dylib
exists, all is well. If it doesn't, and LTO is not being used, all is well too.
If ld64 does end up using LTO and the dylib does not exist, ld64 will print
something like
ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64
https://reviews.llvm.org/D26984
llvm-svn: 287685
Summary:
Compiling CUDA device code requires us to know the host toolchain,
because CUDA device-side compiles pull in e.g. host headers.
When we only supported Linux compilation, this worked because
CudaToolChain, which is responsible for device-side CUDA compilation,
inherited from the Linux toolchain. But in order to support MacOS,
CudaToolChain needs to take a HostToolChain pointer.
Because a CUDA toolchain now requires a host TC, we no longer will
create a CUDA toolchain from Driver::getToolChain -- you have to go
through CreateOffloadingDeviceToolChains. I am *pretty* sure this is
correct, and that previously any attempt to create a CUDA toolchain
through getToolChain() would eventually have resulted in us throwing
"error: unsupported use of NVPTX for host compilation".
In any case hacking getToolChain to create a CUDA+host toolchain would
be wrong, because a Driver can be reused for multiple compilations,
potentially with different host TCs, and getToolChain will cache the
result, causing us to potentially use a stale host TC.
So that's the main change in this patch.
In addition, we have to pull CudaInstallationDetector out of Generic_GCC
and into a top-level class. It's now used by the Generic_GCC and MachO
toolchains.
Reviewers: tra
Subscribers: rryan, hfinkel, sfantao
Differential Revision: https://reviews.llvm.org/D26774
llvm-svn: 287285
In addition to the preprocessed sources file and reproducer script, also
point to the .crash diagnostic files on Darwin. Example:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cpp
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cache
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.sh
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.crash
When no match is found for the .crash, point the user to a directory
where those can be found. Example:
clang-4.0: note: diagnostic msg: Crash backtrace is located in
clang-4.0: note: diagnostic msg: /Users/bruno/Library/Logs/DiagnosticReports/clang-4.0_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
clang-4.0: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
rdar://problem/27286266
llvm-svn: 287262
Summary:
-fembed-bitcode infers -bitcode_bundle to ld64 but it is not correctly
passed when using LTO. LTO is a special case of -fembed-bitcode which
it doesn't require embed the bitcode in a special section in the object
file but it requires linker to save that as part of the final executable.
rdar://problem/29274226
Reviewers: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26690
llvm-svn: 287084
Alex Lorenz