2011-01-01 01:31:54 +08:00
|
|
|
//===--- Compilation.cpp - Compilation Task Implementation ----------------===//
|
2009-03-03 03:59:07 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "clang/Driver/Compilation.h"
|
2009-03-18 10:55:38 +08:00
|
|
|
#include "clang/Driver/Action.h"
|
2009-03-19 06:16:03 +08:00
|
|
|
#include "clang/Driver/Driver.h"
|
|
|
|
#include "clang/Driver/DriverDiagnostic.h"
|
2009-11-19 12:25:22 +08:00
|
|
|
#include "clang/Driver/Options.h"
|
2009-03-16 14:42:30 +08:00
|
|
|
#include "clang/Driver/ToolChain.h"
|
2011-08-03 01:58:04 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2013-06-15 01:17:23 +08:00
|
|
|
#include "llvm/Option/ArgList.h"
|
2013-06-19 04:58:25 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2011-07-23 19:36:43 +08:00
|
|
|
|
2009-03-05 04:49:20 +08:00
|
|
|
using namespace clang::driver;
|
2011-07-23 19:36:43 +08:00
|
|
|
using namespace clang;
|
2013-06-15 01:17:23 +08:00
|
|
|
using namespace llvm::opt;
|
2009-03-03 03:59:07 +08:00
|
|
|
|
2010-06-12 06:00:26 +08:00
|
|
|
Compilation::Compilation(const Driver &D, const ToolChain &_DefaultToolChain,
|
2017-06-30 21:21:27 +08:00
|
|
|
InputArgList *_Args, DerivedArgList *_TranslatedArgs,
|
|
|
|
bool ContainsError)
|
[CUDA][OpenMP] Create generic offload toolchains
Summary:
This patch introduces the concept of offloading tool chain and offloading kind. Each tool chain may have associated an offloading kind that marks it as used in a given programming model that requires offloading.
It also adds the logic to iterate on the tool chains based on the kind. Currently, only CUDA is supported, but in general a programming model (an offloading kind) may have associated multiple tool chains that require supporting offloading.
This patch does not add tests - its goal is to keep the existing functionality.
This patch is the first of a series of three that attempts to make the current support of CUDA more generic and easier to extend to other programming models, namely OpenMP. It tries to capture the suggestions/improvements/concerns on the initial proposal in http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html. It only tackles the more consensual part of the proposal, i.e.does not address the problem of intermediate files bundling yet.
Reviewers: ABataev, jlebar, echristo, hfinkel, tra
Subscribers: guansong, Hahnfeld, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: http://reviews.llvm.org/D18170
llvm-svn: 272571
2016-06-14 02:10:57 +08:00
|
|
|
: TheDriver(D), DefaultToolChain(_DefaultToolChain), ActiveOffloadMask(0u),
|
2017-09-14 01:03:58 +08:00
|
|
|
Args(_Args), TranslatedArgs(_TranslatedArgs), ForDiagnostics(false),
|
|
|
|
ContainsError(ContainsError) {
|
[CUDA][OpenMP] Create generic offload toolchains
Summary:
This patch introduces the concept of offloading tool chain and offloading kind. Each tool chain may have associated an offloading kind that marks it as used in a given programming model that requires offloading.
It also adds the logic to iterate on the tool chains based on the kind. Currently, only CUDA is supported, but in general a programming model (an offloading kind) may have associated multiple tool chains that require supporting offloading.
This patch does not add tests - its goal is to keep the existing functionality.
This patch is the first of a series of three that attempts to make the current support of CUDA more generic and easier to extend to other programming models, namely OpenMP. It tries to capture the suggestions/improvements/concerns on the initial proposal in http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html. It only tackles the more consensual part of the proposal, i.e.does not address the problem of intermediate files bundling yet.
Reviewers: ABataev, jlebar, echristo, hfinkel, tra
Subscribers: guansong, Hahnfeld, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: http://reviews.llvm.org/D18170
llvm-svn: 272571
2016-06-14 02:10:57 +08:00
|
|
|
// The offloading host toolchain is the default tool chain.
|
|
|
|
OrderedOffloadingToolchains.insert(
|
|
|
|
std::make_pair(Action::OFK_Host, &DefaultToolChain));
|
|
|
|
}
|
2009-03-16 14:42:30 +08:00
|
|
|
|
2009-09-09 23:08:12 +08:00
|
|
|
Compilation::~Compilation() {
|
2010-06-12 06:00:26 +08:00
|
|
|
delete TranslatedArgs;
|
2009-03-16 14:42:30 +08:00
|
|
|
delete Args;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-03-16 14:42:30 +08:00
|
|
|
// Free any derived arg lists.
|
2016-10-08 05:27:26 +08:00
|
|
|
for (auto Arg : TCArgs)
|
|
|
|
if (Arg.second != TranslatedArgs)
|
|
|
|
delete Arg.second;
|
2009-03-03 03:59:07 +08:00
|
|
|
}
|
|
|
|
|
[Driver][OpenMP] Add logic for offloading-specific argument translation.
Summary:
This patch includes support for argument translation that is specific of a given offloading kind. Additionally, it implements the translation for OpenMP device kinds in the gcc tool chain.
With this patch, it is possible to compile a functional OpenMP application with offloading capabilities with no separate compilation.
Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21848
llvm-svn: 285320
2016-10-28 01:39:44 +08:00
|
|
|
const DerivedArgList &
|
|
|
|
Compilation::getArgsForToolChain(const ToolChain *TC, StringRef BoundArch,
|
|
|
|
Action::OffloadKind DeviceOffloadKind) {
|
2009-03-16 14:42:30 +08:00
|
|
|
if (!TC)
|
|
|
|
TC = &DefaultToolChain;
|
|
|
|
|
[Driver][OpenMP] Add logic for offloading-specific argument translation.
Summary:
This patch includes support for argument translation that is specific of a given offloading kind. Additionally, it implements the translation for OpenMP device kinds in the gcc tool chain.
With this patch, it is possible to compile a functional OpenMP application with offloading capabilities with no separate compilation.
Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21848
llvm-svn: 285320
2016-10-28 01:39:44 +08:00
|
|
|
DerivedArgList *&Entry = TCArgs[{TC, BoundArch, DeviceOffloadKind}];
|
2010-06-12 06:00:26 +08:00
|
|
|
if (!Entry) {
|
2017-09-28 02:12:31 +08:00
|
|
|
SmallVector<Arg *, 4> AllocatedArgs;
|
2017-10-04 21:32:59 +08:00
|
|
|
DerivedArgList *OpenMPArgs = nullptr;
|
2017-08-07 23:39:11 +08:00
|
|
|
// Translate OpenMP toolchain arguments provided via the -Xopenmp-target flags.
|
2017-10-04 21:32:59 +08:00
|
|
|
if (DeviceOffloadKind == Action::OFK_OpenMP) {
|
|
|
|
const ToolChain *HostTC = getSingleOffloadToolChain<Action::OFK_Host>();
|
|
|
|
bool SameTripleAsHost = (TC->getTriple() == HostTC->getTriple());
|
|
|
|
OpenMPArgs = TC->TranslateOpenMPTargetArgs(
|
|
|
|
*TranslatedArgs, SameTripleAsHost, AllocatedArgs);
|
|
|
|
}
|
|
|
|
|
2017-08-08 02:43:37 +08:00
|
|
|
if (!OpenMPArgs) {
|
|
|
|
Entry = TC->TranslateArgs(*TranslatedArgs, BoundArch, DeviceOffloadKind);
|
2017-09-28 02:12:36 +08:00
|
|
|
if (!Entry)
|
|
|
|
Entry = TranslatedArgs;
|
2017-08-08 02:43:37 +08:00
|
|
|
} else {
|
|
|
|
Entry = TC->TranslateArgs(*OpenMPArgs, BoundArch, DeviceOffloadKind);
|
2017-09-28 02:12:36 +08:00
|
|
|
if (!Entry)
|
|
|
|
Entry = OpenMPArgs;
|
|
|
|
else
|
|
|
|
delete OpenMPArgs;
|
2017-08-08 02:43:37 +08:00
|
|
|
}
|
2017-08-07 23:39:11 +08:00
|
|
|
|
2017-09-28 02:12:31 +08:00
|
|
|
// Add allocated arguments to the final DAL.
|
|
|
|
for (auto ArgPtr : AllocatedArgs) {
|
|
|
|
Entry->AddSynthesizedArg(ArgPtr);
|
|
|
|
}
|
2010-06-12 06:00:26 +08:00
|
|
|
}
|
2009-03-16 14:42:30 +08:00
|
|
|
|
2009-03-18 13:58:45 +08:00
|
|
|
return *Entry;
|
2009-03-03 03:59:07 +08:00
|
|
|
}
|
|
|
|
|
2013-01-25 03:14:47 +08:00
|
|
|
bool Compilation::CleanupFile(const char *File, bool IssueErrors) const {
|
2013-06-25 01:59:44 +08:00
|
|
|
// FIXME: Why are we trying to remove files that we have not created? For
|
|
|
|
// example we should only try to remove a temporary assembly file if
|
|
|
|
// "clang -cc1" succeed in writing it. Was this a workaround for when
|
|
|
|
// clang was writing directly to a .s file and sometimes leaving it behind
|
|
|
|
// during a failure?
|
|
|
|
|
|
|
|
// FIXME: If this is necessary, we can still try to split
|
|
|
|
// llvm::sys::fs::remove into a removeFile and a removeDir and avoid the
|
|
|
|
// duplicated stat from is_regular_file.
|
2013-01-25 03:14:47 +08:00
|
|
|
|
|
|
|
// Don't try to remove files which we don't have write access to (but may be
|
|
|
|
// able to remove), or non-regular files. Underlying tools may have
|
|
|
|
// intentionally not overwritten them.
|
2013-06-25 01:59:44 +08:00
|
|
|
if (!llvm::sys::fs::can_write(File) || !llvm::sys::fs::is_regular_file(File))
|
2013-01-25 03:14:47 +08:00
|
|
|
return true;
|
|
|
|
|
2014-06-12 22:02:15 +08:00
|
|
|
if (std::error_code EC = llvm::sys::fs::remove(File)) {
|
2013-06-25 01:59:44 +08:00
|
|
|
// Failure is only failure if the file exists and is "regular". We checked
|
|
|
|
// for it being regular before, and llvm::sys::fs::remove ignores ENOENT,
|
|
|
|
// so we don't need to check again.
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
|
2013-06-25 01:59:44 +08:00
|
|
|
if (IssueErrors)
|
|
|
|
getDriver().Diag(clang::diag::err_drv_unable_to_remove_file)
|
|
|
|
<< EC.message();
|
|
|
|
return false;
|
2013-01-25 03:14:47 +08:00
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2009-09-09 23:08:12 +08:00
|
|
|
bool Compilation::CleanupFileList(const ArgStringList &Files,
|
2009-03-19 06:16:03 +08:00
|
|
|
bool IssueErrors) const {
|
|
|
|
bool Success = true;
|
2009-09-09 23:08:12 +08:00
|
|
|
for (ArgStringList::const_iterator
|
2013-01-25 03:14:47 +08:00
|
|
|
it = Files.begin(), ie = Files.end(); it != ie; ++it)
|
|
|
|
Success &= CleanupFile(*it, IssueErrors);
|
|
|
|
return Success;
|
|
|
|
}
|
2009-11-24 23:23:21 +08:00
|
|
|
|
2013-01-25 03:14:47 +08:00
|
|
|
bool Compilation::CleanupFileMap(const ArgStringMap &Files,
|
|
|
|
const JobAction *JA,
|
|
|
|
bool IssueErrors) const {
|
|
|
|
bool Success = true;
|
|
|
|
for (ArgStringMap::const_iterator
|
|
|
|
it = Files.begin(), ie = Files.end(); it != ie; ++it) {
|
2009-03-19 06:16:03 +08:00
|
|
|
|
2013-01-25 03:14:47 +08:00
|
|
|
// If specified, only delete the files associated with the JobAction.
|
|
|
|
// Otherwise, delete all files in the map.
|
|
|
|
if (JA && it->first != JA)
|
2011-04-26 04:43:05 +08:00
|
|
|
continue;
|
2013-01-25 03:14:47 +08:00
|
|
|
Success &= CleanupFile(it->second, IssueErrors);
|
2009-03-19 06:16:03 +08:00
|
|
|
}
|
|
|
|
return Success;
|
|
|
|
}
|
|
|
|
|
2009-07-02 03:14:39 +08:00
|
|
|
int Compilation::ExecuteCommand(const Command &C,
|
|
|
|
const Command *&FailingCommand) const {
|
2013-07-24 01:58:53 +08:00
|
|
|
if ((getDriver().CCPrintOptions ||
|
2011-08-03 01:58:04 +08:00
|
|
|
getArgs().hasArg(options::OPT_v)) && !getDriver().CCGenDiagnostics) {
|
2011-07-23 18:55:15 +08:00
|
|
|
raw_ostream *OS = &llvm::errs();
|
2010-03-20 16:01:59 +08:00
|
|
|
|
|
|
|
// Follow gcc implementation of CC_PRINT_OPTIONS; we could also cache the
|
|
|
|
// output stream.
|
|
|
|
if (getDriver().CCPrintOptions && getDriver().CCPrintOptionsFilename) {
|
2014-08-26 02:17:04 +08:00
|
|
|
std::error_code EC;
|
|
|
|
OS = new llvm::raw_fd_ostream(getDriver().CCPrintOptionsFilename, EC,
|
2014-02-25 02:20:21 +08:00
|
|
|
llvm::sys::fs::F_Append |
|
|
|
|
llvm::sys::fs::F_Text);
|
2014-08-26 02:17:04 +08:00
|
|
|
if (EC) {
|
2010-03-20 16:01:59 +08:00
|
|
|
getDriver().Diag(clang::diag::err_drv_cc_print_options_failure)
|
2014-08-26 02:17:04 +08:00
|
|
|
<< EC.message();
|
2010-03-20 16:01:59 +08:00
|
|
|
FailingCommand = &C;
|
|
|
|
delete OS;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (getDriver().CCPrintOptions)
|
|
|
|
*OS << "[Logging clang options]";
|
|
|
|
|
2013-09-13 02:23:34 +08:00
|
|
|
C.Print(*OS, "\n", /*Quote=*/getDriver().CCPrintOptions);
|
2010-03-20 16:01:59 +08:00
|
|
|
|
|
|
|
if (OS != &llvm::errs())
|
|
|
|
delete OS;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-03-19 16:01:45 +08:00
|
|
|
std::string Error;
|
2013-03-27 07:41:30 +08:00
|
|
|
bool ExecutionFailed;
|
2013-09-13 02:35:08 +08:00
|
|
|
int Res = C.Execute(Redirects, &Error, &ExecutionFailed);
|
2009-03-19 16:01:45 +08:00
|
|
|
if (!Error.empty()) {
|
|
|
|
assert(Res && "Error string set with 0 result code!");
|
|
|
|
getDriver().Diag(clang::diag::err_drv_command_failure) << Error;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-07-02 03:14:39 +08:00
|
|
|
if (Res)
|
|
|
|
FailingCommand = &C;
|
|
|
|
|
2013-03-27 07:41:30 +08:00
|
|
|
return ExecutionFailed ? 1 : Res;
|
2009-03-19 16:01:45 +08:00
|
|
|
}
|
|
|
|
|
Bail on compilation as soon as a job fails.
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
2016-02-25 05:49:28 +08:00
|
|
|
void Compilation::ExecuteJobs(
|
|
|
|
const JobList &Jobs,
|
|
|
|
SmallVectorImpl<std::pair<int, const Command *>> &FailingCommands) const {
|
2015-07-03 06:52:08 +08:00
|
|
|
for (const auto &Job : Jobs) {
|
2014-05-18 00:56:41 +08:00
|
|
|
const Command *FailingCommand = nullptr;
|
Bail on compilation as soon as a job fails.
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
2016-02-25 05:49:28 +08:00
|
|
|
if (int Res = ExecuteCommand(Job, FailingCommand)) {
|
2013-01-30 04:15:05 +08:00
|
|
|
FailingCommands.push_back(std::make_pair(Res, FailingCommand));
|
Bail on compilation as soon as a job fails.
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
2016-02-25 05:49:28 +08:00
|
|
|
// Bail as soon as one command fails, so we don't output duplicate error
|
|
|
|
// messages if we die on e.g. the same file.
|
|
|
|
return;
|
|
|
|
}
|
2009-03-19 06:44:24 +08:00
|
|
|
}
|
|
|
|
}
|
2011-08-03 01:58:04 +08:00
|
|
|
|
2012-11-15 22:28:07 +08:00
|
|
|
void Compilation::initCompilationForDiagnostics() {
|
2014-06-21 06:16:00 +08:00
|
|
|
ForDiagnostics = true;
|
|
|
|
|
2011-08-03 01:58:04 +08:00
|
|
|
// Free actions and jobs.
|
2016-01-12 07:07:27 +08:00
|
|
|
Actions.clear();
|
|
|
|
AllActions.clear();
|
2011-08-03 01:58:04 +08:00
|
|
|
Jobs.clear();
|
|
|
|
|
|
|
|
// Clear temporary/results file lists.
|
|
|
|
TempFiles.clear();
|
|
|
|
ResultFiles.clear();
|
2013-01-30 07:57:10 +08:00
|
|
|
FailureResultFiles.clear();
|
2011-08-03 01:58:04 +08:00
|
|
|
|
|
|
|
// Remove any user specified output. Claim any unclaimed arguments, so as
|
|
|
|
// to avoid emitting warnings about unused args.
|
2011-11-06 08:40:05 +08:00
|
|
|
OptSpecifier OutputOpts[] = { options::OPT_o, options::OPT_MD,
|
|
|
|
options::OPT_MMD };
|
2012-05-04 05:25:34 +08:00
|
|
|
for (unsigned i = 0, e = llvm::array_lengthof(OutputOpts); i != e; ++i) {
|
2011-11-06 08:40:05 +08:00
|
|
|
if (TranslatedArgs->hasArg(OutputOpts[i]))
|
|
|
|
TranslatedArgs->eraseArg(OutputOpts[i]);
|
|
|
|
}
|
2011-08-03 01:58:04 +08:00
|
|
|
TranslatedArgs->ClaimAllArgs();
|
|
|
|
|
|
|
|
// Redirect stdout/stderr to /dev/null.
|
2017-09-14 01:03:58 +08:00
|
|
|
Redirects = {None, {""}, {""}};
|
2011-08-03 01:58:04 +08:00
|
|
|
}
|
2012-04-16 12:16:43 +08:00
|
|
|
|
2012-11-15 22:28:07 +08:00
|
|
|
StringRef Compilation::getSysRoot() const {
|
2012-04-16 12:16:43 +08:00
|
|
|
return getDriver().SysRoot;
|
|
|
|
}
|
2016-06-28 16:00:42 +08:00
|
|
|
|
2017-09-14 01:03:58 +08:00
|
|
|
void Compilation::Redirect(ArrayRef<Optional<StringRef>> Redirects) {
|
2016-06-28 16:00:42 +08:00
|
|
|
this->Redirects = Redirects;
|
|
|
|
}
|