| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
No one callback uses target triple so we can escape passing the unused
argument.
llvm-svn: 270068
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 269989
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
MIPS32 Android defaults to FPXX ("-fpxx").
MIPS32R6 Android defaults to FP64A ("-mfp64 -mno-odd-spreg").
Differential Revision: http://reviews.llvm.org/D20345
llvm-svn: 269914
|
| |
|
|
|
|
|
|
|
| |
/Gr), by Alexander Makarov
Patch for bug #27711
Differential Revision: http://reviews.llvm.org/D20171
llvm-svn: 269891
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Change default CPU for MIPS32 Android. Now it is mips32 (rev1).
Differential Revision: http://reviews.llvm.org/D20313
llvm-svn: 269754
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
We may consider msvc features may be capable on mingw host, if it can.
Consider --host=mingw --target=msvc.
llvm-svn: 269557
|
| |
|
|
|
|
| |
std::string, to appease mingw-g++.
llvm-svn: 269556
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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
|
| |
|
|
| |
llvm-svn: 269412
|
| |
|
|
|
|
| |
This should affect only the mips-mti-linux toolchain.
llvm-svn: 269411
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 269279
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 268956
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
now use the full GCC version in their weird suffix.
llvm-svn: 268874
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 268540
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
I have updated the compiler-rt tests.
llvm-svn: 267903
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Move phase handling after input type validation.
llvm-svn: 267040
|
| |
|
|
|
|
|
|
|
|
|
| |
Add -miamcu option which:
* Sets IAMCU triple
* Sets IAMCU ABI
* Enforces static compilation
Differential Revision: http://reviews.llvm.org/D18398
llvm-svn: 266972
|
| |
|
|
| |
llvm-svn: 266797
|
| |
|
|
|
|
| |
Fix PR26999 - crashing in cc1as with any '*bsd' target.
llvm-svn: 266775
|
| |
|
|
|
|
| |
buildbots.
llvm-svn: 266753
|
| |
|
|
|
|
|
|
|
|
|
| |
Add -miamcu option which:
* Sets IAMCU triple
* Sets IAMCU ABI
* Enforces static compilation
Differential Revision: http://reviews.llvm.org/D18398
llvm-svn: 266747
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: tra
Subscribers: cfe-commits, jhen
Differential Revision: http://reviews.llvm.org/D19251
llvm-svn: 266708
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--cuda-device-only.
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
|
| |
|
|
|
|
| |
driver thinks they are unused
llvm-svn: 266673
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
There might be flags passed to the linker (e.g. /libpath), causing it
to search in paths the Clang driver doesn't know about.
PR27234
llvm-svn: 266402
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18748
llvm-svn: 266133
|