Checking for the type of the command line tokenizer should not be the criteria to enable support for the CL environment variable, this change checks that we are in clang-cl mode instead.
Differential Revision: https://reviews.llvm.org/D23503
llvm-svn: 280702
Summary:
Add a cmake check for sys/resource.h and replace the __has_include() check with its result, in order to make it possible to use rlimits when building with compilers not supporting __has_include() -- i.e. when bootstrapping.
// Please also re-apply dfcd52eb1d8e5d322404b40414cb7331c7380a8c (llvm-config.h fix)
Patch by: Michał Górny
Reviewers: rsmith, beanz
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23744
llvm-svn: 279559
This is a follow-up to r279112 (which removed the need for the header)
and in the same spirit as r279035 (which attempted to un-break
out-of-tree builds).
llvm-svn: 279348
<sys/resource.h> is available. This should fix out-of-tree builds, at the cost
of not providing the higher rlimits to stage 1 clang when built with an old
host compiler not implementing this feature yet (bootstrap builds should be
fine, though).
llvm-svn: 279112
llvm/Config/config.h has intentionally been excluded from llvm
installations (see: llvm/CMakeLists.txt). Un-break out-of-tree builds
post-r278882 by switching to llvm-config.h, which is exported.
Suggested by Will Dietz!
llvm-svn: 279035
around a Linux kernel bug where the actual amount of available stack may be a
*lot* lower than the rlimit.
GCC also sets a higher stack rlimit on startup, but it goes all the way to
64MiB. We can increase this limit if it proves necessary.
The kernel bug is as follows: Linux kernels prior to version 4.1 may choose to
map the process's heap as little as 128MiB before the process's stack for a PIE
binary, even in a 64-bit virtual address space. This means that allocating more
than 128MiB before you reach the process's stack high water mark can lead to
crashes, even if you don't recurse particularly deeply.
We work around the kernel bug by touching a page deep within the stack (after
ensuring that we know how big it is), to preallocate virtual address space for
the stack so that the kernel doesn't allow the brk() area to wander into it,
when building clang as a Linux PIE binary.
llvm-svn: 278882
LD64 does optimization on symbol layouts that gets disabled whenever an order file is passed (even if it is empty). This change prevents disabling that optimization, and still enables iterative generation and usage of order files.
If the order file is empty it does not setup the order file flags, instead it sets the empty order file as a configuration dependency. When the order file changes it will then trigger a re-configuration that adds the linker flag.
llvm-svn: 278306
llvm statistics are currently printed when the destructor of a "static
ManagedStatic<StatisticInfo> StatInfo" in llvm runs. This destructor
currently runs in each case as part of llvm_shutdown() which is run even
in disable_free mode as part of main(). I assume that this hasn't always
been the case.
Removing the special code here avoids the statistics getting printed
twice.
Differential Revision: http://reviews.llvm.org/D21338
llvm-svn: 272820
Currently, clang-cl always uses Windows style for unquoting, and clang always
uses POSIX style for unquoting.
With this flag, it's possible to change these defaults.
In general, response file quoting should match the shell the response file is
used in. On Windows, it's possible to run clang-cl in a bash shell, or clang in
cmd.exe, so a flag for overriding the default behavior is natural there.
On non-Windows, Windows quoting probably never makes sense (except maybe in
Wine), but having clang-cl behave differently based on the host OS seems
strange too. So require that people who want to use posix-style response
files with clang-cl on non-Windows pass --rsp-quoting=posix.
http://reviews.llvm.org/D19425
llvm-svn: 267474
Summary:
https://llvm.org/bugs/show_bug.cgi?id=27396
This fixes an issue in response files where "\r\n" was being interpreted
as two EOL markers (i.e. we consumed the '\r' as terminating the
previous token, and then parsed the '\n' as a significant EOL). This
breaks response files where joined arguments get split across multiple
lines (like "-x\r\nc"). I also fixed an accidental issue in the
response-file.c test, where the response file is appended to, instead of
being overwritten.
Reviewers: rnk
Subscribers: danalbert, llvm-commits
Differential Revision: http://reviews.llvm.org/D19289
llvm-svn: 266840
This patch changes the default DWARF version for cc1as from invalid 0 to 2,
which should be the lowest common denominator on all platforms.
rdar://problem/24735813
llvm-svn: 266814
This is re-landing r260742. I've reworked the conditionals so that it only hits when targeting Apple platforms with ld64.
Original Summary:
With this change generating clang order files using dtrace uses the following workflow:
cmake <whatever options you want>
ninja generate-order-file
ninja clang
This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.
CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.
llvm-svn: 265864
The CMake EXISTS operator needs to have the variable expanded. Not expanding this was causing the if statement to always be false, which made it impossible to pass linker order files in.
llvm-svn: 264757
This appears to be passing '-Wl,-order_file' to Linux link commands,
which then causes the linker to silently, behind the scenes, write the
output to 'rder_file' instead of somewhere else. Will work with Chris to
figure out the proper support for this, but so far there are numerous
people who can't get Clang to update when they build because of this.
llvm-svn: 261054
Summary:
This commit re-lands r259862. The underlying cause of the build breakage was an incorrectly written capabilities test. In tools/Driver/CMakeLists.txt I was attempting to check if a linker flag worked, the test was passing it to the compiler, not the linker. CMake doesn't have a linker test, so we have a hand-rolled one.
Original Patch Review: http://reviews.llvm.org/D16896
Original Summary:
With this change generating clang order files using dtrace uses the following workflow:
cmake <whatever options you want>
ninja generate-order-file
ninja clang
This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.
CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.
Reviewers: bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16999
llvm-svn: 260742
This reverts commit r259862, and attempts to fix builder CMakeCaches.
Will try this again some other time...
Conflicts:
CMakeLists.txt
tools/driver/CMakeLists.txt
llvm-svn: 259872
Summary:
With this change generating clang order files using dtrace uses the following workflow:
cmake <whatever options you want>
ninja generate-order-file
ninja clang
This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.
CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.
Reviewers: bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16896
llvm-svn: 259862
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
This change brings forward the LLVM convention that "executables" are just runnable binaries, and "tools" are executables that are part of the project's install.
Having this abstraction will allow us to simplify some of the tool CMakeLists files, and it will standardize some of the install behaviors.
llvm-svn: 258209
The /Brepro flag controls whether or not the compiler should embed
timestamps into the object file. Object files which do not embed
timestamps are not suitable for incremental linking but are suitable for
hermetic build systems and staged self-hosts of clang.
A normal clang spelling of this flag has been added,
-mincremental-linker-compatible.
llvm-svn: 256204
LLVM_SUBMIT_VERSION and LLVM_SUBMIT_SUBVERSION are commonly used variable names in the autoconf build system. They seem to have leeched into clang's CMake in a few places, and should just be replaced by the LLVM_VERSION_* variables where appropriate.
llvm-svn: 250246
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
llvm-svn: 249655
logic to select an alternate target based on the executable it was
called as. For instance, if you symlink i686-linux-android-gcc to clang
and invoke it, the driver will act as though it were called with another
argument ("-target i686-linux-android"). This leads to visible effects
even in syntax-only compilations (like the ANDROID preprocessor symbol
being defined).
This behavior is not replicated for tool invocations--for instance,
clang::createInvocationFromCommandLine will not choose an alternate
target based on ArgList[0]. This means that configurations stored in
compilation databases aren't accurately replayed.
This patch separates the logic for selecting a mode flag and target from
the executable name into a new member function on ToolChain. It should
have no functional effects (but will allow other code to reuse the
target/mode selection logic).
Patch by Luke Zarko!
llvm-svn: 248592
Generation of clang symlinks now uses add_clang_symlink macro which uses add_llvm_symlink. Also the list of symlinks to generate is configurable via CLANG_LINKS_TO_CREATE.
This re-lands r248015, with fixes for clang symlinks to always be generated as part of the clang and install-clang targets.
llvm-svn: 248043
Generation of clang symlinks now uses add_clang_symlink macro which uses add_llvm_symlink. Also the list of symlinks to generate is configurable via CLANG_LINKS_TO_CREATE.
llvm-svn: 248015
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change. Thanks go to Pavel Labath for fixing LLDB for me.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247692
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247683
Pierre Gousseau