Commit Graph

58 Commits

Author SHA1 Message Date
Sam Clegg 471d7afdf0 [WebAssembly] Add crt1.o with calling lld
Also, for OS unknown targets like wasm, don't include
'unknown' in the library path. This is a fix for rL316719.

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

llvm-svn: 316777
2017-10-27 18:10:19 +00:00
Sam Clegg a08631ec6c [WebAssembly] Include libclang_rt.builtins in the standard way
Differential Revision: https://reviews.llvm.org/D39218

llvm-svn: 316719
2017-10-27 00:26:07 +00:00
Sam Clegg 6b396c2c22 [WebAssembly] Remove invliad lld arguments
These arguments don't (not yet at least) make sense for
the wasm lld port.

Subscribers: jfb, dschuff, jgravelle-google, aheejin

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

llvm-svn: 313299
2017-09-14 21:29:25 +00:00
Nico Weber 0ee47d92b2 Introduce -nostdlib++ flag to disable linking the C++ standard library.
Projects that want to statically link their own C++ standard library currently
need to pass -nostdlib or -nodefaultlibs, which also disables linking of the
builtins library, -lm, and so on. Alternatively, they could use `clang` instead
of `clang++`, but that already disables implicit addition of -lm on some
toolchains.

Add a dedicated flag -nostdlib++ that disables just linking of libc++ /
libstdc++. This is analogous to -nostdinc++.

https://reviews.llvm.org/D35780

llvm-svn: 308997
2017-07-25 18:02:57 +00:00
Gheorghe-Teodor Bercea f0f29608d0 [OpenMP] Extend CLANG target options with device offloading kind.
Summary: Pass the type of the device offloading when building the tool chain for a particular target architecture. This is required when supporting multiple tool chains that target a single device type. In our particular use case, the OpenMP and CUDA tool chains will use the same ```addClangTargetOptions ``` method. This enables the reuse of common options and ensures control over options only supported by a particular tool chain.

Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar, Hahnfeld

Reviewed By: hfinkel

Subscribers: jgravelle-google, aheejin, rengolin, jfb, dschuff, sbc100, cfe-commits

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

llvm-svn: 307272
2017-07-06 16:22:21 +00:00
Sam Clegg 8202e86a99 [WebAssembly] Add default -allow-undefined-file to linker args
Also, don't use the outdated lib32/lib64 naming of files
within the sysroot. The more modern/flexible approach
IIUC is to use seperate sysroots or /lib/<target-tripple>
and /include/<target-tripple>.

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

llvm-svn: 306074
2017-06-23 00:02:55 +00:00
Sam Clegg 27ea1567a4 [WebAssembly] Fix location and -flavor when running lld
Add the toolchain installation directory to the program
path so that lld can be found.

Change -flavor to wasm.  Although this new flavor hasn't
yet landed in upstream lld yet there are no point in
passing wasm objects the gnu flavor.

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

llvm-svn: 302558
2017-05-09 17:47:50 +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