summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend
Commit message (Collapse)AuthorAgeFilesLines
...
* Initialize builtins during modular codegenDavid Blaikie2017-02-081-0/+3
| | | | llvm-svn: 294512
* Enable -dump-deserialized-decls and -error-on-deserialized-decl for modules.Vassil Vassilev2017-02-071-16/+22
| | | | llvm-svn: 294359
* Modules: Simplify CompilerInstance constructor, NFCDuncan P. N. Exon Smith2017-02-021-4/+1
| | | | | | | Initialize fields directly in header. Note that the ModuleManager field is an IntrusiveRefCntPtr, so there's no need for explicit initialization. llvm-svn: 293863
* [X86] Teach Clang about -mfentry flagNirav Dave2017-01-311-0/+1
| | | | | | | | | | | | Replace mcount calls with calls to fentry. Reviewers: hfinkel, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28001 llvm-svn: 293649
* [c-index-test] Provide capability to index module file imports and dump ↵Argyrios Kyrtzidis2017-01-301-0/+4
| | | | | | | | their input files. This ensures the capability to index a module file using an existing ASTReader from a compiler instance or ASTUnit. llvm-svn: 293461
* Prototype of modules codegenDavid Blaikie2017-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | First pass at generating weak definitions of inline functions from module files (& skipping (-O0) or emitting available_externally (optimizations) definitions where those modules are used). External functions defined in modules are emitted into the modular object file as well (this may turn an existing ODR violation (if that module were imported into multiple translations) into valid/linkable code). Internal symbols (static functions, for example) are not correctly supported yet. The symbol will be produced, internal, in the modular object - unreferenceable from the users. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D28845 llvm-svn: 293456
* Pass a char instead of a string to the find function. clang-tidy: ↵Sylvestre Ledru2017-01-282-2/+2
| | | | | | performance-faster-string-find llvm-svn: 293379
* [CodeGen] [CUDA] Add the ability set default attrs on functions in linked ↵Justin Lebar2017-01-251-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | modules. Summary: Now when you ask clang to link in a bitcode module, you can tell it to set attributes on that module's functions to match what we would have set if we'd emitted those functions ourselves. This is particularly important for fast-math attributes in CUDA compilations. Each CUDA compilation links in libdevice, a bitcode library provided by nvidia as part of the CUDA distribution. Without this patch, if we have a user-function F that is compiled with -ffast-math that calls a function G from libdevice, F will have the unsafe-fp-math=true (etc.) attributes, but G will have no attributes. Since F calls G, the inliner will merge G's attributes into F's. It considers the lack of an unsafe-fp-math=true attribute on G to be tantamount to unsafe-fp-math=false, so it "merges" these by setting unsafe-fp-math=false on F. This then continues up the call graph, until every function that (transitively) calls something in libdevice gets unsafe-fp-math=false set, thus disabling fastmath in almost all CUDA code. Reviewers: echristo Subscribers: hfinkel, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D28538 llvm-svn: 293097
* Revert "Use filename in linemarker when compiling preprocessed source"Diana Picus2017-01-251-46/+2
| | | | | | | | | | | | | | | | | | | | | This reverts commit r293004 because it broke the buildbots with "unknown CPU" errors. I tried to fix it in r293026, but that broke on Green Dragon with this kind of error: error: expected string not found in input // CHECK: l{{ +}}df{{ +}}*ABS*{{ +}}{{0+}}{{.+}}preprocessed-input.c{{$}} ^ <stdin>:2:1: note: scanning from here /Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o: file format Mach-O 64-bit x86-64 ^ <stdin>:2:67: note: possible intended match here /Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o: file format Mach-O 64-bit x86-64 I suppose this means that llvm-objdump doesn't support Mach-O, so the test should indeed check for linux (but not for x86). I'll leave it to someone that knows better. llvm-svn: 293032
* Use filename in linemarker when compiling preprocessed sourceDavid Callahan2017-01-251-2/+46
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Clang appears to always use name as specified on the command line, whereas gcc uses the name as specified in the linemarker at the first line when compiling a preprocessed source. This results mismatch between two compilers in FILE symbol table entry. This patch makes clang to resemble gcc's behavior in finding the original source file name and use it as an input file name. Even with this patch, values of FILE symbol table entry may still be different because clang uses dirname+basename for the entry whlie gcc uses basename only. I'll write a patch for that once this patch is committed. Reviewers: dblaikie, inglorion Reviewed By: inglorion Subscribers: inglorion, aprantl, bruno Differential Revision: https://reviews.llvm.org/D28796 llvm-svn: 293004
* [Frontend] The macro that describes the Objective-C bool type shouldAlex Lorenz2017-01-201-3/+5
| | | | | | | | | | be defined for non Objective-C code as well rdar://29794915 Differential Revision: https://reviews.llvm.org/D28349 llvm-svn: 292617
* Add -fdebug-info-for-profiling to emit more debug info for sample pgo ↵Dehao Chen2017-01-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | profile collection Summary: SamplePGO uses profile with debug info to collect profile. Unlike the traditional debugging purpose, sample pgo needs more accurate debug info to represent the profile. We add -femit-accurate-debug-info for this purpose. It can be combined with all debugging modes (-g, -gmlt, etc). It makes sure that the following pieces of info is always emitted: * start line of all subprograms * linkage name of all subprograms * standalone subprograms (functions that has neither inlined nor been inlined) The impact on speccpu2006 binary size (size increase comparing with -g0 binary, also includes data for -g binary, which does not change with this patch): -gmlt(orig) -gmlt(patched) -g 433.milc 4.68% 5.40% 19.73% 444.namd 8.45% 8.93% 45.99% 447.dealII 97.43% 115.21% 374.89% 450.soplex 27.75% 31.88% 126.04% 453.povray 21.81% 26.16% 92.03% 470.lbm 0.60% 0.67% 1.96% 482.sphinx3 5.77% 6.47% 26.17% 400.perlbench 17.81% 19.43% 73.08% 401.bzip2 3.73% 3.92% 12.18% 403.gcc 31.75% 34.48% 122.75% 429.mcf 0.78% 0.88% 3.89% 445.gobmk 6.08% 7.92% 42.27% 456.hmmer 10.36% 11.25% 35.23% 458.sjeng 5.08% 5.42% 14.36% 462.libquantum 1.71% 1.96% 6.36% 464.h264ref 15.61% 16.56% 43.92% 471.omnetpp 11.93% 15.84% 60.09% 473.astar 3.11% 3.69% 14.18% 483.xalancbmk 56.29% 81.63% 353.22% geomean 15.60% 18.30% 57.81% Debug info size change for -gmlt binary with this patch: 433.milc 13.46% 444.namd 5.35% 447.dealII 18.21% 450.soplex 14.68% 453.povray 19.65% 470.lbm 6.03% 482.sphinx3 11.21% 400.perlbench 8.91% 401.bzip2 4.41% 403.gcc 8.56% 429.mcf 8.24% 445.gobmk 29.47% 456.hmmer 8.19% 458.sjeng 6.05% 462.libquantum 11.23% 464.h264ref 5.93% 471.omnetpp 31.89% 473.astar 16.20% 483.xalancbmk 44.62% geomean 16.83% Reviewers: davidxl, andreadb, rob.lougher, dblaikie, echristo Reviewed By: dblaikie, echristo Subscribers: hfinkel, rob.lougher, andreadb, gbedwell, cfe-commits, probinson, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D25435 llvm-svn: 292458
* Move vtable type metadata emission behind a cc1-level flag.Peter Collingbourne2017-01-181-0/+1
| | | | | | | | | | | | | In ThinLTO mode, type metadata will require the module to be written as a multi-module bitcode file, which is currently incompatible with the Darwin linker. It is also useful to be able to enable or disable multi-module bitcode for testing purposes. This introduces a cc1-level flag, -f{,no-}lto-unit, which is used by the driver to enable multi-module bitcode on all but Darwin+ThinLTO, and can also be used to enable/disable the feature manually. Differential Revision: https://reviews.llvm.org/D28877 llvm-svn: 292448
* [ASTUnit] Reset diag state when creating the ASTUnit.Benjamin Kramer2017-01-181-0/+1
| | | | | | A client could call this with a dirty diagnostic engine, don't crash. llvm-svn: 292406
* Fix PR31644 introduced by r287138 and add a regression test.Yaron Keren2017-01-141-2/+2
| | | | | | Thanks Dimitry Andric for the report and fix! llvm-svn: 292032
* unique_ptrify createDriverOptTableDavid Blaikie2017-01-131-1/+1
| | | | llvm-svn: 291919
* [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtinMichal Gorny2017-01-091-6/+4
| | | | | | | | | | | | | | | | | | | | | | | Correct the logic used to set ATOMIC_*_LOCK_FREE preprocessor macros not to rely on the ABI alignment of types. Instead, just assume all those types are aligned correctly by default since clang uses safe alignment for _Atomic types even if the underlying types are aligned to a lower boundary by default. For example, the 'long long' and 'double' types on x86 are aligned to 32-bit boundary by default. However, '_Atomic long long' and '_Atomic double' are aligned to 64-bit boundary, therefore satisfying the requirements of lock-free atomic operations. This fixes PR #19355 by correcting the value of __GCC_ATOMIC_LLONG_LOCK_FREE on x86, and therefore also fixing the assumption made in libc++ tests. This also fixes PR #30581 by applying a consistent logic between the functions used to implement both interfaces. Differential Revision: https://reviews.llvm.org/D28213 llvm-svn: 291477
* PCH: fix a regression that reports a module is defined in both pch and pcm.Manman Ren2017-01-091-0/+6
| | | | | | | | | | | | | | | | | In r276159, we started to say that a module X is defined in a pch if we specify -fmodule-name when building the pch. This caused a regression that reports module X is defined in both pch and pcm if we generate the pch with -fmodule-name=X and then in a separate clang invocation, we include the pch and also import X.pcm. This patch adds an option CompilingPCH similar to CompilingModule. When we use -fmodule-name=X while building a pch, modular headers in X will be textually included and the compiler knows that we are not building module X, so we don't put module X in SUBMODULE_DEFINITION of the pch. Differential Revision: http://reviews.llvm.org/D28415 llvm-svn: 291465
* Add a cc1 option to force disabling lifetime-markers emission from clangMehdi Amini2017-01-061-0/+1
| | | | | | | | Summary: This intended as a debugging/development flag only. Differential Revision: https://reviews.llvm.org/D28385 llvm-svn: 291300
* Reapply "IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase ↵David Blaikie2017-01-065-52/+48
| | | | | | | | | | | | | | and CodeCompleteConsumer" Aleksey Shlypanikov pointed out my mistake in migrating an explicit unique_ptr to auto - I was expecting the function returned a unique_ptr, but instead it returned a raw pointer - introducing a leak. Thanks Aleksey! This reapplies r291184, reverted in r291249. llvm-svn: 291270
* Revert "IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and ↵David Blaikie2017-01-065-48/+52
| | | | | | | | | | CodeCompleteConsumer" Caused a memory leak reported by asan. Reverting while I investigate. This reverts commit r291184. llvm-svn: 291249
* shared_ptrify (from InclusiveRefCntPtr) HeaderSearchOptionsDavid Blaikie2017-01-062-6/+4
| | | | llvm-svn: 291202
* IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and ↵David Blaikie2017-01-055-52/+48
| | | | | | CodeCompleteConsumer llvm-svn: 291184
* Move SerializedDiagnosticPrinter's SharedState to std::shared_ptr rather ↵David Blaikie2017-01-051-4/+4
| | | | | | than IntrusiveRefCntPtr llvm-svn: 291167
* Move Preprocessor over to std::shared_ptr rather than IntrusiveRefCntPtrDavid Blaikie2017-01-053-13/+17
| | | | llvm-svn: 291166
* Move PreprocessorOptions to std::shared_ptr from IntrusiveRefCntPtrDavid Blaikie2017-01-052-8/+9
| | | | llvm-svn: 291160
* Move FailedModulesSet over to shared_ptr from IntrusiveRefCntPtrDavid Blaikie2017-01-051-1/+2
| | | | llvm-svn: 291159
* Use shared_ptr instead of IntrusiveRefCntPtr for ModuleFileExtensionDavid Blaikie2017-01-054-5/+5
| | | | | | | The intrusiveness wasn't needed here, so this simplifies/clarifies the ownership model. llvm-svn: 291150
* Fix for LLVM Bitcode API change (to use std::shared_ptr)David Blaikie2017-01-042-18/+18
| | | | llvm-svn: 291018
* Add -f[no-]strict-return flag that can be used to avoid undefined behaviourAlex Lorenz2017-01-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | in non-void functions that fall off at the end without returning a value when compiling C++. Clang uses the new compiler flag to determine when it should treat control flow paths that fall off the end of a non-void function as unreachable. If -fno-strict-return is on, the code generator emits the ureachable and trap IR only when the function returns either a record type with a non-trivial destructor or another non-trivially copyable type. The primary goal of this flag is to avoid treating falling off the end of a non-void function as undefined behaviour. The burden of undefined behaviour is placed on the caller instead: if the caller ignores the returned value then the undefined behaviour is avoided. This kind of behaviour is useful in several cases, e.g. when compiling C code in C++ mode. rdar://13102603 Differential Revision: https://reviews.llvm.org/D27163 llvm-svn: 290960
* Handle StaticAssertDecl in DeclContextPrinterAlex Lorenz2017-01-031-0/+4
| | | | | | | | | | | This commit fixes a crash that occurs when -print-decl-contexts AST consumer tries to print an unhandled declaration. rdar://19467234 Differential Revision: https://reviews.llvm.org/D26964 llvm-svn: 290887
* Handle VarTemplateDecl in DeclContextPrinterAlex Lorenz2017-01-031-0/+4
| | | | | | | | | | | This commit fixes a crash that occurs when -print-decl-contexts AST consumer tries to print an unhandled declaration. rdar://19467234 Differential Revision: https://reviews.llvm.org/D26964 llvm-svn: 290886
* Handle AccessSpecDecl in DeclContextPrinterAlex Lorenz2017-01-031-0/+4
| | | | | | | | | | | This commit fixes a crash that occurs when -print-decl-contexts AST consumer tries to print an unhandled declaration. rdar://19467234 Differential Revision: https://reviews.llvm.org/D26964 llvm-svn: 290885
* Handle ClassTemplateSpecializationDecl in DeclContextPrinterAlex Lorenz2017-01-031-1/+22
| | | | | | | | | | | This commit fixes a crash that occurs when -print-decl-contexts AST consumer tries to print an unhandled declaration. rdar://19467234 Differential Revision: https://reviews.llvm.org/D26964 llvm-svn: 290884
* Handle EmptyDecl in DeclContextPrinterAlex Lorenz2017-01-031-0/+4
| | | | | | | | | | | This commit fixes a crash that occurs when -print-decl-contexts AST consumer tries to print an unhandled declaration. rdar://19467234 Differential Revision: https://reviews.llvm.org/D26964 llvm-svn: 290882
* Handle UsingDecl and UsingShadowDecl in DeclContextPrinterAlex Lorenz2017-01-031-0/+8
| | | | | | | | | | | This commit fixes a crash that occurs when -print-decl-contexts AST consumer tries to print an unhandled declaration. rdar://19467234 Differential Revision: https://reviews.llvm.org/D26964 llvm-svn: 290881
* Handle FriendDecl in DeclContextPrinterAlex Lorenz2017-01-031-0/+7
| | | | | | | | | | | This commit fixes a crash that occurs when -print-decl-contexts AST consumer tries to print an unhandled declaration. rdar://19467234 Differential Revision: https://reviews.llvm.org/D26964 llvm-svn: 290880
* [c++17] Implement P0522R0 as written. This allows a template template argumentRichard Smith2016-12-311-0/+2
| | | | | | | | | | | | | | | | | | | to be specified for a template template parameter whenever the parameter is at least as specialized as the argument (when there's an obvious and correct mapping from uses of the parameter to uses of the argument). For example, a template with more parameters can be passed to a template template parameter with fewer, if those trailing parameters have default arguments. This is disabled by default, despite being a DR resolution, as it's fairly broken in its current state: there are no partial ordering rules to cope with template template parameters that have different parameter lists, meaning that code that attempts to decompose template-ids based on arity can hit unavoidable ambiguity issues. The diagnostics produced on a non-matching argument are also pretty bad right now, but I aim to improve them in a subsequent commit. llvm-svn: 290792
* [PM] Introduce options to enable the (still experimental) new passChandler Carruth2016-12-231-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | manager, and a code path to use it. The option is actually a top-level option but does contain 'experimental' in the name. This is the compromise suggested by Richard in discussions. We expect this option will be around long enough and have enough users towards the end that it merits not being relegated to CC1, but it still needs to be clear that this option will go away at some point. The backend code is a fresh codepath dedicated to handling the flow with the new pass manager. This was also Richard's suggested code structuring to essentially leave a clean path for development rather than carrying complexity or idiosyncracies of how we do things just to share code with the parts of this in common with the legacy pass manager. And it turns out, not much is really in common even though we use the legacy pass manager for codegen at this point. I've switched a couple of tests to run with the new pass manager, and they appear to work. There are still plenty of bugs that need squashing (just with basic experiments I've found two already!) but they aren't in this code, and the whole point is to expose the necessary hooks to start experimenting with the pass manager in more realistic scenarios. That said, I want to *strongly caution* anyone itching to play with this: it is still *very shaky*. Several large components have not yet been shaken down. For example I have bugs in both the always inliner and inliner that I have already spotted and will be fixing independently. Still, this is a fun milestone. =D One thing not in this patch (but that might be very reasonable to add) is some level of support for raw textual pass pipelines such as what Sean had a patch for some time ago. I'm mostly interested in the more traditional flow of getting the IR out of Clang and then running it through opt, but I can see other use cases so someone may want to add it. And of course, *many* features are not yet supported! - O1 is currently more like O2 - None of the sanitizers are wired up - ObjC ARC optimizer isn't wired up - ... So plenty of stuff still lef to do! Differential Revision: https://reviews.llvm.org/D28077 llvm-svn: 290450
* Cleanup the handling of noinline function attributes, -fno-inline,Chandler Carruth2016-12-231-17/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
* Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.Chandler Carruth2016-12-231-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Much to my surprise, '-disable-llvm-optzns' which I thought was the magical flag I wanted to get at the raw LLVM IR coming out of Clang deosn't do that. It still runs some passes over the IR. I don't want that, I really want the *raw* IR coming out of Clang and I strongly suspect everyone else using it is in the same camp. There is actually a flag that does what I want that I didn't know about called '-disable-llvm-passes'. I suspect many others don't know about it either. It both does what I want and is much simpler. This removes the confusing version and makes that spelling of the flag an alias for '-disable-llvm-passes'. I've also moved everything in Clang to use the 'passes' spelling as it seems both more accurate (*all* LLVM passes are disabled, not just optimizations) and much easier to remember and spell correctly. This is part of simplifying how Clang drives LLVM to make it cleaner to wire up to the new pass manager. Differential Revision: https://reviews.llvm.org/D28047 llvm-svn: 290392
* [CrashReproducer] Add support for merging -ivfsoverlayBruno Cardoso Lopes2016-12-222-14/+48
| | | | | | | | | | | Merge all VFS mapped files inside -ivfsoverlay inputs into the vfs overlay provided by the crash reproducer. This is the last missing piece to allow crash reproducers to fully work with user frameworks; when combined with headermaps, it allows clang to find additional frameworks. rdar://problem/27913709 llvm-svn: 290326
* Revert another accidental bitPaul Robinson2016-12-191-2/+0
| | | | llvm-svn: 290125
* Undo accidental comitPaul Robinson2016-12-191-0/+2
| | | | llvm-svn: 290121
* Add __cpp_structured_bindings feature test macro for structured bindings, perRichard Smith2016-12-191-0/+1
| | | | | | latest (provisional) draft of SD-6. llvm-svn: 290082
* [c++1z] cxx_status: mark p0195r2 as done.Richard Smith2016-12-191-0/+1
| | | | llvm-svn: 290081
* Recommit r289979 [OpenCL] Allow disabling types and declarations associated ↵Yaxun Liu2016-12-181-1/+1
| | | | | | | | with extensions Fixed undefined behavior due to cast integer to bool in initializer list. llvm-svn: 290056
* Revert r289979 due to regressionsYaxun Liu2016-12-161-1/+1
| | | | llvm-svn: 289991
* [OpenCL] Allow disabling types and declarations associated with extensionsYaxun Liu2016-12-161-1/+1
| | | | | | | | | | | | | | | | | | Added a map to associate types and declarations with extensions. Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation. Fixed some bugs for types associated with extensions. Allow users to use pragma to declare types and functions for supported extensions, e.g. #pragma OPENCL EXTENSION the_new_extension_name : begin // declare types and functions associated with the extension here #pragma OPENCL EXTENSION the_new_extension_name : end Differential Revision: https://reviews.llvm.org/D21698 llvm-svn: 289979
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-5/+5
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
OpenPOWER on IntegriCloud