summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/WebAssembly.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [WebAssembly] Remove invliad lld argumentsSam Clegg2017-09-141-27/+0
| | | | | | | | | | | 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
* Introduce -nostdlib++ flag to disable linking the C++ standard library.Nico Weber2017-07-251-2/+1
| | | | | | | | | | | | | | | 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
* [OpenMP] Extend CLANG target options with device offloading kind.Gheorghe-Teodor Bercea2017-07-061-1/+2
| | | | | | | | | | | | | | 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
* [WebAssembly] Add default -allow-undefined-file to linker argsSam Clegg2017-06-231-2/+3
| | | | | | | | | | | 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
* [WebAssembly] Fix location and -flavor when running lldSam Clegg2017-05-091-1/+4
| | | | | | | | | | | | | 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
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-0/+163
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
OpenPOWER on IntegriCloud