| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11105
llvm-svn: 241934
|
|
|
|
|
|
|
|
|
| |
All of the ABIs we support are altivec style anyhow and so the option
doesn't make much sense with the modern ABIs. We could make this a more
noisy ignore, but it would break builds for projects that just pass
it along by default because of historical reasons.
llvm-svn: 241925
|
|
|
|
|
|
|
|
|
|
| |
The function is massively large and GCC is emitting stack overflow
errors when building it (stack, as counted by the compiler, grows to
more than 16Kb).
The new flag processing logic added in r241825 took it over the limit.
llvm-svn: 241918
|
|
|
|
|
|
|
| |
In certain builds (msan), this can otherwise exceed the stack frame
limit set for certain environments.
llvm-svn: 241894
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for specifying where the profile is emitted in a
way similar to GCC. These flags are used to specify directories instead
of filenames. When -fprofile-generate=DIR is used, the compiler will
generate code to write to <DIR>/default.profraw.
The patch also adds a couple of extensions: LLVM_PROFILE_FILE can still be
used to override the directory and file name to use and -fprofile-use
accepts both directories and filenames.
To simplify the set of flags used in the backend, all the flags get
canonicalized to -fprofile-instr-{generate,use} when passed to the
backend. The decision to use a default name for the profile is done
in the driver.
llvm-svn: 241825
|
|
|
|
| |
llvm-svn: 241812
|
|
|
|
|
|
|
| |
Similarly to r231989, the driver arguments can be quite helpful in
diagnosing a crash.
llvm-svn: 241786
|
|
|
|
|
|
|
|
|
| |
There are known issues, but the current implementation is good enough for
the check-cfi test suite.
Differential Revision: http://reviews.llvm.org/D11030
llvm-svn: 241728
|
|
|
|
|
|
|
|
|
| |
Until somebody writes the code for it, be loud about the fact that
it's not implemented yet.
Differential Revision: http://reviews.llvm.org/D11020
llvm-svn: 241708
|
|
|
|
|
|
|
|
|
|
|
| |
For Mips direct-to-nacl, the goal is to be close to le32 front-end and
use Mips32EL backend. This patch defines new NaClMips32ELTargetInfo and
modifies it slightly to be close to le32. It also adds necessary parts,
inline with ARM and X86.
Differential Revision: http://reviews.llvm.org/D10739
llvm-svn: 241678
|
|
|
|
| |
llvm-svn: 241594
|
|
|
|
| |
llvm-svn: 241568
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"-arm-long-calls".
This change allows using -mlong-calls/-mno-long-calls for LTO and enabling or
disabling long call on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D9414
llvm-svn: 241565
|
|
|
|
|
|
| |
Add a test for ppc64(le), which wasn't handled before.
llvm-svn: 241528
|
|
|
|
|
|
| |
"-pthread" appends -lpthread after the object files list passed to the linker.
llvm-svn: 241485
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is the same except for the addition of a new test for the
issue that required reverting the dependent llvm commit.
--Original Commit Message--
Pass down the -flto option to the -cc1 job, and from there into the
CodeGenOptions and onto the PassManagerBuilder. This enables gating
the new EliminateAvailableExternally module pass on whether we are
preparing for LTO.
If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not
included as we want to preserve available externally functions for possible
link time inlining.
llvm-svn: 241467
|
|
|
|
| |
llvm-svn: 241432
|
|
|
|
|
|
|
|
|
|
|
| |
We had a strange relationship here where we made a list of Jobs
inherit from a single Job, but there weren't actually any places where
this arbitrary nesting was used or needed.
Simplify all of this by removing Job entirely and updating all of the
users to either work with a JobList or a single Command.
llvm-svn: 241310
|
|
|
|
| |
llvm-svn: 241309
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No more hardcoded paths: clang will use -sysroot as gcc root location if
provided. Otherwise, it will search for gcc on the path. If not found it
will use the driver installed location.
http://reviews.llvm.org/D5268
Patch by Ruben Van Boxem, Martell Malone, Yaron Keren.
Reviewed by Reid Kleckner.
llvm-svn: 241241
|
|
|
|
|
|
| |
Fixes the tests there.
llvm-svn: 241228
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows the user may invoke the linker directly, so we might not have an
opportunity to add runtime library flags to the linker command line. Instead,
instruct the code generator to embed linker directive in the object file
that cause the required runtime libraries to be linked.
We might also want to do something similar for ASan, but it seems to have
its own special complexities which may make this infeasible.
Differential Revision: http://reviews.llvm.org/D10862
llvm-svn: 241225
|
|
|
|
| |
llvm-svn: 241106
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main effect of this change is that /arch:IA32 will use i386 as the
CPU, while clang-cl will continue to default to pentium4 (aka SSE2 plus
the usual other features).
/arch:AVX and /arch:AVX2 will also now enable the other features
available in sandybridge and haswell respectively, which is consistent
with MSDN.
llvm-svn: 241077
|
|
|
|
| |
llvm-svn: 240984
|
|
|
|
|
|
|
|
|
| |
- Hexagon options were physically next to to ones that had a
preceding comment saying "Double dash options", which they aren't.
- The 'ld' tool classes are named Linker, not Link.
llvm-svn: 240980
|
|
|
|
|
|
| |
This fixes PR23963.
llvm-svn: 240902
|
|
|
|
|
|
|
|
| |
And generally prefer not to restate TargetTriple.str() over and over.
Differential Revision: http://reviews.llvm.org/D10605
llvm-svn: 240808
|
|
|
|
|
|
|
|
|
| |
Nothing was hand edited afterward except a few literal strings
and comments that were poorly broken.
Differential Revision: http://reviews.llvm.org/D10689
llvm-svn: 240791
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Namely, we must have proper C++ABI support in UBSan runtime. We don't
have a good way to check for that, so just assume that C++ABI support is
there whenever -fsanitize=vptr is supported (i.e. only on handful of
platforms).
Exact diagnostic is also tricky. It's not "cfi" that is unsupported,
just the diagnostic mode. So, I suggest to report that
"-fno-sanitize-trap=cfi-foobar" is incompatible with a given target
toolchain.
Test Plan: regression test suite
Reviewers: pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10751
llvm-svn: 240716
|
|
|
|
|
|
|
| |
To match the '-ccc-print-phases' command-line flag.
Also make two more 'for' loops range-based. NFC
llvm-svn: 240680
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10738
llvm-svn: 240674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the Clang part of the PPC64 memory sanitizer implementation in
D10648.
Reviewers: kcc, eugenis, willschm, wschmidt, samsonov
Reviewed By: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10650
llvm-svn: 240628
|
|
|
|
|
|
|
|
|
|
| |
This re-commits r226005 with a tweak. The origin attempt failed because
Darwin bot sets up SDKROOT and clang can deduce SDK version from them
after this patch. That broke many driver tests due to the change of
deployment target version. Now the tests should not complain after
r240574.
llvm-svn: 240619
|
|
|
|
|
|
|
| |
See https://llvm.org/bugs/show_bug.cgi?id=23539 for why this
is necessary.
llvm-svn: 240618
|
|
|
|
| |
llvm-svn: 240545
|
|
|
|
| |
llvm-svn: 240476
|
|
|
|
|
|
| |
This is consistent with all other classes in Tools.h.
llvm-svn: 240464
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Classes in Tools.h inherit ultimately from Tool, which is a noun,
but subclasses of Tool were named for their operation, such as "Compile",
wherein the constructor call "Compile(args...)" could be misconstrued
as actually causing a compile to happen.
Likewise various other methods were not harmonious with their effect,
in that "BuildLinker()" returned a "new namespace::Link(...)"
instead of a "new namespace::Linker(...)" which it now does.
Exceptions: Clang and ClangAs are un-renamed. Those are their rightful names.
And there is no particulary great way to name the "Lipo-er" and a few others.
Differential Revision: http://reviews.llvm.org/D10595
llvm-svn: 240455
|
|
|
|
| |
llvm-svn: 240432
|
|
|
|
|
|
| |
(Caused by r240370)
llvm-svn: 240376
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10612
llvm-svn: 240370
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
| |
by pointer) from ParseArgs
llvm-svn: 240349
|
|
|
|
| |
llvm-svn: 240328
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
| |
llvm-svn: 240237
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
triple.
Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support and are
not toolchain- or architecture-dependent.
Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.
This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539).
Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.
This change was first submitted as r239953 and reverted in r239958.
The problem was and still is in Darwin toolchains, which get the
knowledge about target platform too late after initializaition, while
now we require this information when ToolChain::getSanitizerArgs() is
called. r240170 works around this issue.
llvm-svn: 240179
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is unfortunate, but would let us land http://reviews.llvm.org/D10467,
that makes ToolChains responsible for computing the set of sanitizers
they support.
Unfortunately, Darwin ToolChains doesn't know about actual OS they
target until ToolChain::TranslateArgs() is called. In particular, it
means we won't be able to construct SanitizerArgs for these ToolChains
before that.
This change removes SanitizerArgs::needsLTO() method, so that now
ToolChain::IsUsingLTO(), which is called very early, doesn't need
SanitizerArgs to implement this method.
Docs and test cases are updated accordingly. See
https://llvm.org/bugs/show_bug.cgi?id=23539, which describes why we
start all these.
Test Plan: regression test suite
Reviewers: pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10560
llvm-svn: 240170
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change passes through C and assembler jobs to Movidius tools by
constructing commands which are the same as ones produces by the examples
in the SDK. But rather than reference MV_TOOLS_DIR to find tools,
we will assume that binaries are installed wherever the Driver would
find its native tools. Similarly, this change assumes that -I options
will "just work" based on where SDK headers get installed, rather than
baking into the Driver some magic paths.
Differential Revision: http://reviews.llvm.org/D10440
llvm-svn: 240134
|