Currently clang requires several additional command
line options in order to enable new features needed
during CUDA compilation. This patch makes these
options default.
* Automatically include cuda_runtime.h if we've found
a valid CUDA installation.
* Disable automatic CUDA header inclusion during unit tests.
* Added test case for command line construction.
* Enabled target overloads and relaxed call checks that are
needed in order to include CUDA headers.
* Added CUDA-7.5 installation path to the CUDA installation search list.
* Define __CUDA__ macro to indicate CUDA compilation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253389 91177308-0d34-0410-b5e6-96231b3b80d8
In order to compile a CUDA file clang must be able to find
include files for both both host and device.
This patch passes AuxToolchain to AddPreprocessingOptions and
uses it to add include paths for the opposite side of compilation.
We also must be able to find CUDA include files. If the driver
found CUDA installation, it adds appropriate include path
to CUDA headers. This can be disabled with '-nocudainc'.
- Added include paths for the opposite side of compilation.
- Added include paths to detected CUDA installation.
- Added -nocudainc to prevent adding CUDA include path.
- Added test cases to verify new functionality.
Differential Revision: http://reviews.llvm.org/D13170
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253386 91177308-0d34-0410-b5e6-96231b3b80d8
Clang needs to know target triple for both sides of compilation so that
preprocessor macros and target builtins from both sides are available.
This change augments Compilation class to carry information about
toolchains used during different CUDA compilation passes and refactors
BuildActions to use it when it constructs CUDA jobs.
Removed DeviceTriple from CudaHostAction/CudaDeviceAction as it's no
longer needed.
Differential Revision: http://reviews.llvm.org/D13144
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253385 91177308-0d34-0410-b5e6-96231b3b80d8
Last time, this caused two Windows buildbots and a single ARM buildbot to fail.
I XFAIL'd the failing test on win32,win64 machines in order to see if the ARM
buildbot complains again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252901 91177308-0d34-0410-b5e6-96231b3b80d8
This currently changes the default toward the more historic -Av8/-Av9,
but as discussed with James Y Knight, consistency is for now more
important than figuring out which default CPU each OS should be using.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252571 91177308-0d34-0410-b5e6-96231b3b80d8
is not defined for 32bit mode, but __sparcv9 is. Pass down the correct
-target-cpu flags to the backend, so that instruction restrictions are
applied correctly. Pass down the correct -A flag when not using IAS.
The latter is limited to NetBSD targets in this commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252545 91177308-0d34-0410-b5e6-96231b3b80d8
The -meabi flag to control LLVM EABI version.
Without '-meabi' or with '-meabi default' imply LLVM triple default.
With '-meabi gnu' sets EABI GNU.
With '-meabi 4' or '-meabi 5' set EABI version 4 and 5 respectively.
A similar patch was introduced in LLVM.
Patch by Vinicius Tinti.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252463 91177308-0d34-0410-b5e6-96231b3b80d8
This sets the mostly expected Darwin default ABI options for these two
platforms. Active changes from these defaults for watchOS are in a later patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251708 91177308-0d34-0410-b5e6-96231b3b80d8
This patch should add support for almost all command-line options and
driver tinkering necessary to produce a correct "clang -cc1"
invocation for watchOS and tvOS.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251706 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commits r251633. I'll investigate the test failure off trunk in
order to keep the buildbots clean.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251698 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r251695. Debug is meant to be done off tree, not use the buildbots
experiments. I'll help investigate this problem off trunk.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251696 91177308-0d34-0410-b5e6-96231b3b80d8
This should be a NFC for every toolchain other than mips-mti-linux (where we
print the list of directories searched for crt files). It will soon be
reverted once we hit the clang-cmake-armv7-a15-selfhost-neon buildbot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251695 91177308-0d34-0410-b5e6-96231b3b80d8
The original commit in r249137 added the mips-mti-linux toolchain. However,
the newly added tests of that commit failed in few buildbots. This commit
re-applies the original changes but XFAILs the test file which caused
the buildbot failures. This will allow us to examine what's going wrong
without having to commit/revert large changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251633 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This is a follow on to post review comments on revision r248276.
Patch by Scott Egerton.
Reviewers: vkalintiris, dsanders
Subscribers: joerg, rengolin, cfe-commits
Differential Revision: http://reviews.llvm.org/D13100
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251430 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251041 91177308-0d34-0410-b5e6-96231b3b80d8
In this patch, the file static method addProfileRT is
moved to be a virtual member function of base ToolChain class.
This allows derived toolchain to override the default behavior
easily and make it consistent with Darwin toolchain (a TODO was
added for this refactoring - now removed). A new helper method
is also introduced to test if instrumentation profile option
is turned on or not.
Differential Revision: http://reviews.llvm.org/D13326
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250994 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Similar to rL248426 (which was a followup to rL248379 and rL248424), add the
required libraries for OpenMP on the linker command line, and update the test
case.
Reviewers: emaste, theraven, joerg
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13822
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250657 91177308-0d34-0410-b5e6-96231b3b80d8
This recommits r250398 with fixes to the tests for bot failures.
Add "-target x86_64-unknown-linux" to the clang invocations that
check for the gold plugin.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250455 91177308-0d34-0410-b5e6-96231b3b80d8
Rolling this back for now since there are a couple of bot failures on
the new tests I added, and I won't have a chance to look at them in detail
until later this afternoon. I think the new tests need some restrictions on
having the gold plugin available.
This reverts commit r250398.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250402 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add clang support for -flto=thin option, which is used to set the
EmitFunctionSummary code gen option on compiles.
Add -flto=full as an alias to the existing -flto.
Add tests to check for proper overriding of -flto variants on the
command line, and convert grep tests to FileCheck.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, cfe-commits
Differential Revision: http://reviews.llvm.org/D11908
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250398 91177308-0d34-0410-b5e6-96231b3b80d8
There was a minor problem with a test. Sorry for the noise yesterday.
This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250293 91177308-0d34-0410-b5e6-96231b3b80d8
Resubmitting the patch.
This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250262 91177308-0d34-0410-b5e6-96231b3b80d8
This removes the default of 3 hidden in the assembler previously.
Fixes breakage caused by r249655, reported by vsukharev.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250173 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for the `-fdebug-prefix-map=` option as in GCC. The syntax is
`-fdebug-prefix-map=OLD=NEW`. When compiling files from a path beginning with
OLD, change the debug info to indicate the path as start with NEW. This is
particularly helpful if you are preprocessing in one path and compiling in
another (e.g. for a build cluster with distcc).
Note that the linearity of the implementation is not as terrible as it may seem.
This is normally done once per file with an expectation that the map will be
small (1-2) entries, making this roughly linear in the number of input paths.
Addresses PR24619.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250094 91177308-0d34-0410-b5e6-96231b3b80d8
C++ exceptions are still off by default, which is similar to how C++
cleanups are off by default in MSVC.
If you use clang instead of clang-cl, exceptions are also still off by
default. In the future, when C++ EH is proven to be stable, we may flip
the default for that driver to be consistent with other platforms.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249704 91177308-0d34-0410-b5e6-96231b3b80d8
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249655 91177308-0d34-0410-b5e6-96231b3b80d8
There are still some loose ends here but it's sufficient so we can detect
GCC headers that are inside of a VFS.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249556 91177308-0d34-0410-b5e6-96231b3b80d8
There are two remaining buildbot failures that we'll have to
investigate before submitting this again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249298 91177308-0d34-0410-b5e6-96231b3b80d8
r249137 added support for the new mips-mti-linux toolchain. However,
the new tests of that commit, broke some buildbots because they didn't use
the correct regular expressions to capture the filename of Clang & LLD.
This commit re-applies the changes of r249137 and fixes the tests in
r249137 in order to match the filenames of the Clang and LLD executable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249294 91177308-0d34-0410-b5e6-96231b3b80d8
In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes. It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure). There is a
desire to support __declspec in Playstation code, and possibly other
environments. This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword. Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.
Patch by Warren Ristow!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249279 91177308-0d34-0410-b5e6-96231b3b80d8
The Windows on ARM ABI recommends that FPO be disabled. This is since the
Windows on ARM ABI uses the FP for fast stack walking. By paying the slight
cost of the loss of registers, a much faster backtrace is possible by using the
frame pointer since the pdata need not be consulted. Furthermore, even if pdata
is not available, you can still more easily reconstruct the stack.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249227 91177308-0d34-0410-b5e6-96231b3b80d8
Reapply r248935.
Usually, when using LTO with a clang installation newer than the
system's one, there's a libLTO.dylib version mismatch and LTO fails. One
solution to this is to make ld point to the right libLTO.dylib by
changing DYLD_LIBRARY_PATH.
However, ld64 supports specifying the complete path to the desired
libLTO.dylib through the -lto_library option. This commit adds support
for the clang driver to use this option whenever it's capable of finding
a libLTO.dylib in clang's installed library directory. This way, we
don't need to rely on DYLD_LIBRARY_PATH nor get caught by version
mismatches.
Differential Revision: http://reviews.llvm.org/D13117
rdar://problem/7363476
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249143 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This new toolchain uses primarily LLVM-based tools, eg. compiler-rt, lld,
libcxx, etc. Because of this, it doesn't require neither an existing GCC
installation nor a GNU environment. Ideally, in a follow-up patch we
would like to add a new --{llvm|clang}-toolchain option (similar to
--gcc-toolchain) in order to allow the use of this toolchain with
independent Clang builds. For the time being, we use the --sysroot
option just to test the correctness of the paths generated by the
driver.
Reviewers: atanasyan, dsanders, rsmith
Subscribers: jfb, tberghammer, danalbert, srhines, dschuff, cfe-commits
Differential Revision: http://reviews.llvm.org/D13340
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249137 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch moves getCompilerRT() from the clang::driver::tools namespace to
the ToolChain class. This is needed for multilib toolchains that need to
place their libraries in Clang's resource directory with a layout that is
different from the default one.
Reviewers: atanasyan, rsmith
Subscribers: tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D13339
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249030 91177308-0d34-0410-b5e6-96231b3b80d8
Usually, when using LTO with a clang installation newer than the
system's one, there's a libLTO.dylib version mismatch and LTO fails. One
solution to this is to make ld point to the right libLTO.dylib by
changing DYLD_LIBRARY_PATH.
However, ld64 supports specifying the complete path to the desired
libLTO.dylib through the -lto_library option. This commit adds support
for the clang driver to use this option whenever it's capable of finding
a libLTO.dylib in clang's installed library directory. This way, we
don't need to rely on DYLD_LIBRARY_PATH nor get caught by version
mismatches.
Differential Revision: http://reviews.llvm.org/D13117
rdar://problem/7363476
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248932 91177308-0d34-0410-b5e6-96231b3b80d8
* assembling from a .s file mistook -ggdb0 for -g
* -ggdb1 is supposed to mean basically -g1, not -gN for N>1
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248912 91177308-0d34-0410-b5e6-96231b3b80d8
ARM EABI adds target attributes to the object file. Amongst the attributes that
are emitted is the VFP argument passing (Hard vs Soft). The linker is
responsible for checking these attributes and erroring on mismatches. This
causes problems for the compiler-rt builtins when targeting both hard and
soft. Because both of these options name the builtins compiler-rt component
the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC
is able to get away with this as it does one target per toolchain. This
changes the naming convention for the ARM compiler-rt builtins to differentiate
between HF and Soft. Although this means that compiler-rt may be duplicated, it
enables supporting both variants from a single toolchain. A similar approach is
taken by the Darwin toolchain, naming the library to differentiate between the
calling conventions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248649 91177308-0d34-0410-b5e6-96231b3b80d8
StringRefs always point to immutable memory so the const doesn't add value
here. Also quiets clang's -Wrange-loop-analysis which warns about the implicit
copying.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248496 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Strictly speaking, the MIPS*R2 ISA's should not permit -mnan=2008 since this
feature was added in MIPS*R3. However, other toolchains permit this and we
should do the same.
Reviewers: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13057
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248481 91177308-0d34-0410-b5e6-96231b3b80d8
This translates to -load name.so in the cc1 command. We can't name the driver
option -load, as that means "link against oad", so instead we follow GCC's lead
and name the option -fplugin.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248378 91177308-0d34-0410-b5e6-96231b3b80d8
This changes getARMFloatABI to use the ToolChain and Args instead of Driver,
Args, Triple. Although this pushes the Triple calculation/parsing into the
function itself, it enables the use of the function for a future change. The
reason to sink the triple calculation here is to avoid threading the Triple
through multiple layers in a future change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248095 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than using re-calculating the effective triple, thread the already
calculated value down into AddARMTargetArgs. This avoids both recreating the
triple, as well as re-parsing the triple as it was already done in the previous
frame.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248094 91177308-0d34-0410-b5e6-96231b3b80d8
Use an enumeration for the Floating Point ABIs supported on MIPS. This is
replicating the ARM change to avoid string based tracking of the floating point
ABI. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248083 91177308-0d34-0410-b5e6-96231b3b80d8
Use an enumeration and change the use of the FloatABI from a string to the
enumeration. This avoids the use of string values to represent an enumeration.
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247967 91177308-0d34-0410-b5e6-96231b3b80d8
There is no __cxa_finalize symbol available on recent Solaris OS
versions, so we need this flag to make non trivial C++ programs run.
Also stop looking for cxa_finalize.o, since it won't be there.
Patch by Xan López!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247634 91177308-0d34-0410-b5e6-96231b3b80d8
This is actually needed, otherwise libc won't be added at all. For
instance when building libclang.so all the libc symbols won't be
found, with ld warning about libc being an "implicit dependency".
Patch by Xan López!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247603 91177308-0d34-0410-b5e6-96231b3b80d8
-force-align-stack.
Also, make changes to the driver so that -mno-stack-realign is no longer
an option exposed to the end-user that disallows stack realignment in
the backend.
Differential Revision: http://reviews.llvm.org/D11815
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247451 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
With Visual Studio 2015 release, a part of runtime library was extracted
and now comes with Windows Kits. This patch enables clang to use
Universal CRT library if %INCLUDE or %LIB environment varaibles are not
specified.
See also https://llvm.org/bugs/show_bug.cgi?id=24741
Patch by Igor Kudrin
Reviewers: zturner, hans, rnk
Subscribers: ruiu, cfe-commits
Differential Revision: http://reviews.llvm.org/D12695
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247362 91177308-0d34-0410-b5e6-96231b3b80d8
If target supports TLS all threadprivates are generated as TLS. If target does not support TLS, use runtime calls for proper codegen of threadprivate variables.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247273 91177308-0d34-0410-b5e6-96231b3b80d8
This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.
Differential Revision: http://reviews.llvm.org/D12002
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246814 91177308-0d34-0410-b5e6-96231b3b80d8
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246764 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
[ARM] Allow passing/returning of __fp16 arguments
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246760 91177308-0d34-0410-b5e6-96231b3b80d8
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246755 91177308-0d34-0410-b5e6-96231b3b80d8
This patch refactors the code to use the GCC installation detector
(modified so that it works in Solaris), and uses
ToolChain::GetFilePath everywhere once it works.
Patch by Xan López <xan@igalia.com>!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246473 91177308-0d34-0410-b5e6-96231b3b80d8
const char pointers. In turn, push this through Clang APIs as well,
simplifying a number of bits of code that was handling the oddities of
nullptrs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246375 91177308-0d34-0410-b5e6-96231b3b80d8
to enable the use of external type references in the debug info
(a.k.a. module debugging).
The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs"
and passes that to cc1. All this does at the moment is set a flag
codegenopts.
http://reviews.llvm.org/D11958
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246192 91177308-0d34-0410-b5e6-96231b3b80d8
Error out if -mfloat-abi=hard or -mhard-float is specified on the command
line and the target ABI is APCS. Previously clang issued no warnings or
errors and just passed the option to the backend, which had no effect on
code generation for targets using APCS.
This commit corrects the patch commited in r245866, which didn't take into
account the fact that not all darwin targets use APCS.
rdar://problem/22257950
http://reviews.llvm.org/D12344
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246054 91177308-0d34-0410-b5e6-96231b3b80d8
Error out if the user tries to use float-abi="hard" since it isn't
supported on darwin platforms. Previously clang issued no warnings or
erros and just passed the option to the backend, which had no effect on
code generation for targets using apcs.
rdar://problem/22257950
Differential Revision: http://reviews.llvm.org/D12155
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245866 91177308-0d34-0410-b5e6-96231b3b80d8
For some reason, clang had been treating a command like:
clang -static -fPIC foo.c
as if it should be compiled without the PIC relocation model.
This was incorrect: -static should be affecting only the linking
model, and -fPIC only the compilation.
This new behavior also matches GCC.
This is a follow-up from a review comment on r245447.
Differential Revision: http://reviews.llvm.org/D12208
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245667 91177308-0d34-0410-b5e6-96231b3b80d8
doing assembly-only, and unify the Driver's PIC argument parsing.
On a few architectures, parsing of assembly files annoyingly depends
on whether PIC is enabled or not. This was handled for external 'as'
already (passing -KPIC), but was missed for calls to the standalone
internal assembler.
The integrated-as.s test needed to be modified to not expect
-fsanitize=address to be unused, as now fsanitize *IS* used for
assembly, since -fsanitize=memory can sometimes imply -fPIE, which the
assembler needs to know (gack!!).
Differential Revision: http://reviews.llvm.org/D11845
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245447 91177308-0d34-0410-b5e6-96231b3b80d8
"generic" cpu was wrongly handled as exact real CPU name of ARMv8.1A architecture.
This has been fixed, now it is abstract name, suitable for any arch.
Reviewers: rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11640
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245445 91177308-0d34-0410-b5e6-96231b3b80d8
This is needed to prevent breakage of -Wl,-as-needed link when
interceptors for functions in libutil are added. See PR15823.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245344 91177308-0d34-0410-b5e6-96231b3b80d8
-mkernel enables -fno-builtin and -fno-common by default, but allows -fbuiltin
and -fcommon to override that. However "-fbuiltin -fno-builtin" is treated the
same as "-fbuiltin" which is wrong, so fix that. Also fixes similar behaviour
when -fno-common is default.
Differential Revision: http://reviews.llvm.org/D11459
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244437 91177308-0d34-0410-b5e6-96231b3b80d8
Implemented in MinGW::Linker::AddLibGCC since AddLibgcc is a logic puzzle even
before adding one more boolean. A first step towards simplification of AddLibgcc
would be to factor out the Android AddLibgcc code into its own routine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244407 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds flags -fno-profile-instr-generate and
-fno-profile-instr-use, and the GCC aliases -fno-profile-generate and
-fno-profile-use.
These flags are used in situations where users need to disable profile
generation or use for specific files in a build, without affecting other
files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244153 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can
force emission of one or both by passing -gcodeview and -gdwarf to
either driver.
Reviewers: dblaikie, hans
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11742
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244097 91177308-0d34-0410-b5e6-96231b3b80d8
This seems preferable to printing two warnings per unsupported option-
one warning about not supporting it, and one about not using it.
It also makes the '-Wno-' option do what you mean.
Differential Revision: http://reviews.llvm.org/D11766
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244079 91177308-0d34-0410-b5e6-96231b3b80d8
It doesn't make any sense to enable -gmlt with -gsplit-dwarf, since
-gmlt is designed for on-line symbolication (and -gsplit-dwarf normally
emits all the -gmlt data into the .o anyway - so there's nothing to
split out except redundant/duplicate info).
With this change they override each other, -gmlt -gsplit-dwarf is the
same as -gsplit-dwarf and -gsplit-dwarf -gmlt is the same as -gmlt.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243694 91177308-0d34-0410-b5e6-96231b3b80d8
Copying the already existing code for x86 to ARM to set the correct CPU
features when using -mcpu=native. We can already detect the CPU name
but we were not setting the correct feature bits.
Moving fpu/hwdiv down to make sure they override whatever we set the
default to be.
No tests because this is native detection, and not all ARM-enabled builds
will hapen at a specific CPU, or even ARM. I have tested locally and it
works as expected.
Fixes PR12794.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243656 91177308-0d34-0410-b5e6-96231b3b80d8
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243642 91177308-0d34-0410-b5e6-96231b3b80d8
This commit changes the driver to save subtarget feature "+strict-align"
to the IR instead of using backend option "aarch64-strict-align". This is
needed for LTO.
rdar://problem/21529937
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243518 91177308-0d34-0410-b5e6-96231b3b80d8
This commit changes the driver to save subtarget feature "+strict-align" to the
IR instead of using backend option "arm-strict-align". This is needed for LTO.
Also, move the logic in ARM backend that was deciding whether strict alignment
should be forced to the front-end.
rdar://problem/21529937
http://reviews.llvm.org/D11472
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243489 91177308-0d34-0410-b5e6-96231b3b80d8
This patch allows Clang to pass on -Wa,-mfpu, -Wa,-mhwdiv and
-Wa,-mcpu to the integrated assembler (via target-features), but
-march is still not being passed, but validated.
In case the command line has both -mxxx and -Wa,-mxxx, we warn
that the naked one will not be used in assembler mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243353 91177308-0d34-0410-b5e6-96231b3b80d8
To be able to handle -Wa, options in the assembler (ClangAs), we need to
make the handling of options based on the value of the options, not direct
Arguments from the list, since the list is immutable.
No functional change in this patch, but this allows validating of -Wa,-mfpu
and friends in the same way we validate -mfpu and friends, *just* for the
assembler.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243352 91177308-0d34-0410-b5e6-96231b3b80d8
After r243308, the front-end is responsible for checking the target OS and
passing reserve-x18 if the target is Darwin.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243310 91177308-0d34-0410-b5e6-96231b3b80d8
Currently trigger to select hard-float linker is only based of -gnueabihf
appearing in target triplet, but we should also select it when hardfloat
is requested via cmdline.
Patch by Khem Raj.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243262 91177308-0d34-0410-b5e6-96231b3b80d8
We had multiple bugs here:
- We didn't support multiple optimization options in one argument.
e.g. -O2y-
- We didn't correctly expand -O[12dx] to their respective options.
- We treated -O1 as clang -O1 instead of clang -Os.
- We treated -Ox as clang -O3 instead of clang -O2. In fact, cl's -Ox
option is *less* powerful than cl's -O2 option despite -Ox described
as "Full Optimization".
This fixes PR24003.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243261 91177308-0d34-0410-b5e6-96231b3b80d8
option "-aarch64-reserve-x18".
This change is needed since backend options do not make it to the backend
when doing LTO and are not capable of changing the behavior of code-gen
passes on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D11462
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243185 91177308-0d34-0410-b5e6-96231b3b80d8
The flag allows users to specify that they do not want the object file
to have any implicit /defaultlib directives.
This fixes PR24236.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243097 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, for --rtlib=compiler-rt on GNU systems, we're assuming
that one has libgcc_s and libgcc_eh as low-level libraries, which
when used in conjunction with -lunwind or -lc++abi, breaks that
assumption.
My original fix was wrong, and this patch reverts it to prepare for
a new flag to choose the unwinder/C++ libraries. For the time being,
people can use "-lgcc_s -lgcc_eh" or "-lunwind -lc++abi" or any
combination they need explicitly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243025 91177308-0d34-0410-b5e6-96231b3b80d8
option "-arm-reserve-r9".
This recommits r242736, which had to be reverted because the llvm-side
change that was committed in r242737 caused the number of subtarget
features to go over the limit of 64.
This change is needed since backend options do not make it to the backend
when doing LTO and are not capable of changing the behavior of code-gen
passes on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D11319
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242755 91177308-0d34-0410-b5e6-96231b3b80d8
r242737 caused builds to fail with the following error message, so I'm
reverting the clang side change too:
error:Too many subtarget features! Bump MAX_SUBTARGET_FEATURES.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242741 91177308-0d34-0410-b5e6-96231b3b80d8
option "-arm-reserve-r9".
This change is needed since backend options do not make it to the backend
when doing LTO and are not capable of changing the behavior of code-gen
passes on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D11319
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242736 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, -save-temp will cause ObjCARC optimization to be dropped,
sanitizer pass to run early in the pipeline, and profiling
instrumentation to run twice.
Fix the issue by properly disable all passes in the optimization
pipeline when generating bitcode output and parse some of the Language
Options even when the input is bitcode so the passes can be setup
correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242565 91177308-0d34-0410-b5e6-96231b3b80d8
Guessing which file name to replace based on the -main-file-name
argument to -cc1 is flawed. Instead, keep track of which arguments are
inputs to each command.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242504 91177308-0d34-0410-b5e6-96231b3b80d8
"-arm-use-movt=0".
This change is needed since backend options do not make it to the backend
when doing LTO and are not capable of changing the behavior of code-gen
passes on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D11025
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242368 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than making -fexceptions a core option that enables C++ EH in
clang-cl, users can use the '-Xclang -fexceptions -Xclang
-fcxx-exceptions' flag set. We weren't going to expose -fexceptions in
clang-cl in the long run, so this way we don't add and then remove a
flag.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242176 91177308-0d34-0410-b5e6-96231b3b80d8
NOTE: reverts r242077 to reinstate r242058, r242065, 242067
and includes fix for OS X test failures.
- Changed driver pipeline to compile host and device side of CUDA
files and incorporate results of device-side compilation into host
object file.
- Added a test for cuda pipeline creation in clang driver.
New clang options:
--cuda-host-only - Do host-side compilation only.
--cuda-device-only - Do device-side compilation only.
--cuda-gpu-arch=<ARCH> - specify GPU architecture for device-side
compilation. E.g. sm_35, sm_30. Default is sm_20. May be used more
than once in which case one device-compilation will be done per
unique specified GPU architecture.
Differential Revision: http://reviews.llvm.org/D9509
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242085 91177308-0d34-0410-b5e6-96231b3b80d8
The tests were failing on OS X.
Revert "[cuda] Driver changes to compile and stitch together host and device-side CUDA code."
Revert "Fixed regex to properly match '64' in the test case."
Revert "clang/test/Driver/cuda-options.cu REQUIRES clang-driver, at least."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242077 91177308-0d34-0410-b5e6-96231b3b80d8
- Changed driver pipeline to compile host and device side of CUDA
files and incorporate results of device-side compilation into host
object file.
- Added a test for cuda pipeline creation in clang driver.
New clang options:
--cuda-host-only - Do host-side compilation only.
--cuda-device-only - Do device-side compilation only.
--cuda-gpu-arch=<ARCH> - specify GPU architecture for device-side
compilation. E.g. sm_35, sm_30. Default is sm_20. May be used more
than once in which case one device-compilation will be done per
unique specified GPU architecture.
Differential Revision: http://reviews.llvm.org/D9509
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242058 91177308-0d34-0410-b5e6-96231b3b80d8
We don't need any more bug reports from users telling us that MSVC-style
C++ exceptions are broken. Developers and adventurous users can still
test the existing functionality by passing along -fexceptions to either
clang or clang-cl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241952 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241925 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241918 91177308-0d34-0410-b5e6-96231b3b80d8
In certain builds (msan), this can otherwise exceed the stack frame
limit set for certain environments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241894 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241825 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241678 91177308-0d34-0410-b5e6-96231b3b80d8
"-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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241565 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241467 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241241 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241225 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241077 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240980 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240455 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240170 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240134 91177308-0d34-0410-b5e6-96231b3b80d8
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -march option for the AArch64 target.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240019 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
If the driver is only given -msoft-float/-mfloat-abi=soft or -msingle-float,
we should refrain from propagating -mfpxx, unless it was explicitly given on the
command line.
Reviewers: atanasyan, dsanders
Reviewed By: atanasyan, dsanders
Subscribers: cfe-commits, mpf
Differential Revision: http://reviews.llvm.org/D10387
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239818 91177308-0d34-0410-b5e6-96231b3b80d8
We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.
The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239789 91177308-0d34-0410-b5e6-96231b3b80d8
Hans Wennborg