Diagnostics that happen during driver time do not have color output support
unless -fcolor-diagonostic is explicitly passed into the driver. This is not a
problem for cc1 since dianostic arguments are properly handled and color is
enabled by default if the terminal supports it.
Make the driver behave like CC1. There are tests that already check for these
flags, but for the color itself there's no sensible way to test it.
Differential Revision: http://reviews.llvm.org/D20404
rdar://problem/26290980
llvm-svn: 271042
This patch adds the commandline option -mcompact-branches={never,optimal,always),
which controls how LLVM generates compact branches for MIPSR6 targets. By default,
the compact branch policy is 'optimal' where LLVM will generate the most
appropriate branch for any situation. The 'never' and 'always' policy will disable
or always generate compact branches wherever possible respectfully.
Reviewers: dsanders, vkalintiris, atanasyan
Differential Revision: http://reviews.llvm.org/D20729
llvm-svn: 271000
Summary:
There are no llvm backend tests* for EABI and no EABI buildbots. There were only
three clang tests, all of which checked that -mabi=eabi was passed to the
assembler.
*There is a single backend test that specifies EABI but it actually tests MIPS16.
Reviewers: atanasyan
Subscribers: emaste, sdardis, atanasyan, cfe-commits
Differential Revision: http://reviews.llvm.org/D20679
llvm-svn: 270998
OpenMP version.
If '-fopenmp' option is provided '-fopenmp-version=' allows to control,
which version of OpenMP must be supported. Currently it affects only the
value of _OPENMP define.
llvm-svn: 270838
This reverts commit r270688 and r270689. The issue is not a random order, but a
different order for some targets and others (prob. Linux vs Darwin). Reverting until
we have a better fix.
llvm-svn: 270691
Using AArch64TargetParser in clang to avoid repetitive string parsing.
Use TargetParser to do ARCH/CPU/ArchExt parsing instead of local implementation.
Patch by Jojo Ma.
llvm-svn: 270688
-finline-functions and /Ob2 are currently ignored by Clang. The only way to
enable inlining is to use the global O flags, which also enable other options,
or to emit LLVM bitcode using Clang, then running opt by hand with the inline
pass.
This patch allows to simply use the -finline-functions flag (same as GCC) or
/Ob2 in clang-cl mode to enable inlining without other optimizations.
This is the first patch of a serie to improve support for the /Ob flags.
Patch by Rudy Pons <rudy.pons@ilod.org>!
Differential Revision: http://reviews.llvm.org/D20576
llvm-svn: 270609
Summary:
Following patch D19265 which enable software floating point support in the Sparc backend, this patch enables the option to be enabled in the front-end using the -msoft-float option.
The user should ensure a library (such as the builtins from Compiler-RT) that includes the software floating point routines is provided.
Reviewers: jyknight, lero_chris
Subscribers: jyknight, cfe-commits
Differential Revision: http://reviews.llvm.org/D20419
llvm-svn: 270538
Exherbo has an alternative file system layout to accommodate multiarch. The
loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain
to support that on exherbo.
llvm-svn: 270392
The parameter already requires the toolchain, sink the method into the class.
This also enables the use of the distro detection logic which will be needed to
support Exherbo's multiarch approach.
llvm-svn: 270352
Convert the cascading if/else to a switch. This makes it easier to follow the
logic. Minor difference is that we no longer default to x86_64 but rather to
the architecture specified by the architecture.
llvm-svn: 270351
All additional include directories are relative to the toolchain install
folder. So let's do not pass this folder to each callback to simplify
and slightly reduce the code.
llvm-svn: 270069
CodeSourcery toolchain is a standalone toolchain which always uses
the same triple name in its paths. It is independent from target
triple used by the driver.
llvm-svn: 270067
Summary:
-fembed-bitcode was only checking for old style LTO flag (-flto) but not
considering the new -flto= style option. That makes clang output bitcode
embedded in bitcode object when using -flto= and -fembed-bitcode= together.
Now clang should output normal bitcode file when using LTO and ignores
-fembed-bitcode option.
Reviewers: joker.eph
Subscribers: joker.eph, cfe-commits
Differential Revision: http://reviews.llvm.org/D20374
llvm-svn: 269961
As The default CMAKE install prefix is /usr/local ( https://cmake.org/cmake/help/v3.0/variable/CMAKE_INSTALL_PREFIX.html ),
sudo ninja install ends up installing clang, LLVM and libcxx under /usr/local.
In development scenario, when clang is run from the build location it will not
find libcxx at neither (build location)/../include/c++ nor /usr/include/c++.
This patch lets development clang find system installed libcxx without adding
-isystem /usr/local/include/c++. Also addresses the FIXME by explaining the
use-case for these include paths.
llvm-svn: 269801
licensees actually see in the toolchain we deliver to them. This will
reduce the set of local patches we have to maintain. The triple is
not changing. (The term ORBIS is an internal code name for PS4.)
llvm-svn: 269671
Summary:
The MIPS IAS can now pass 'ninja check-all', recurse, build a bootable linux
kernel, and pass a variety of LNT testing.
Unfortunately we can't enable it by default for 64-bit targets yet since the N32
ABI is still very buggy and this also means we can't enable it for N64 either
because we can't distinguish between N32 and N64 in the relevant code.
Reviewers: vkalintiris
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18759
Differential Revision: http://reviews.llvm.org/D18761
llvm-svn: 269560
-fms-compatibility-version was defaulting to 18 (VS 2013), which is a pain if your environment is pointing to version 19 (VS 2015) libraries.
If cl.exe can be found, this patch uses its version number as the default instead. It re-uses the existing code to find the Visual Studio binaries folder and WinAPI methods to check its version. You can still explicitly specify a compatibility version on the command line. If you don't have cl.exe, this should be a no-op and you'll get the old default of 18.
This affected the tests, which assumed that if you didn't specific a version, that it would default to 18, but this won't be true for all machines. So a couple test cases had to be eliminated and a couple others had to be tweaked to allow for various outputs.
Addresses: https://llvm.org/bugs/show_bug.cgi?id=27215
Differential Revision: http://reviews.llvm.org/D20136
llvm-svn: 269515
Summary:
This option allows the user to control how much of the file name is
emitted by UBSan. Tuning this option allows one to save space in the
resulting binary, which is helpful for restricted execution
environments.
With a positive N, UBSan skips the first N path components.
With a negative N, UBSan only keeps the last N path components.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19666
llvm-svn: 269309
Summary:
Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandline into the bitcode in special sections before compiling to
the object file. Using -fembed-bitcode-marker will only introduce a
marker in both sections.
Depends on D17390
Reviewers: rsmith
Subscribers: yaron.keren, vsk, cfe-commits
Differential Revision: http://reviews.llvm.org/D17392
llvm-svn: 269202
[ Copied from https://llvm.org/bugs/show_bug.cgi?id=26404 ]
clang support on Haiku is lagging a bit, and missing on x86_64.
This patch updates support for x86 and add support for x86_64. It should
apply directly to trunk and it's harmless in the sense that it only
affects Haiku.
Reviewers: rnk, rsmith
Patch by Jérôme Duval
Differential Revision: http://reviews.llvm.org/D16797
llvm-svn: 269201
This patch corresponds to review:
http://reviews.llvm.org/D19684
It simply adds the handling for the option and the corresponding macros.
llvm-svn: 268951
- Don't consider "/etc/lsb-release" to be Ubuntu only.
- Detect SL, too.
- Only add "--no-add-needed" for RHEL7 (or Fedora), not for RHEL6
(that's what the compilers shipped with RHEL do).
- removed RHEL4 which is now four years past EOL and certainly incapable
of building or running any recent version of llvm/clang.
llvm-svn: 268914
Some distros with ten years of support ship an old gcc but later offer
more recent versions for installation in parallel. These versions are
typically not only needed for the compilation of llvm/clang, but also to
properly use the clang binary that comes out.
Clang already searches /usr at runtime for the most recent installation
of gcc. This patch appends paths for add-on installations of gcc in
RHEL.
Patch by Michael Lampe.
llvm-svn: 268912
Summary:
Now that LLVM is emitting version 2 of the AMD code object, we can
start using lld again for linking instead of our custom tool.
Reviewers: arsenm, kzhuravl
Subscribers: rafael, cfe-commits
Differential Revision: http://reviews.llvm.org/D19952
llvm-svn: 268648
r217178 changed clang to add function attribute uwtable by default on
Win64, which caused the __eh_frame section to be emitted by default.
This commit restores the previous behavior for MachO targets.
rdar://problem/25282627
llvm-svn: 268589
This option, like the corresponding gcc option, is SystemZ-specific and
enables storing frame backchain links, as specified in the ABI.
Differential Revision: http://reviews.llvm.org/D19891
llvm-svn: 268575
This reverts commit r264813 / 6484b95d634f53dd929c75265ef3c4decf397584.
While using it in the shell is fine, this a problem when cc1as is
invoked directly by the driver because single quoting the clang full
version makes cc1as write out the version with the quotes in the final
binary.
If the user wants to copy-n-pastable output, it could use either -###
or CC_PRINT_OPTIONS=1 clang -v ...
llvm-svn: 268297
Summary:
This patch adds a new driver warning -Wincompatible-sdk which notifies the user when they are mismatching the version min options and the sysroot.
The patch works by checking the sysroot (if present) for an SDK name, then matching that against the target platform. In the case of a mismatch it logs a warning.
Reviewers: bob.wilson, rsmith
Subscribers: rsmith, edward-san, cfe-commits
Differential Revision: http://reviews.llvm.org/D18088
llvm-svn: 268127
It makes compiler-rt tests fail if the gold plugin is enabled.
Revert "Rework interface for bitset-using features to use a notion of LTO visibility."
Revert "Driver: only produce CFI -fvisibility= error when compiling."
Revert "clang/test/CodeGenCXX/cfi-blacklist.cpp: Exclude ms targets. They would be non-cfi."
llvm-svn: 267871
The -fvisibility= flag only affects compile jobs, so there's no need to
error out because of it if we aren't compiling (e.g. if we are only linking).
llvm-svn: 267824
Bitsets, and the compiler features they rely on (vtable opt, CFI),
only have visibility within the LTO'd part of the linkage unit. Therefore,
only enable these features for classes with hidden LTO visibility. This
notion is based on object file visibility or (on Windows)
dllimport/dllexport attributes.
We provide the [[clang::lto_visibility_public]] attribute to override the
compiler's LTO visibility inference in cases where the class is defined
in the non-LTO'd part of the linkage unit, or where the ABI supports
calling classes derived from abstract base classes with hidden visibility
in other linkage units (e.g. COM on Windows).
If the cross-DSO CFI mode is enabled, bitset checks are emitted even for
classes with public LTO visibility, as that mode uses a separate mechanism
to cause bitsets to be exported.
This mechanism replaces the whole-program-vtables blacklist, so remove the
-fwhole-program-vtables-blacklist flag.
Because __declspec(uuid()) now implies [[clang::lto_visibility_public]], the
support for the special attr:uuid blacklist entry is removed.
Differential Revision: http://reviews.llvm.org/D18635
llvm-svn: 267784
Currently, clang-cl always uses Windows style for unquoting, and clang always
uses POSIX style for unquoting.
With this flag, it's possible to change these defaults.
In general, response file quoting should match the shell the response file is
used in. On Windows, it's possible to run clang-cl in a bash shell, or clang in
cmd.exe, so a flag for overriding the default behavior is natural there.
On non-Windows, Windows quoting probably never makes sense (except maybe in
Wine), but having clang-cl behave differently based on the host OS seems
strange too. So require that people who want to use posix-style response
files with clang-cl on non-Windows pass --rsp-quoting=posix.
http://reviews.llvm.org/D19425
llvm-svn: 267474
Summary:
Adds a framework to enable the instrumentation pass for the new
EfficiencySanitizer ("esan") family of tools. Adds a flag for esan's
cache fragmentation tool via -fsanitize=efficiency-cache-frag.
Adds appropriate tests for the new flag.
Reviewers: eugenis, vitalybuka, aizatsky, filcab
Subscribers: filcab, kubabrecka, llvm-commits, zhaoqin, kcc
Differential Revision: http://reviews.llvm.org/D19169
llvm-svn: 267059
Summary:
This completes the flag's tristate, letting you override it at will on
the command line.
Reviewers: tra
Subscribers: cfe-commits, jhen
Differential Revision: http://reviews.llvm.org/D19248
llvm-svn: 266707
Summary:
Without this change, we silently proceed on without including
__clang_cuda_runtime_wrapper.h. This leads to very strange behavior --
you say you're compiling CUDA code, but e.g. __device__ is not defined!
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19180
llvm-svn: 266496
We've already paid the price for separate "armv7m" and "armv7em" slices
(support in other tools), it's silly to make them identical other than the
default CPU.
rdar://23055688
llvm-svn: 266211
FreeBSD uses LLVM's libunwind on FreeBSD/arm64 today (and is expected to
use it more widely in the future), and it requires the EH frame segment
in static binaries.
This is the same as r203742 for NetBSD.
Differential Revision: http://reviews.llvm.org/D19029
llvm-svn: 266123
r260990 exposed -isystem in clang-cl. -isystem adds a directory to the front of
the system include search path. The idea was to use this to point to a hermetic
msvc install, but as it turns out this doesn't work: -isystem then adds the
hermetic headers in front of clang's builtin headers, and clang's headers that
are supposed to wrap msvc headers (say, stdarg.h) aren't picked up at all
anymore.
So revert that, and instead expose -imsvc which works as if the passed
directory was part of %INCLUDE%: The header is treated as a system header, but
it is searched after clang's lib/Header headers.
Fixes half of PRPR26751.
llvm-svn: 266108
This is the clang part of http://reviews.llvm.org/D18846.
SafeStack instrumentation pass adds stack protector canaries if both
attributes are present on a function. StackProtector pass will step
back if the function has a safestack attribute.
llvm-svn: 266005
As we're currently working on making CloudABI executables easier to
emulate in userspace (e.g., on OS X and Windows), it makes a whole lot
of sense to build these using PIE. By using PIE, they can simply be
loaded into the existing process address space without clashes.
PIE support got added to CloudABI's C library and seems to work pretty
well. CloudABI does not make use of an ld.so, so the binary's _start()
has all the logic in it to do the relocations.
Now that all but one bug in LLD relating to PIE support have been
squashed (and a patch for that is already in code review), I'd like to
go ahead and force the use of PIE for Clang 3.9. When released, we'll
also switch over to using LLD exclusively.
llvm-svn: 265546
Summary:
Setting this flag causes all functions are annotated with the
"nvvm-f32ftz" = "true" attribute.
In addition, we annotate the module with "nvvm-reflect-ftz" set
to 0 or 1, depending on whether -cuda-flush-denormals-to-zero is set.
This is read by the NVVMReflect pass.
Reviewers: tra, rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18671
llvm-svn: 265435
Add no-jump-tables flag to disable use of jump tables when lowering
switch statements
Reviewers: echristo, hans
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18407
llvm-svn: 265425
The reproducer should use -I/-F/-resource-dir in the same way as the
original command. The VFS already collects the right headers but without
these flags the reproducer will fail to do the right thing.
llvm-svn: 265343
The cc1 invocation in the reproducer script should contain a valid path in
-fmodule-cache-path; for that reuse "<name>.cache/module" dir we already
use to dump the vfs and modules.
llvm-svn: 265162
Summary:
This prevents errors when you invoke clang with a flag that the NVPTX
toolchain doesn't support. For example, on x86-64,
clang -mthread-model single -x c++ /dev/null -o /dev/null
should output just one error about "invalid thread model 'single' in
'-mthread-model single' for this target"; x86-64 doesn't support
-mthread-model, but we shouldn't also instantiate a NVPTX target!
Reviewers: echristo
Subscribers: tra, sunfish, cfe-commits
Differential Revision: http://reviews.llvm.org/D18629
llvm-svn: 264965
Over the last month we've been testing SafeStack extensively. As far as
we know, it works perfectly fine. That why I'd like to see us having
this enabled by default for CloudABI.
This change introduces a getDefaultSanitizers() function that toolchains
can use to specify which sanitizers are enabled by default. Once all
flags are processed, only flags that had no -fno-sanitize overrides are
enabled.
Extend the thests for CloudABI to test both the default case and the
case in which we want to explicitly disable SafeStack.
Reviewed by: eugenis, pcc
Differential Revision: http://reviews.llvm.org/D18505
llvm-svn: 264787
Summary:
* -fcuda-target-overloads
Previously unconditionally set to true by the driver. Necessary for
correct functioning of the compiler -- our CUDA headers wrapper won't
compile without this.
* -fcuda-disable-target-call-checks
Previously unconditionally set to true by the driver. Necessary to
compile almost any external CUDA code -- almost all libraries assume
that host+device code can call host or device functions.
* -fcuda-allow-host-calls-from-host-device
No effect when target overloading is enabled.
Reviewers: tra
Subscribers: rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D18416
llvm-svn: 264739
Most things even work; see the included FIXMEs for things that need polishing.
Also don't warn about unused flags for the `/Yuh2.h /FIh1.h /FIh2.h`. The
common case is that the pch was built with `/Ych2.h /FIh1.h /FIh2.h`, so h1.h
is in the PCH, and we shouldn't warn about /FIh1.h not having an effect.
(If we wanted to get fancy, we could store the list of -include flags in the
pch and then check that it matches later on.)
llvm-svn: 264178
This reverts commit r263607.
This change caused more objc_retain/objc_release calls in the IR but those
are then incorrectly optimized by the ARC optimizer. Work is going to have
to be done to ensure the ARC optimizer doesn't optimize user written RR, but
that should land before this change.
This change will also need to be updated to take account for any changes required
to ensure that user written calls to RR are distinct from those inserted by ARC.
llvm-svn: 263984
Update the clang driver to allow -fsanitize=thread when targeting x86_64 iOS and tvOS
simulators. Also restrict TSan targeting OS X to only be supported on x86_64 and not i386.
Differential Revision: http://reviews.llvm.org/D18280
llvm-svn: 263913
Summary: LLVM_PREFIX could be undefined if CMAKE_INSTALL_PREFIX were set to empty.
Reviewers: kparzysz, bkramer, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17784
llvm-svn: 263766
It is faster to directly call the ObjC runtime for methods such as retain/release instead of sending a message to those functions.
This patch adds support for converting messages to retain/release/alloc/autorelease to their equivalent runtime calls.
Tests included for the positive case of applying this transformation, negative tests that we ensure we only convert "alloc" to objc_alloc, not "alloc2", and also a driver test to ensure we enable this only for supported runtime versions.
Reviewed by John McCall.
Differential Revision: http://reviews.llvm.org/D14737
llvm-svn: 263607
Summary: isTarget*() calls are order-dependent. This is because iOS Sim *is* iOS. This means checks for the simulator version of the platform must always be ahead of checks for the embedded platform.
Reviewers: zaks.anna, bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17947
llvm-svn: 263567
Also introduce -stdlib=platform to override the configured value
and use it to make the tests always pass.
Differential Revision: http://reviews.llvm.org/D17286
llvm-svn: 263434
This enables "--rtlib compiler-rt" option under MSVC environment.
Patch by Roman Shirokiy.
Differential Revision: http://reviews.llvm.org/D17453
llvm-svn: 263422
Summary:
This flag is enabled by default in the driver when NDEBUG is set. It
is forwarded on the LLVMContext to discard all value names (but
GlobalValue) for performance purpose.
This an improved version of D18024
Reviewers: echristo, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18127
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263394
This patch extends the -fuse-ld option to accept a full path to an executable
and use it verbatim to invoke the linker. There are generally two reasons
to desire this.
The first reason relates to the sad truth is that Clang is retargetable,
Binutils are not.
While any Clang from a binary distribution is sufficient to compile code
for a wide range of architectures and prefixed BFD linkers (e.g.
installed as /usr/bin/arm-none-linux-gnueabi-ld) as well as cross-compiled
libc's (for non-bare-metal targets) are widely available, including on all
Debian derivatives, it is impossible to use them together because
the -fuse-ld= option allows to specify neither a linker prefix nor
a full path to one.
The second reason is linker development, both when porting existing linkers
to new architectures and when working on a new linker such as LLD.
Differential Revision: http://reviews.llvm.org/D17952
llvm-svn: 262996
Now that pragma comment and pragma detect_mismatch are implemented, this might
just work.
Some pragmas aren't serialized yet (from the top of my head: code_seg, bss_seg,
data_seg, const_seg, init_seg, section, vtordisp), but these are as far as I
know usually pushed and popped within the header and usually don't leak out.
If it turns out the current PCH support isn't good enough yet, we can turn it
off again.
llvm-svn: 262749
Summary:
Using -no-integrated-as causes -mcpu=krait to be transformed into
-march=armv7-a today. This precludes the assembler from using
instructions like sdiv, which are present for krait. Cortex-a15 is the
closest subset of functionality for krait, so we should switch the
assembler to use that instead.
Reviewers: cfe-commits, apazos, weimingz
Subscribers: aemerson
Differential Revision: http://reviews.llvm.org/D17874
llvm-svn: 262742
This patch changes cc1 option for PGO profile use from
-fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>.
-fprofile-instr-use=<path> is now a driver only option.
In addition to decouple the cc1 option from the driver level option, this patch
also enables IR level profile use. cc1 option handling now reads the profile
header and sets CodeGenOpt ProfileUse (valid values are {None, Clang, LLVM}
-- this is a common enum for -fprofile-instrument={}, for the profile
instrumentation), and invoke the pipeline to enable the respective PGO use pass.
Reviewers: silvas, davidxl
Differential Revision: http://reviews.llvm.org/D17737
llvm-svn: 262515
In the gcc precompiled header model, one explicitly runs clang with `-x
c++-header` on a .h file to produce a gch file, and then includes the header
with `-include foo.h` and if a .gch file exists for that header it gets used.
This is documented at
http://clang.llvm.org/docs/UsersManual.html#precompiled-headers
cl.exe's model is fairly different, and controlled by the two flags /Yc and
/Yu. A pch file is generated as a side effect of a regular compilation when
/Ycheader.h is passed. While the compilation is running, the compiler keeps
track of #include lines in the main translation unit and writes everything up
to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells
the compiler to skip all code in the main TU up to and including `#include
"header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu
without an argument, in that case a `#pragma hrdstop` takes the role of
controlling the point where pch ends and real code begins.)
This patch implements limited support for this in that it requires the pch
header to be passed as a /FI force include flag – with this restriction,
it can be implemented almost completely in the driver with fairly small amounts
of code. For /Yu, this is trivial, and for /Yc a separate pch action is added
that runs before the actual compilation. After r261774, the first failing
command makes a compilation stop – this means if the pch fails to build the
main compilation won't run, which is what we want. However, in /fallback builds
we need to run the main compilation even if the pch build fails so that the
main compilation's fallback can run. To achieve this, add a ForceSuccessCommand
that pretends that the pch build always succeeded in /fallback builds (the main
compilation will then fail to open the pch and run the fallback cl.exe
invocation).
If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl
will now emit a "not implemented yet; flag ignored" warning that can be
disabled using -Wno-clang-cl-pch.
Since clang-cl doesn't yet serialize some important things (most notably
`pragma comment(lib, ...)`, this feature is disabled by default and only
enabled by an internal driver flag. Once it's more stable, this internal flag
will disappear.
(The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not
as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it
does. Implementing support for this should be possible with the approach in
this patch with minimal frontend changes by passing a --stop-at / --start-at
flag from the driver to the frontend. This is left for a follow-up. I don't
think we ever want to support `#pragma hdrstop`, and supporting it with this
approach isn't easy: This approach relies on the driver knowing the pch
filename in advance, and `#pragma hdrstop(out.pch)` can set the output
filename, so the driver can't know about it in advance.)
clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe
would put them, but the pch file format is of course incompatible. This has
ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in
/fallback builds.
http://reviews.llvm.org/D17695
llvm-svn: 262420
Summary:
This is the clang driver part of the change to embedded bitcode. This
includes:
1. -fembed-bitcode option which breaks down the compilation into two
stages. The first stage emits optimized bitcode and the second stage
compiles bitcode into object file.
2. -fembed-bitcode-marker option which doesn't really break down to
two stages to speedup the compilation flow.
3. pass the correct linker flag to darwin linker if tool chains supports
embedded bitcode.
Reviewers: rsmith, thakis
Subscribers: thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D17390
llvm-svn: 262282
Functions with an explicit exception specification have their behavior
dictated by the specification. The additional /EHc behavior only comes
into play if no exception specification is given.
llvm-svn: 262198
Summary:
(Re-land of r260448, which was reverted in r260522 due to a test failure
in Driver/output-file-cleanup.c that only showed up in fresh builds.)
Previously we attempted to be smart; if one job failed, we'd run all
jobs that didn't depend on the failing job.
Problem is, this doesn't work well for e.g. CUDA compilation without
-save-temps. In this case, the device-side and host-side Assemble
actions (which actually are responsible for preprocess, compile,
backend, and assemble, since we're not saving temps) are necessarily
distinct. So our clever heuristic doesn't help us, and we repeat every
error message once for host and once for each device arch.
The main effect of this change, other than fixing CUDA, is that if you
pass multiple cc files to one instance of clang and you get a compile
error, we'll stop when the first cc1 job fails.
Reviewers: echristo
Subscribers: cfe-commits, jhen, echristo, tra, rafael
Differential Revision: http://reviews.llvm.org/D17217
llvm-svn: 261774
This patch introduces the -fwhole-program-vtables flag, which enables the
whole-program vtable optimization feature (D16795) in Clang.
Differential Revision: http://reviews.llvm.org/D16821
llvm-svn: 261767
Also introduce inputs() that reutnrs an llvm::iterator_range.
Iterating over A->inputs() is much less mysterious than
iterating over *A. No intended behavior change.
llvm-svn: 261674
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.
This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.
llvm-svn: 261372
Our support for C++ EH is sufficiently good that it makes sense to
enable support for it out of the box.
While we are here, update the MSVCCompatibility doc.
llvm-svn: 261195
Summary:
I've got a patchset in my home directory to integrate support for
SafeStack into CloudABI's C library. All of the CloudABI unit tests
still seem to pass. Pretty sweet!
This change adds the necessary changes to Clang to make
-fsanitize=safe-stack work on CloudABI. Without it, passing this command
line flag throws an error.
Reviewers: eugenis, samsonov
Differential Revision: http://reviews.llvm.org/D17243
llvm-svn: 261135
ptxas optimizations are disabled if we need to generate debug info
as ptxas does not accept '-g' otherwise.
Differential Revision: http://reviews.llvm.org/D17111
llvm-svn: 261018
I'd accidentally skipped the CMake check in a premature optimisation. I'd also
put the original test in completely the wrong place.
Thanks Jonas Hahnfeld!
llvm-svn: 260898
C++ programs compiled for profiling (using `-pg`) should be linked with
`-lc++_p` (or `-lstdc++_p`, depending on the `-stdlib=` setting), not
with the regular C++ libraries.
Add a `FreeBSD::AddCXXStdlibLibArgs()` override to handle this, and add
a test case for it. While here, extend the test case for the proper
passing of -lm and -lm_p.
Reviewers: compnerd, davide, dws, emaste
Reviewed By: compnerd
Differential Revision: http://reviews.llvm.org/D16264
llvm-svn: 260851
With this option one can optionally override the architecture dependent
default library to use if no -stdlib= is provided on compiler invocation.
Differential Revision: http://reviews.llvm.org/D15920
llvm-svn: 260662
This allows ARMv8.2-A to be targeted either by using "armv8.2a" in the
triple, or by using -march=armv8.2-a (or the alias -march=armv8.2a).
The FP16 extension can be enabled with the "+fp16" suffix to the -march
or -mcpu option. This is consistent with the AArch64 option, rather than
the usual ARM option of -mfpu. We have agreed with the team which will
be upstreaming this to GCC that we want to use this new option format
for new architecture extensions for both ARM and AArch64.
Most of the work for this was done by the TargetParser patch in llvm.
Differential Revision: http://reviews.llvm.org/D15040
llvm-svn: 260533
Rafael Espindola