Commit Graph

68 Commits

Author SHA1 Message Date
Yaxun (Sam) Liu eca40066eb [NFC] Move OptionUtils from Basic to Driver
Differential Revision: https://reviews.llvm.org/D71802
2019-12-23 08:11:23 -05:00
Heejin Ahn b9903ec897 [clang][driver] Add ProfileData to LLVM_LINK_COMPONENTS
Summary:
After D68351 we need this to make builds with `-DBUILD_SHARED_LIB=ON`
work.

Reviewers: tlively

Subscribers: mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D69699
2019-10-31 19:52:41 -07:00
Peter Waller 6bf5580492 [clang][driver] Add basic --driver-mode=flang support for fortran
This patch adds a new Flang mode. When in Flang mode, the driver will
invoke flang for fortran inputs instead of falling back to the GCC
toolchain as it would otherwise do.

The behaviour of other driver modes are left unmodified to preserve
backwards compatibility.

It is intended that a soon to be implemented binary in the flang project
will import libclangDriver and run the clang driver in the new flang
mode.

Please note that since the binary invoked by the driver is under
development, there will no doubt be further tweaks necessary in future
commits.

* Initial support is added for basic driver phases
  * -E, -fsyntax-only, -emit-llvm -S, -emit-llvm, -S, (none specified)
  * -### tests are added for all of the above
  * This is more than is supported by f18 so far, which will emit errors
    for those options which are unimplemented.

