summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert r326946. It caused stack overflows by significantly increasing the ↵Richard Smith2018-03-101-16/+0
| | | | | | size of a CallArgList. llvm-svn: 327195
* CodeGen: Fix address space of indirect function argumentYaxun Liu2018-03-071-0/+16
| | | | | | | | | | | | | | | | | | | | | The indirect function argument is in alloca address space in LLVM IR. However, during Clang codegen for C++, the address space of indirect function argument should match its address space in the source code, i.e., default addr space, even for indirect argument. This is because destructor of the indirect argument may be called in the caller function, and address of the indirect argument may be taken, in either case the indirect function argument is expected to be in default addr space, not the alloca address space. Therefore, the indirect function argument should be mapped to the temp var casted to default address space. The caller will cast it to alloca addr space when passing it to the callee. In the callee, the argument is also casted to the default address space and used. CallArg is refactored to facilitate this fix. Differential Revision: https://reviews.llvm.org/D34367 llvm-svn: 326946
* Start setting dllimport/dllexport in setGVProperties.Rafael Espindola2018-03-011-7/+0
| | | | | | | | | | This is the next step in setting dso_local for COFF. The patches changes setGVProperties to first set dllimport/dllexport and changes a few cases that were setting dllimport/dllexport manually. With this a few more GVs are marked dso_local. llvm-svn: 326397
* [ObjC] Allow declaring __strong pointer fields in structs in Objective-CAkira Hatanaka2018-02-281-3/+25
| | | | | | | | | | | | | | | | | | | | | ARC mode. Declaring __strong pointer fields in structs was not allowed in Objective-C ARC until now because that would make the struct non-trivial to default-initialize, copy/move, and destroy, which is not something C was designed to do. This patch lifts that restriction. Special functions for non-trivial C structs are synthesized that are needed to default-initialize, copy/move, and destroy the structs and manage the ownership of the objects the __strong pointer fields point to. Non-trivial structs passed to functions are destructed in the callee function. rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D41228 llvm-svn: 326307
* Bring r325915 back.Rafael Espindola2018-02-231-1/+2
| | | | | | | | | | | | | | | The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
* Revert "Start setting dso_local for COFF."Rafael Espindola2018-02-231-2/+1
| | | | | | | | This reverts commit r325915. It will take some time to fix the failures on a windows host. llvm-svn: 325929
* Start setting dso_local for COFF.Rafael Espindola2018-02-231-1/+2
| | | | | | | | | With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325915
* CodeGen: handle blocks correctly when inalloca'edSaleem Abdulrasool2018-02-211-2/+5
| | | | | | | | | | When using blocks with C++ on Windows x86, it is possible to have the block literal be pushed into the inalloca'ed parameters. Teach IRGen to handle the case properly by extracting the block literal from the inalloca parameter. This fixes the use of blocks with C++ on Windows x86. llvm-svn: 325724
* [DebugInfo] Avoid name conflict of generated VLA expression variable.Sander de Smalen2018-02-131-2/+3
| | | | | | | | | | | | | | | | | Summary: This patch also adds the 'DW_AT_artificial' flag to the generated variable. Addresses the issues mentioned in http://llvm.org/PR30553. Reviewers: CarlosAlbertoEnciso, probinson, aprantl Reviewed By: aprantl Subscribers: JDevlieghere, cfe-commits Differential Revision: https://reviews.llvm.org/D43189 llvm-svn: 324988
* Fix crash on array initializer with non-0 alloca addrspaceMatt Arsenault2018-02-081-1/+2
| | | | llvm-svn: 324641
* Recommit r324107 again.Rafael Espindola2018-02-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
* Revert "Recommit r324107."Rafael Espindola2018-02-071-2/+1
| | | | | | | | | | | | | | This reverts commit r324500. The bots found two failures: ThreadSanitizer-x86_64 :: Linux/pie_no_aslr.cc ThreadSanitizer-x86_64 :: pie_test.cc when using gold. The issue is a limitation in gold when building pie binaries. I will investigate how to work around it. llvm-svn: 324505
* Recommit r324107.Rafael Espindola2018-02-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324500
* Don't pass ForDefinition_t in places it is redundant.Rafael Espindola2018-02-071-1/+1
| | | | | | | | | | | | | | I found this while looking at the ppc failures caused by the dso_local change. The issue was that the patch would produce the wrong answer for available_externally. Having ForDefinition_t available in places where the code can just check the linkage is a bit of a foot gun. This patch removes the ForDefiniton_t argument in places where the linkage is already know. llvm-svn: 324499
* Add support for attribute 'trivial_abi'.Akira Hatanaka2018-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
* Recommit rL323952: [DebugInfo] Enable debug information for C99 VLA types.Sander de Smalen2018-02-031-14/+68
| | | | | | Fixed build issue when building with g++-4.8 (specialization after instantiation). llvm-svn: 324173
* Revert "Start setting dso_local in clang."Rafael Espindola2018-02-021-2/+1
| | | | | | | | This reverts commit r324107. I will have to test it on OS X. llvm-svn: 324108
* Start setting dso_local in clang.Rafael Espindola2018-02-021-1/+2
| | | | | | | | | | | | | | | | This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324107
* Reverting patch rL323952 due to build errors that ISander de Smalen2018-02-011-68/+14
| | | | | | haven't encountered in local builds. llvm-svn: 323956
* [DebugInfo] Enable debug information for C99 VLA typesSander de Smalen2018-02-011-14/+68
| | | | | | | | | | | | | | | | | | | | | Summary: This patch enables debugging of C99 VLA types by generating more precise LLVM Debug metadata, using the extended DISubrange 'count' field that takes a DIVariable. This should implement: Bug 30553: Debug info generated for arrays is not what GDB expects (not as good as GCC's) https://bugs.llvm.org/show_bug.cgi?id=30553 Reviewers: echristo, aprantl, dexonsmith, clayborg, pcc, kristof.beyls, dblaikie Reviewed By: aprantl Subscribers: jholewinski, schweitz, davide, fhahn, JDevlieghere, cfe-commits Differential Revision: https://reviews.llvm.org/D41698 llvm-svn: 323952
* Reland "Fix vtable not receiving hidden visibility when using push(visibility)"Jake Ehrlich2017-11-291-1/+1
| | | | | | | | | | I had to reland this change in order to make the test work on windows This change should resolve https://bugs.llvm.org/show_bug.cgi?id=35022 https://reviews.llvm.org/D39627 llvm-svn: 319269
* Revert "[CodeGen] Fix vtable not receiving hidden visibility when using ↵Petr Hosek2017-11-221-1/+1
| | | | | | | | push(visibility)" This reverts commit r318853: tests are failing on Windows bots llvm-svn: 318866
* [CodeGen] Fix vtable not receiving hidden visibility when using push(visibility)Petr Hosek2017-11-221-1/+1
| | | | | | | | | | This change should resolve https://bugs.llvm.org/show_bug.cgi?id=35022 Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D39627 llvm-svn: 318853
* [MS] Apply adjustments after storing 'this'Reid Kleckner2017-11-161-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MS ABI convention is that the 'this' pointer on entry is the address of the vfptr that was used to make the virtual method call. In other words, the pointer on entry always points to the base subobject that introduced the virtual method. Consider this hierarchy: struct A { virtual void f() = 0; }; struct B { virtual void g() = 0; }; struct C : A, B { void f() override; void g() override; }; On entry to C::g, [ER]CX will contain the address of C's B subobject, and C::g will have to subtract sizeof(A) to recover a pointer to C. Before this change, we applied this adjustment in the prologue and stored the new value into the "this" local variable alloca used for debug info. However, MSVC does not do this, presumably because it is often profitable to fold the adjustment into later field accesses. This creates a problem, because the debugger expects the variable to be unadjusted. Unfortunately, CodeView doesn't have anything like DWARF expressions for computing variables that aren't in the program anymore, so we have to declare 'this' to be the unadjusted value if we want the debugger to see the right value. This has the side benefit that, in optimized builds, the 'this' pointer will usually be available on function entry because it doesn't require any adjustment. Reviewers: hans Subscribers: aprantl, cfe-commits Differential Revision: https://reviews.llvm.org/D40109 llvm-svn: 318440
* [OpenCL] Fix code generation of function-scope constant samplers.Alexey Bader2017-11-151-0/+4
| | | | | | | | | | | | | | | | | Summary: Constant samplers are handled as static variables and clang's code generation library, which leads to llvm::unreachable. We bypass emitting sampler variable as static since it's translated to a function call later. Reviewers: yaxunl, Anastasia Reviewed By: yaxunl, Anastasia Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34342 llvm-svn: 318290
* CodeGen: Fix invalid bitcast in partial initialization of automatic arrary ↵Yaxun Liu2017-10-231-1/+1
| | | | | | | | variable Differential Revision: https://reviews.llvm.org/D39184 llvm-svn: 316353
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Convert clang::LangAS to a strongly typed enum Currently both clang AST address spaces and target specific address spaces are represented as unsigned which can lead to subtle errors if the wrong type is passed. It is especially confusing in the CodeGen files as it is not possible to see what kind of address space should be passed to a function without looking at the implementation. I originally made this change for our LLVM fork for the CHERI architecture where we make extensive use of address spaces to differentiate between capabilities and pointers. When merging the upstream changes I usually run into some test failures or runtime crashes because the wrong kind of address space is passed to a function. By converting the LangAS enum to a C++11 we can catch these errors at compile time. Additionally, it is now obvious from the function signature which kind of address space it expects. I found the following errors while writing this patch: - ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address space to TargetInfo::getPointer{Width,Align}() - TypePrinter::printAttributedAfter() prints the numeric value of the clang AST address space instead of the target address space. However, this code is not used so I kept the current behaviour - initializeForBlockHeader() in CGBlocks.cpp was passing LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}() - CodeGenFunction::EmitBlockLiteral() was passing a AST address space to TargetInfo::getPointerWidth() - CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space to Qualifiers::addAddressSpace() - CGOpenMPRuntimeNVPTX::getParameterAddress() was using llvm::Type::getPointerTo() with a AST address space - clang_getAddressSpace() returns either a LangAS or a target address space. As this is exposed to C I have kept the current behaviour and added a comment stating that it is probably not correct. Other than this the patch should not cause any functional changes. Reviewers: yaxunl, pcc, bader Reviewed By: yaxunl, bader Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D38816 llvm-svn: 315871
* [OpenCL] Add LangAS::opencl_private to represent private address space in ASTYaxun Liu2017-10-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
* Extract IRGen's constant-emitter into its own helper class and clean upJohn McCall2017-08-151-2/+6
| | | | | | | | | | | | the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
* CodeGen: Fix address space of global variableYaxun Liu2017-07-081-12/+10
| | | | | | | | | | | | | Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
* CodeGen: load indirect ObjC ARC arguments in prologueSaleem Abdulrasool2017-06-271-0/+4
| | | | | | | | | When generating a prologue, add loads for ARC arguments passed indirectly. Patch by Dave Lee! llvm-svn: 306444
* CodeGen: Cast temporary variable to proper address spaceYaxun Liu2017-06-191-21/+3
| | | | | | | | | | | | | | | | In C++ all variables are in default address space. Previously change has been made to cast automatic variables to default address space. However that is not sufficient since all temporary variables need to be casted to default address space. This patch casts all temporary variables to default address space except those for passing indirect arguments since they are only used for load/store. This patch only affects target having non-zero alloca address space. Differential Revision: https://reviews.llvm.org/D33706 llvm-svn: 305711
* Add support for #pragma clang sectionJaved Absar2017-06-051-0/+7
| | | | | | | | | | | | | | | This patch provides a means to specify section-names for global variables, functions and static variables, using #pragma directives. This feature is only defined to work sensibly for ELF targets. One can specify section names as: #pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText" One can "unspecify" a section name with empty string e.g. #pragma clang section bss="" data="" text="" rodata="" Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D33412 llvm-svn: 304705
* CodeGen: Cast alloca to expected address spaceYaxun Liu2017-05-181-1/+17
| | | | | | | | | | | Alloca always returns a pointer in alloca address space, which may be different from the type defined by the language. For example, in C++ the auto variables are in the default address space. Therefore cast alloca to the expected address space when necessary. Differential Revision: https://reviews.llvm.org/D32248 llvm-svn: 303370
* [OpenCL] Emit function-scope variable in constant address space as static ↵Yaxun Liu2017-05-151-5/+8
| | | | | | | | variable Differential Revision: https://reviews.llvm.org/D32977 llvm-svn: 303072
* CodeGen: Let lifetime intrinsic use alloca address spaceYaxun Liu2017-04-171-4/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D31717 llvm-svn: 300485
* [ObjC] Fix lifetime markers of loop variable in EmitObjCForCollectionStmt ↵Kuba Mracek2017-04-141-7/+6
| | | | | | | | | | [take 2] CodeGenFunction::EmitObjCForCollectionStmt currently emits lifetime markers for the loop variable in an inconsistent way: lifetime.start is emitted before the loop is entered, but lifetime.end is emitted inside the loop. AddressSanitizer uses these markers to track out-of-scope accesses to local variables, and we get false positives in Obj-C foreach loops (in the 2nd iteration of the loop). This patch keeps the loop variable alive for the whole loop by extending ForScope and registering the cleanup function inside EmitAutoVarAlloca. Differential Revision: https://reviews.llvm.org/D32029 llvm-svn: 300340
* Update for lifetime intrinsic signature changeMatt Arsenault2017-04-101-4/+6
| | | | llvm-svn: 299877
* Fix Wdocumentation warningSimon Pilgrim2017-03-141-1/+1
| | | | llvm-svn: 297784
* [ubsan] Use the nicer nullability diagnostic handlersVedant Kumar2017-03-141-3/+2
| | | | | | | | | | | This is a follow-up to r297700 (Add a nullability sanitizer). It addresses some FIXME's re: using nullability-specific diagnostic handlers from compiler-rt, now that the necessary handlers exist. check-ubsan test updates to follow. llvm-svn: 297750
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-141-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach UBSan to detect when a value with the _Nonnull type annotation assumes a null value. Call expressions, initializers, assignments, and return statements are all checked. Because _Nonnull does not affect IRGen, the new checks are disabled by default. The new driver flags are: -fsanitize=nullability-arg (_Nonnull violation in call) -fsanitize=nullability-assign (_Nonnull violation in assignment) -fsanitize=nullability-return (_Nonnull violation in return stmt) -fsanitize=nullability (all of the above) This patch builds on top of UBSan's existing support for detecting violations of the nonnull attributes ('nonnull' and 'returns_nonnull'), and relies on the compiler-rt support for those checks. Eventually we will need to update the diagnostic messages in compiler-rt (there are FIXME's for this, which will be addressed in a follow-up). One point of note is that the nullability-return check is only allowed to kick in if all arguments to the function satisfy their nullability preconditions. This makes it necessary to emit some null checks in the function body itself. Testing: check-clang and check-ubsan. I also built some Apple ObjC frameworks with an asserts-enabled compiler, and verified that we get valid reports. Differential Revision: https://reviews.llvm.org/D30762 llvm-svn: 297700
* Add an explicit derived class of FunctionDecl to model deduction guides ratherRichard Smith2017-02-171-0/+1
| | | | | | | | than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
* [CodeGen] Suppress emission of lifetime markers if a label has been seenAkira Hatanaka2017-01-251-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | in the current lexical scope. clang currently emits the lifetime.start marker of a variable when the variable comes into scope even though a variable's lifetime starts at the entry of the block with which it is associated, according to the C standard. This normally doesn't cause any problems, but in the rare case where a goto jumps backwards past the variable declaration to an earlier point in the block (see the test case added to lifetime2.c), it can cause mis-compilation. To prevent such mis-compiles, this commit conservatively disables emitting lifetime variables when a label has been seen in the current block. This problem was discussed on cfe-dev here: http://lists.llvm.org/pipermail/cfe-dev/2016-July/050066.html rdar://problem/30153946 Differential Revision: https://reviews.llvm.org/D27680 llvm-svn: 293106
* CGDecl: Skip static variable initializers in unreachable codeMatthias Braun2017-01-101-2/+2
| | | | | | | | This fixes http://llvm.org/PR31054 Differential Revision: https://reviews.llvm.org/D28505 llvm-svn: 291576
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-201-0/+4
| | | | | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
* Revert "[c++1z] P0195R2: Support pack-expansion of using-declarations."Daniel Jasper2016-12-191-4/+0
| | | | | | | This reverts commit r290080 as it leads to many Clang crashes, e.g.: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814 llvm-svn: 290092
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-191-0/+4
| | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
* Re-commit r289252 and r289285, and fix PR31374Yaxun Liu2016-12-151-1/+1
| | | | llvm-svn: 289787
* Revert 289252 (and follow-up 289285), it caused PR31374Nico Weber2016-12-141-1/+1
| | | | llvm-svn: 289713
* Add support for non-zero null pointer for C and OpenCLYaxun Liu2016-12-091-1/+1
| | | | | | | | | | | | | | | | | | In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space. Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value. Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast. Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values. This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way. This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally. Differential Revision: https://reviews.llvm.org/D26196 llvm-svn: 289252
OpenPOWER on IntegriCloud