| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
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: 239481
|
| |
|
|
|
|
|
|
|
| |
This matches the cl.exe behavior (tested with 18.00.31101). In order to
specify an output file for /P, use the /Fi option instead.
Differential Revision: http://reviews.llvm.org/D10313
llvm-svn: 239393
|
| |
|
|
|
|
|
|
| |
The object file format is sometimes overridden for MSVC targets to use
ELF instead of COFF. Make sure we preserve this choice when setting the
msvc version number in the triple.
llvm-svn: 239388
|
| |
|
|
|
|
|
| |
We already have Args->filtered(...) which is a drop-in range-for
replacement.
llvm-svn: 239381
|
| |
|
|
|
|
|
| |
Encoding the version into the triple will allow us to communicate to
LLVM what functions it can expect to depend upon in the implementation.
llvm-svn: 239273
|
| |
|
|
|
|
|
|
| |
No documentation yet; the linker needs more work.
Differential Revision: http://reviews.llvm.org/D10270
llvm-svn: 239213
|
| |
|
|
|
|
|
|
|
|
|
| |
Adds tests verifying the proper dirs are found in the Debian 8/GCC4.9
layout for sparc (32bit), sparc (32bit) with lib64 multilib, and
sparc64.
The test cases added here also cover r239047, which fixed the linker
paths.
llvm-svn: 239154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main effect of this is to fix anomalies where certain -mfpu options didn't
disable everything that they should causing strange behaviour when combined
with -mcpu or -march values that themselves enabled fpu subtarget features,
e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as
-mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled.
Invalid -mfpu options now also give an error, which is consistent with the
handling of the .fpu directive.
Differential Revision: http://reviews.llvm.org/D10239
llvm-svn: 239152
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
following r239099
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10256
llvm-svn: 239101
|
| |
|
|
|
|
|
| |
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option.
llvm-svn: 239059
|
| |
|
|
| |
llvm-svn: 239047
|
| |
|
|
| |
llvm-svn: 239038
|
| |
|
|
| |
llvm-svn: 239028
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10224
llvm-svn: 238992
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10223
llvm-svn: 238955
|
| |
|
|
| |
llvm-svn: 238938
|
| |
|
|
|
|
|
|
| |
This reverts commit r238851.
It depends on a llvm commit that was reverted.
llvm-svn: 238904
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first try to land this (r238055) was reverted due to bot failures
caused by the LLVM part of the patch. That was hopefully fixed by r238788,
and the LLVM patch was resubmitted at r238842.
This is the front-end counterpart to D8982.
The -mrecip option interface is based on maintaining compatibility with gcc:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#index-mrecip_003dopt-1627
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/RS_002f6000-and-PowerPC-Options.html#index-mrecip-2289
...while adding more functionality (allowing users to specify the number of refinement steps for each
estimate type).
Differential Revision: http://reviews.llvm.org/D8989
llvm-svn: 238851
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
llvm-svn: 238601
|
| |
|
|
|
|
|
|
|
|
| |
getCanonicalArchName can return an empty string for an architecture
that is well-formed but meaningless. Use parseArch to determine if
it's actually valid or not.
Differential Revision: http://reviews.llvm.org/D10120
llvm-svn: 238553
|
| |
|
|
|
|
| |
Justin pointed out in post-commit review.
llvm-svn: 238498
|
| |
|
|
| |
llvm-svn: 238435
|
| |
|
|
| |
llvm-svn: 238430
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't an actual revert of r237769, it just restores the behavior of
the Clang driver prior to it while completely re-implementing how that
behavior works.
This also re-does the work of making the default OpenMP runtime
selectable at CMake (or configure) time to work in the way all of our
other such hooks do (config.h, configure and cmake hooks, etc.).
I've re-implemented how we manage the '-fopenmp' flagset in an important
way. Now, the "default" hook just makes '-fopenmp' equivalent to
'-fopenmp=<default>' rather than a separate special beast. Also, there
is an '-fno-openmp' flag which does the obvious thing. Also, the code is
shared between all the places to select a known OpenMP runtime and act
on it.
Finally, and most significantly, I've taught the driver to inspect the
selected runtime when choosing whether to propagate the '-fopenmp' flag
to the frontend in the CC1 commandline. Without this, it isn't possible
to use Clang with libgomp, even if you were happy with the serial,
boring way in which it worked previously (ignoring all #pragmas but
linking in the library to satisfy direct calls into the runtime).
While I'm here, I've gone ahead and sketched out a path for the future
name of LLVM's OpenMP runtime (libomp) and the legacy support for its
current name (libiomp5) in what seems a more reasonable way.
To re-enable LLVM's OpenMP runtime (which I think should wait until the
normal getting started instructions are a reasonable way for falks to
check out, build, and install Clang with the runtime) all that needs to
change is the default string in the CMakeLists.txt and configure.ac
file. No code changes necessary.
I also added a test for the driver's behavior around OpenMP since it was
*completely missing* previously. Makes it unsurprising that we got it
wrong.
llvm-svn: 238389
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9939
llvm-svn: 238225
|
| |
|
|
|
|
|
|
| |
AddHexagonTargetArgs didn't respect the driver flags by unconditionally
pushing -fno-signed-char. Instead, add Hexagon handling to
isSignedCharDefault.
llvm-svn: 238106
|
| |
|
|
|
|
|
| |
GCC maps -fno-unsigned-char to -fsigned-char and -fno-signed-char to
-funsigned-char.
llvm-svn: 238105
|
| |
|
|
|
|
| |
They depend on a reverted llvm commit.
llvm-svn: 238076
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the front-end counterpart to D8982 (LLVM r238051).
The -mrecip option interface is based on maintaining compatibility with gcc:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#index-mrecip_003dopt-1627
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/RS_002f6000-and-PowerPC-Options.html#index-mrecip-2289
...while adding more functionality (allowing users to specify the number of refinement steps for each
estimate type).
Differential Revision: http://reviews.llvm.org/D8989
llvm-svn: 238055
|
| |
|
|
|
|
|
|
|
|
| |
Using non unique names found a bug in the ICF inplementation in gold:
https://sourceware.org/bugzilla/show_bug.cgi?id=18440
This reverts commit r234143.
llvm-svn: 238048
|
| |
|
|
|
|
|
| |
Now that ARMTargetParser can parse profile and version numbers,
use them instead of the local implementation.
llvm-svn: 238037
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the target cpu to determine some behaviour is sprinkled in
several places in the driver, but in almost all the information that
is needed can be found in the triple. Restructure things so that the
triple is used, and the cpu is only used if the exact cpu name is
needed.
Also add a check that the -mcpu argument is valid, and correct the
-march argument checking so that it handles -march=native correctly. I
would have liked to move these checks into the computation of the
triple, but the triple is calculated several times in several places
and that would lead to multiple error messages for the same thing.
Differential Revision: http://reviews.llvm.org/D9879
llvm-svn: 237894
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't print unused-argument warning for sanitizer-specific feature flag
if this sanitizer was eanbled, and later disabled in the command line.
For example, now:
clang -fsanitize=address -fsanitize-coverage=bb -fno-sanitize=address a.cc
doesn't print warning, but
clang -fsanitize-coverage=bb
does. Same holds for -fsanitize-address-field-padding= and
-fsanitize-memory-track-origins= flags.
Fixes PR23604.
llvm-svn: 237870
|
| |
|
|
|
|
|
|
|
| |
configurable in the CMake build. There shouldn't be any change in default
behavior.
Derived from a patch by Daniel Jasper!
llvm-svn: 237850
|
| |
|
|
|
|
|
| |
-fopenmp turns on OpenMP support and links libiomp5 as OpenMP library. Also there is -fopenmp={libiomp5|libgomp} option that allows to override effect of -fopenmp and link libgomp library (if -fopenmp=libgomp is specified).
Differential Revision: http://reviews.llvm.org/D9736
llvm-svn: 237769
|
| |
|
|
| |
llvm-svn: 237553
|
| |
|
|
| |
llvm-svn: 237374
|
| |
|
|
|
|
| |
This patch factors out SmallDataThreshold code.
llvm-svn: 237364
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for ARMv8.1a architecture.
Briefly it is described on http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development
Reviewers: jmolloy, rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8799
llvm-svn: 237349
|
| |
|
|
|
|
|
|
|
| |
sys/time.h on Solaris (and possibly other systems) defines "SEC" as "1"
using a cpp macro. The result is that this fails to compile.
Fixes https://llvm.org/PR23482
llvm-svn: 237113
|
| |
|
|
|
|
|
|
|
|
| |
The MachO toolchain has an isTargetIOSBased method, but it isn't
virtual so it isn't very meaningful to call it. After thinking about
this, I guess that putting this logic in the MachO class is a bit of a
layering violation anyway. Do this more like how we handle
AddLinkRuntimeLibArgs instead.
llvm-svn: 237095
|
| |
|
|
|
|
|
|
| |
This time without a stray "true" in an argument list.
This reverts r237077, restoring r237074.
llvm-svn: 237091
|
| |
|
|
|
|
| |
This revert r237074. These tests are failing all over the place.
llvm-svn: 237077
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Compiler-rt's Profiling library isn't part of the stdlib, so -nostdlib
shouldn't prevent it from being linked. This makes Darwin behave like
other toolchains, and link in the profile runtime irrespective of
-nostdlib, since the resulting program can't be run unless you link
this.
I've also added a test to show that other toolchains already behave
like this.
llvm-svn: 237074
|
| |
|
|
|
|
|
|
| |
No functional change.
Differential Revision: http://reviews.llvm.org/D9621
llvm-svn: 237056
|
| |
|
|
|
|
|
|
|
|
| |
compiler.
No functional change.
Differential Revision: http://reviews.llvm.org/D9618
llvm-svn: 237055
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D8784
llvm-svn: 237001
|
| |
|
|
|
|
|
| |
This patch factor out the code in hexagon::Link::ConstructJob to be reused
in other functions. No functionality change intended.
llvm-svn: 236926
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a starting point for using the TargetParser in Clang, in a simple
enough part of the code that can be used without disrupting the crazy
platform support that we need to be compatible with other toolchains.
Also adding a few FIXME on obvious places that need replacing, but those
cases will indeed break a few of the platform assumptions, as arch/cpu names
change multiple times in the driver.
Finally, I'm changing the "neon-vfpv3" behaviour to match standard NEON, since
-mfpu=neon implies vfpv3 by default in both Clang and LLVM. That option
string is still supported as an alias to "neon".
llvm-svn: 236901
|
| |
|
|
|
|
|
| |
This reverts commit r236859, as it broke multiple builds. I'll investigate
and reapply when safe.
llvm-svn: 236869
|