* A test is added that ensures that clang gives a reasonable error
  message if flang is not available in the path (without -###).

* Test that the driver accepts multiple inputs in --driver-mode=flang.

* Test that a combination of C and Fortran inputs run both clang and
  flang in --driver-mode=flang.

* clang/test/Driver/fortran.f95 is fixed to use the correct fortran
  comment character.

Differential revision: https://reviews.llvm.org/D63607
2019-10-30 10:42:22 +00:00
stevewan bb6a27fc25 Add AIX toolchain and basic linker functionality
Summary:
This patch adds AIX toolchain infrastructure into driver, and enables AIX
system linker invocation with some basic functionality support

Reviewers: daltenty, hubert.reinterpretcast, jasonliu, Xiangling_L

Reviewed By: jasonliu

Subscribers: Xiangling_L, jasonliu, ormris, wuzish, nemanjai, mgorny, kbarton, jfb, jsji, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D68340
2019-10-24 14:47:57 -04:00
Puyan Lotfi c382d03ca8 [clang][ifs] Clang Interface Stubs ToolChain plumbing.
Second Landing Attempt:

This patch enables end to end support for generating ELF interface stubs
directly from clang. Now the following:

clang -emit-interface-stubs -o libfoo.so a.cpp b.cpp c.cpp

will product an ELF binary with visible symbols populated. Visibility attributes
and -fvisibility can be used to control what gets populated.

* Adding ToolChain support for clang Driver IFS Merge Phase
* Implementing a default InterfaceStubs Merge clang Tool, used by ToolChain
* Adds support for the clang Driver to involve llvm-ifs on ifs files.
* Adds -emit-merged-ifs flag, to tell llvm-ifs to emit a merged ifs text file
  instead of the final object format (normally ELF)


Differential Revision: https://reviews.llvm.org/D63978

llvm-svn: 374061
2019-10-08 15:23:14 +00:00
Nico Weber 6713f8235b Revert 373538 and follow-ups 373549 and 373552.
They break tests on (at least) macOS.

llvm-svn: 373556
2019-10-03 02:38:43 +00:00
Puyan Lotfi 406de17b9b [clang][ifs] Clang Interface Stubs ToolChain plumbing.
This patch enables end to end support for generating ELF interface stubs
directly from clang. Now the following:

clang -emit-interface-stubs -o libfoo.so a.cpp b.cpp c.cpp

will product an ELF binary with visible symbols populated. Visibility attributes
and -fvisibility can be used to control what gets populated.

* Adding ToolChain support for clang Driver IFS Merge Phase
* Implementing a default InterfaceStubs Merge clang Tool, used by ToolChain
* Adds support for the clang Driver to involve llvm-ifs on ifs files.
* Adds -emit-merged-ifs flag, to tell llvm-ifs to emit a merged ifs text file
  instead of the final object format (normally ELF)


Differential Revision: https://reviews.llvm.org/D63978

llvm-svn: 373538
2019-10-02 22:50:07 +00:00
Qiu Chaofan 19828e399b [PowerPC] [Clang] Port MMX intrinsics and basic test cases to Power
Port mmintrin.h which include x86 MMX intrinsics implementation to PowerPC platform (using Altivec).

To make the include process correct, PowerPC's toolchain class is overrided to insert new headers directory (named ppc_wrappers) into the path. Basic test cases for several intrinsic functions are added.

The header is mainly developed by Steven Munroe, with contributions from Paul Clarke, Bill Schmidt, Jinsong Ji and Zixuan Wu.

Reviewed By: Jinsong Ji

Differential Revision: https://reviews.llvm.org/D59924

llvm-svn: 358949
2019-04-23 05:50:24 +00:00
Anton Korobeynikov 93165d648f [MSP430] Provide a toolchain description
This is an initial implementation for msp430 toolchain including
-mmcu option support
-mhwmult options support
-integrated-as by default

The toolchain uses msp430-elf-as as a linker and supports msp430-gcc toolchain tree.

Patch by Kristina Bessonova!

Differential Revision: https://reviews.llvm.org/D56658

llvm-svn: 351228
2019-01-15 19:44:05 +00:00
Alex Lorenz 0a264f3928 [darwin] parse the SDK settings from SDKSettings.json if it exists and
pass in the -target-sdk-version to the compiler and backend

This commit adds support for reading the SDKSettings.json file in the Darwin
driver. This file is used by the driver to determine the SDK's version, and it
uses that information to pass it down to the compiler using the new
-target-sdk-version= option. This option is then used to set the appropriate
SDK Version module metadata introduced in r349119.

Note: I had to adjust the two ast tests as the SDKROOT environment variable
on macOS caused SDK version to be picked up for the compilation of source file
but not the AST.

rdar://45774000

Differential Revision: https://reviews.llvm.org/D55673

llvm-svn: 349380
2018-12-17 19:19:15 +00:00
Kristina Brooks 77a4adc4f9 Add Hurd target to Clang driver (2/2)
This adds Hurd toolchain support to Clang's driver in addition
to handling translating the triple from Hurd-compatible form to
the actual triple registered in LLVM.

(Phabricator was stripping the empty files from the patch so I 
manually created them)

Patch by sthibaul (Samuel Thibault)

Differential Revision: https://reviews.llvm.org/D54379

llvm-svn: 347833
2018-11-29 03:49:14 +00:00
Erik Pilkington 46420b6fee NFC: Fix some darwin linker warnings introduced in r338385
The darwin linker was complaining about Toolchains/RISCV.cpp and
Toolchains/Arch/RISCV.cpp had the same name. Fix is to just rename
Toolchains/RISCV.cpp to Toolchains/RISCVToolchain.cpp.

Differential revision: https://reviews.llvm.org/D52574

llvm-svn: 343263
2018-09-27 20:36:28 +00:00
David Bolvansky f4be25352a [RISCV] Add driver for riscv32-unknown-elf baremetal target
Summary:
This patch adds a driver for the baremetal RISC-V target (i.e. riscv32-unknown-elf). For reference, D39963 added basic target info and added support for riscv32-linux-unknown-elf.

Patch by: asb (Alex Bradbury)

Reviewers: efriedma, phosek, apazos, espindola, mgrang

Reviewed By: mgrang

Subscribers: jrtc27, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, emaste, mgorny, arichardson, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, cfe-commits

Differential Revision: https://reviews.llvm.org/D46822

llvm-svn: 338385
2018-07-31 14:21:46 +00:00
Yaxun Liu f614422da9 Add HIP toolchain
This patch adds HIP toolchain to support HIP language mode. It includes:

Create specific compiler jobs for HIP.

Choose specific libraries for HIP.

With contribution from Greg Rodgers.

Differential Revision: https://reviews.llvm.org/D45212

llvm-svn: 333484
2018-05-30 00:53:50 +00:00
Alex Bradbury 71f45455e1 [RISCV] Add the RISCV target and compiler driver
As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver 
support (RV64 to follow).

Differential Revision: https://reviews.llvm.org/D39963

llvm-svn: 322276
2018-01-11 13:36:56 +00:00
Erich Keane 2b9657b570 Remove Bitrig: Clang Changes
Bitrig code has been merged back to OpenBSD, thus the OS has been abandoned.

Differential Revision: https://reviews.llvm.org/D35708

llvm-svn: 308797
2017-07-21 22:46:31 +00:00
Ed Schouten 4dabea22d3 Add support for Ananas platform
Ananas is a home-brew operating system, mainly for amd64 machines. After
using GCC for quite some time, it has switched to clang and never looked
back - yet, having to manually patch things is annoying, so it'd be much
nicer if this was in the official tree.

More information:

https://github.com/zhmu/ananas/
https://rink.nu/projects/ananas.html

Submitted by:	Rink Springer
Differential Revision:	https://reviews.llvm.org/D32936

llvm-svn: 306239
2017-06-25 08:29:09 +00:00
NAKAMURA Takumi 92c99cd6dc Update libdeps to add BinaryFormat, introduced in r304864.
llvm-svn: 304869
2017-06-07 04:48:49 +00:00
Jonathan Roelofs 901c776d06 Don't defer to the GCC driver for linking arm-baremetal
Also comes with a cmake cache for building the runtime bits:

 $ cmake <normal cmake flags> \
   -DBAREMETAL_ARMV6M_SYSROOT=/path/to/sysroot \
   -DBAREMETAL_ARMV7M_SYSROOT=/path/to/sysroot \
   -DBAREMETAL_ARMV7EM_SYSROOT=/path/to/sysroot \
   -C /path/to/clang/cmake/caches/BaremetalARM.cmake \
   /path/to/llvm

https://reviews.llvm.org/D33259

llvm-svn: 303873
2017-05-25 15:42:13 +00:00
Dean Michael Berris 835832d37a [XRay] Add -fxray-{always,never}-instrument= flags to clang
Summary:
The -fxray-always-instrument= and -fxray-never-instrument= flags take
filenames that are used to imbue the XRay instrumentation attributes
using a whitelist mechanism (similar to the sanitizer special cases
list). We use the same syntax and semantics as the sanitizer blacklists
files in the implementation.

As implemented, we respect the attributes that are already defined in
the source file (i.e. those that have the
[[clang::xray_{always,never}_instrument]] attributes) before applying
the always/never instrument lists.

Reviewers: rsmith, chandlerc

Subscribers: jfb, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D30388

llvm-svn: 299041
2017-03-30 00:29:36 +00:00
Konstantin Zhuravlyov e37b32c433 Driver/ToolChains: Mips -> MipsLinux
- Mips is architecture, not a toolchain
  - Might help eliminate the confusion in the future by not having header files with the same name

Differential Revision: https://reviews.llvm.org/D30753

llvm-svn: 297312
2017-03-08 22:36:04 +00:00
David L. Jones f561abab56 [Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)

This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.

There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.

I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.

There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.

Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar

Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D30372

llvm-svn: 297250
2017-03-08 01:02:16 +00:00
David L. Jones ecc6de35fb [Driver] Move architecture-specific free helper functions to their own files.
This patch moves helper functions that are CPU-specific out of Driver.cpp and to
separate implementation files. The new files are named for the architecture,
e.g. ARMArch.cpp.

The next step after this will be to move OS-specific code, which I expect will
include many of the tool implementations, to similarly separate files.

Some CPU-specific functions are not being moved just yet. In cases where the
only caller is the platform-specific tools, I plan to move them together. An
example is Hexagon, where the only caller of the architecture-specific functions
are the tools themselves. (I'm happy to revise this choice, it just seems like
less churn to me.)

This does mean that some functions which were previously static are now exposed
through the library header Driver.h.

Reviewers: rsmith, javed.absar

Subscribers: aemerson, danalbert, srhines, dschuff, jyknight, nemanjai, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D30315

llvm-svn: 296056
2017-02-24 00:28:01 +00:00
Michal Gorny 67e199eb32 [Driver] Refactor distro detection & classification as a separate API
Refactor the Distro enum along with helper functions into a full-fledged
Distro class, inspired by llvm::Triple, and make it a public API.
The new class wraps the enum with necessary comparison operators, adding
the convenience Is*() methods and a constructor performing
the detection. The public API is needed to run the unit tests (D25869).

Differential Revision: https://reviews.llvm.org/D25949

llvm-svn: 288060
2016-11-28 21:11:14 +00:00
NAKAMURA Takumi 2326f79a60 MSVCToolChain.cpp: Make version.dll generic for win32.
We may consider msvc features may be capable on mingw host, if it can.
Consider --host=mingw --target=msvc.

llvm-svn: 269557
2016-05-14 08:12:37 +00:00
Yaron Keren 1c0070c65d Support mingw-w64 and mingw.org toolchains at any install location.
No more hardcoded paths: clang will use -sysroot as gcc root location if
provided. Otherwise, it will search for gcc on the path. If not found it
will use the driver installed location.

 http://reviews.llvm.org/D5268

Patch by Ruben Van Boxem, Martell Malone, Yaron Keren.
Reviewed by Reid Kleckner.

llvm-svn: 241241
2015-07-02 04:45:27 +00:00
Saleem Abdulrasool 543a78b55e Driver: add CrossWindowsToolChain
This is a very basic toolchain.  It supports cross-compiling Windows (primarily
inspired by the WoA target).  It is meant to use clang with the LLVM IAS and a
binutils ld-compatible interface for the linker (eventually to be lld).  It does
not perform any "standard" GCC lookup, nor does it perform any special
adjustments given that it is expected to be used in an environment where the
user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK.
The primary runtime library is expected to be compiler-rt and the C++
implementation to be libc++.

It also expects that a sysroot has been setup given the usual Unix semantics
(standard C headers in /usr/include, all the import libraries available in
/usr/lib).  It also expects that an entry point stub is present in /usr/lib
(crtbegin.obj for executables, crtbeginS.obj for shared libraries).

The entry point stub is responsible for running any GNU constructors.

llvm-svn: 220546
2014-10-24 03:13:37 +00:00
Saleem Abdulrasool 819f391dae Driver: rename Windows to MSVCToolChain
This renames the Windows toolchain to MSVCToolChain.  This is a preparatory step
for adding a CrossWindowsToolChain which uses clang/libc++/(ld/lld) without the
standard GCC toolchain lookup.  NFC.

llvm-svn: 220362
2014-10-22 02:37:29 +00:00
Alexey Samsonov b7dd329f2f Decouple llvm::SpecialCaseList text representation and its LLVM IR semantics.
Turn llvm::SpecialCaseList into a simple class that parses text files in
a specified format and knows nothing about LLVM IR. Move this class into
LLVMSupport library. Implement two users of this class:
  * DFSanABIList in DFSan instrumentation pass.
  * SanitizerBlacklist in Clang CodeGen library.
The latter will be modified to use actual source-level information from frontend
(source file names) instead of unstable LLVM IR things (LLVM Module identifier).

Remove dependency edge from ClangCodeGen/ClangDriver to LLVMTransformUtils.

No functionality change.

llvm-svn: 212643
2014-07-09 19:40:08 +00:00
Alp Toker 61dad75b10 cc1as: consolidate option flags with cc1 and eliminate duplication
The clang -cc1as options are nearly a strict subset of -cc1. Instead of
duplicating the definitions and documentation, let's go ahead and share the
definitions in a similar way the current handling of combined driver and
frontend flags, eliminating some of the vestigial legacy surrounding the
assembler subcommand.

llvm-svn: 212620
2014-07-09 14:05:11 +00:00
NAKAMURA Takumi 9698686505 [CMake] Use LINK_LIBS instead of target_link_libraries().
llvm-svn: 202238
2014-02-26 06:41:29 +00:00
NAKAMURA Takumi 7da9487dd4 [CMake] Get rid of explicit dependencies to include/clang/*.inc and introduce CLANG_TABLEGEN_TARGETS.
This does;
  - clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
  - List of targets is added to LLVM_COMMON_DEPENDS.
  - all clang libraries and targets depend on generated headers.

You might wonder this would be regression, but in fact, this is little loss.
  - Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
  - clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
  - Each library's dependencies to tblgen'd files might vary along headers' structure.
    It made hard to track and update *really optimal* dependencies.

Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.

llvm-svn: 201842
2014-02-21 07:59:59 +00:00
Jonathan Roelofs 2cea1bea87 Add Multilib selection machinery
This patch improves the support for picking Multilibs from gcc installations.
It also provides a better approximation for the flags '-print-multi-directory'
and '-print-multi-lib'.

This reverts r201203 (i.e. re-applying r201202 with small fixes in
unittests/CMakeLists.txtto make the build bots happy).

review: http://llvm-reviews.chandlerc.com/D2538
llvm-svn: 201205
2014-02-12 03:21:20 +00:00
Jonathan Roelofs 3fa96d8378 Revert 201202
Breaks cmake configure of new unit tests directory

llvm-svn: 201203
2014-02-12 01:36:51 +00:00
Jonathan Roelofs 0e7ec60b74 Add Multilib selection machinery
This patch improves the support for picking Multilibs from gcc installations.
It also provides a better approximation for the flags '-print-multi-directory'
and '-print-multi-lib'.

review: http://llvm-reviews.chandlerc.com/D2538
llvm-svn: 201202
2014-02-12 01:29:25 +00:00
NAKAMURA Takumi 02adf13ceb [CMake] clangDriver: Move LLVM stuff in target_link_library to LLVM_LINK_COMPONENTS.
llvm-svn: 196798
2013-12-09 19:04:19 +00:00
Alexey Samsonov 0c127d7c71 Re-apply r188666
llvm-svn: 188675
2013-08-19 13:59:22 +00:00
Alexey Samsonov cf0559644f Move SanitizerArgs implementation from .h to .cpp
llvm-svn: 187972
2013-08-08 10:11:02 +00:00
Reid Kleckner 898229ab4b [Driver] Refactor clang driver to use LLVM's Option library
The big changes are:
- Deleting Driver/(Arg|Opt)*
- Rewriting includes to llvm/Option/ and re-sorting
- 'using namespace llvm::opt' in clang::driver
- Fixing the autoconf build by adding option everywhere

As discussed in the review, this change includes using directives in
header files.  I'll make follow up changes to remove those in favor of
name specifiers.

Reviewers: espindola

Differential Revision: http://llvm-reviews.chandlerc.com/D975

llvm-svn: 183989
2013-06-14 17:17:23 +00:00
NAKAMURA Takumi 836926dbdf clang/lib: [CMake] Update tblgen'd dependencies.
llvm-svn: 160851
2012-07-27 06:18:33 +00:00
NAKAMURA Takumi 075c89bc06 clang/lib: [CMake] Reformat, alphabetize lists.
llvm-svn: 160850
2012-07-27 06:18:12 +00:00
Chandler Carruth 28969b4139 Remove a goofy CMake hack and use the standard CMake facilities to
express library-level dependencies within Clang.

This is no more verbose really, and plays nicer with the rest of the
CMake facilities. It should also have no change in functionality.

llvm-svn: 158888
2012-06-21 01:30:21 +00:00
Francois Pichet b27ea02784 Zap the /Za compiler switch from MSVC projects, the option is considered harmful even by Microsoft people and clang won't build using the MSVC 2012 RC if not removed.
Only 1 minor code change was necessary: can't use cdecl as variable name anymore.

llvm-svn: 158063
2012-06-06 12:00:10 +00:00
Jordan Rose 88bf06584b Remove AST and Parse from Driver's dependencies.
llvm-svn: 157933
2012-06-04 16:57:53 +00:00
Andrew Trick 4d77ceaa22 Speculatively fix windows cmake builders.
Really just a wild stab in the dark.

llvm-svn: 155974
2012-05-02 01:23:51 +00:00
James Molloy a3c85b8629 Unify Options.td and CC1Options.td, in a first step towards unifying the serialization logic in Frontend and Driver.
Reviewed by Eric, Doug and Chandler, and here: http://llvm.org/reviews/r/7/

llvm-svn: 155916
2012-05-01 14:57:16 +00:00
Chandler Carruth 2ad5de1f72 Delete the driver's HostInfo class. This abstraction just never really
did anything. The two big pieces of functionality it tried to provide
was to cache the ToolChain objects for each target, and to figure out
the exact target based on the flag set coming in to an invocation.
However, it had a lot of flaws even with those goals:
 - Neither of these have anything to do with the host, or its info.
 - The HostInfo class was setup as a full blown class *hierarchy* with
   a separate implementation for each "host" OS. This required
   dispatching just to create the objects in the first place.
 - The hierarchy claimed to represent the host, when in fact it was
   based on the target OS.
 - Each leaf in the hierarchy was responsible for implementing the flag
   processing and caching, resulting in a *lot* of copy-paste code and
   quite a few bugs.
 - The caching was consistently done based on architecture alone, even
   though *any* aspect of the targeted triple might change the behavior
   of the configured toolchain.
 - Flag processing was already being done in the Driver proper,
   separating the flag handling even more than it already is.

Instead of this, we can simply have the dispatch logic in the Driver
which previously created a HostInfo object create the ToolChain objects.
Adding caching in the Driver layer is a tiny amount of code. Finally,
pulling the flag processing into the Driver puts it where it belongs and
consolidates it in one location.

The result is that two functions, and maybe 100 lines of new code
replace over 10 classes and 800 lines of code. Woot.

This also paves the way to introduce more detailed ToolChain objects for
various OSes without threading through a new HostInfo type as well, and
the accompanying boiler plate. That, of course, was the yak I started to
shave that began this entire refactoring escapade. Wheee!

llvm-svn: 148950
2012-01-25 11:01:57 +00:00
Chandler Carruth 1fc603e516 Split the Windows toolchain definition into its own file. This is
especially nice as the Windows toolchain needs the windows header files,
and has lots of platform specific hooks in it.

To facilitate the split, hoist a bunch of file-level static helpers into
class-level static helpers. Spiff up their doxygen comments while there
as they're now more likely to be looked up via docs.

Hopefully, this will be followed by further breaking apart of the
toolchain definitions. Most of the large and complex ones should likely
live on their own. I'm looking at you Darwin. ;]

llvm-svn: 146840
2011-12-17 23:10:01 +00:00
Michael J. Spencer 85da676885 Fix MSVC build.
llvm-svn: 143770
2011-11-05 00:46:46 +00:00
NAKAMURA Takumi 98dd73d66c CMake: LLVM_NO_RTTI must be obsolete now!
llvm-svn: 125275
2011-02-10 09:15:32 +00:00