summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Debug info for blocks: Fix a bug caught by the Verifier.Adrian Prantl2014-11-213-5/+11
| | | | | | | | | | | | When emitting nested block definitions, the insert-at-point variant of DIBuilder::insertDeclare() could be called with the insertion point set to the end-of-BasicBlock sentinel, causing the parent pointer of the CallInst to be set to the intentionally bogus value of the sentinel. Fixed by conditionally invoking the correct version of insertDeclare(). rdar://problem/19034882 llvm-svn: 222487
* DebugInfo: Fix another case of r222377 when we do have a definition of the ↵David Blaikie2014-11-211-11/+7
| | | | | | variable, but we might not be emitting it (such as templates) llvm-svn: 222485
* Remove now dead code.Frederic Riss2014-11-201-7/+0
| | | | | | | | After LLVM r222434, the Variables field of DISubprograms for forward declarations will always be null. No need to keep code around to delete them. llvm-svn: 222437
* Prepare for the DIBuilder populating DISubprogram's Variables with null.Frederic Riss2014-11-201-1/+2
| | | | | | | | | | | This is a followup to r222373. A better solution to the problem solved there is to not create the leaked nodes at all (we know that they will never be used for forward declared functions anyway). To avoid bot breakage in the interval between the cfe and llvm commits, add a check that the nMDNode is not null before deleting it. This code can completely go away after the LLVM part is in. llvm-svn: 222433
* [OPENMP] Codegen for "omp flush" directive.Alexey Bataev2014-11-203-5/+39
| | | | | | | | For each "omp flush" directive a call to "void kmpc_flush(ident_t *, ...)" function is generated. Directive "omp flush" may have an associated list of variables to flush, but currently runtime function ignores them. So the patch generates just "call kmpc_flush(ident_t *<loc>, i32 0)". Differential Revision: http://reviews.llvm.org/D6292 llvm-svn: 222409
* DebugInfo: Don't emit a 'global variable' when a static member declaration ↵David Blaikie2014-11-191-4/+18
| | | | | | | | | is referenced without a definition, just ensure the enclosing class (with the static member declaration) is emitted. Addresses PR21511 by emitting appropriate metadata rather than faux-global definitions for a variable that doesn't have a definition. llvm-svn: 222377
* Fix a temporary MDNode leak.Frederic Riss2014-11-191-0/+7
| | | | | | | | | | | | While emitting debug information for function forward decalrations, we create DISubprogram objects that aran't stored in the AllSubprograms list, and thus won't get finalized by the DIBuilder. During the DIBuilder finalize(), the temporary MDNode allocated for the DISubprogram Variables field gets RAUWd with a non temporary DIArray. For the forward declarations, simply delete that temporary node before we delete the parent node, so that it doesn't leak. llvm-svn: 222373
* Allow EmitVAArg() to promote types and use this to fix some N32/N64 vararg ↵Daniel Sanders2014-11-192-4/+20
| | | | | | | | | | | | | | | | | | | | | issues for Mips. Summary: With this patch, passing a va_list to another function and reading 10 int's from it works correctly on a big-endian target. Based on a pair of patches by David Chisnall, one of which I've reworked for the current trunk. Reviewers: theraven, atanasyan Reviewed By: theraven, atanasyan Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6248 llvm-svn: 222339
* Update for LLVM API change to make Small(Ptr)Set::insert return ↵David Blaikie2014-11-1910-24/+29
| | | | | | pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
* clang-format a recent commit I madeDavid Blaikie2014-11-191-4/+4
| | | | llvm-svn: 222317
* Standardize on StringMap::insert, removing uses of StringMap::GetOrCreateValue.David Blaikie2014-11-192-25/+23
| | | | llvm-svn: 222306
* Update for LLVM API changeDavid Blaikie2014-11-191-1/+1
| | | | llvm-svn: 222303
* Add PIC-level support to Clang.Justin Hibbits2014-11-181-0/+12
| | | | | | | | | | | | | | | | | | Summary: This distinguishes between -fpic and -fPIC now, with the additions in LLVM for PIC level support. Test Plan: No regressions Reviewers: echristo, rafael Reviewed By: rafael Subscribers: rnk, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D5400 llvm-svn: 222227
* Fully handle globals and functions in CGDebugInfo::getDeclarationOrDefinition()Frederic Riss2014-11-182-11/+95
| | | | | | | | | | | | | | | | | | | | Currently this function would return nothing for functions or globals that haven't seen a definition yet. Make it return a forward declaration that will get RAUWed with the definition if one is seen at a later point. The strategy used to implement this is similar to what's done for types: the forward declarations are stored in a vector and post processed upon finilization to perform the required RAUWs. For now the only user of getDeclarationOrDefinition() is EmitUsingDecl(), thus this patch allows to emit correct imported declarations even in the absence of an actual definition of the imported entity. (Another user will be the debug info generation for argument default values that I need to resurect). Differential Revision: http://reviews.llvm.org/D6173 llvm-svn: 222220
* [DebugInfo] Move collection of various function/var decl properties into ↵Frederic Riss2014-11-182-59/+94
| | | | | | | | helper functions. NFC. Helpers to be re-used in upcoming commit. llvm-svn: 222219
* InstrProf: Don't emit coverage for uninstantiated templatesJustin Bogner2014-11-181-3/+5
| | | | | | | | | | | | | We include unused functions and methods in -fcoverage-mapping so that we can differentiate between uninstrumented and unused. This can cause problems for uninstantiated templates though, since they may involve an incomplete type that can't be mangled. This shows up in things like libc++'s <unordered_map> and makes coverage unusable. Avoid the issue by skipping uninstantiated methods of a templated class. llvm-svn: 222204
* CodeGen: make a check stricterSaleem Abdulrasool2014-11-171-2/+2
| | | | | | | | | When targeting Windows itanium (a MSVC environment), use itanium style exceptions rather than SEH. Existing test cases already test this code path. Applying this change ensures that tests wont break due to a parallel change in LLVM (to correctly report isMSVCEnvironment). llvm-svn: 222179
* Fix IRGen for passing transparent unionsReid Kleckner2014-11-151-0/+23
| | | | | | | | | We have had a test for this for a long time with a FIXME saying what we should be doing. This just does it. Fixes PR21573. llvm-svn: 222074
* CGDebugInfo: Update for DIBuilder API changeDuncan P. N. Exon Smith2014-11-151-5/+7
| | | | | | Tracking LLVM commit r222070. llvm-svn: 222071
* This patch fixes couple of bugs for predefined expressionFariborz Jahanian2014-11-141-1/+4
| | | | | | | | | used inside blocks. It fixes a crash in naming code for __func__ etc. when used in a block declared globally. It also brings back old naming convention for predefined expression which was broken. rdar://18961148 llvm-svn: 222065
* Remove some redundant virtual specifiers on overriden functions.David Blaikie2014-11-142-2/+2
| | | | llvm-svn: 222024
* Remove -fseh-exceptions in favor of checking the tripleReid Kleckner2014-11-141-21/+33
| | | | | | | | | This option was misleading because it looked like it enabled the language feature of SEH (__try / __except), when this option was really controlling which EH personality function to use. Mingw only supports SEH and SjLj EH on x86_64, so we can simply do away with this flag. llvm-svn: 221963
* [Objective-C++ IRGen] do not generate .cxx_construct Fariborz Jahanian2014-11-121-1/+15
| | | | | | | for class that contains trivially-constructible struct ivar. rdar://18950072 llvm-svn: 221823
* [PowerPC] Add vec_vsx_ld and vec_vsx_st intrinsicsBill Schmidt2014-11-121-0/+16
| | | | | | | | | | | | | | | | | | This patch enables the vec_vsx_ld and vec_vsx_st intrinsics for PowerPC, which provide programmer access to the lxvd2x, lxvw4x, stxvd2x, and stxvw4x instructions. New code in altivec.h defines these in terms of new builtins, which are themselves defined in BuiltinsPPC.def. The builtins are converted to LLVM intrinsics in CGBuiltin.cpp. Additional code is added to builtins-ppc-vsx.c to verify the correct generation of the intrinsics. Note that I moved the other VSX builtins so all VSX builtins will be alphabetical in their own section in BuiltinsPPC.def. There is a companion patch for LLVM. llvm-svn: 221768
* [clang/asan] Do not emit memcpy for trivial operator= when ↵Kostya Serebryany2014-11-111-1/+1
| | | | | | | | | | | | | | | | | | -fsanitize-address-field-padding >= 1 Summary: If we've added poisoned paddings to a type do not emit memcpy for operator=. Test Plan: regression tests. Reviewers: majnemer, rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6160 llvm-svn: 221739
* Introduce -fsanitize-coverage=N flagKostya Serebryany2014-11-111-0/+15
| | | | | | | | | | | | | | | | | | | Summary: This change makes the asan-coverge (formerly -mllvm -asan-coverge) accessible via a clang flag. Companion patch to LLVM is http://reviews.llvm.org/D6152 Test Plan: regression tests, chromium Reviewers: samsonov Reviewed By: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6153 llvm-svn: 221719
* Bundle conditions checked by UBSan with sanitizer kinds they implement.Alexey Samsonov2014-11-116-77/+79
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
* Revert "IR: MDNode => Value: Update for LLVM API change in r221375"Duncan P. N. Exon Smith2014-11-111-1/+1
| | | | | | | | This reverts commit r221376. The API change was reverted in r221711. llvm-svn: 221712
* PR16091 continued: Debug Info for member functions with undeduced return types.David Blaikie2014-11-111-13/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So DWARF5 specs out auto deduced return types as DW_TAG_unspecified_type with DW_AT_name "auto", and GCC implements this somewhat, but it presents a few problems to do this with Clang. GCC's implementation only applies to member functions where the auto return type isn't deduced immediately (ie: member functions of templates or member functions defined out of line). In the common case of an inline deduced return type function, GCC emits the DW_AT_type as the deduced return type. Currently GDB doesn't seem to behave too well with this debug info - it treats the return type as 'void', even though the definition of the function has the correctly deduced return type (I guess it sees the return type the declaration has, doesn't understand it, and assumes void). This means the function's ABI might be broken (non-trivial return types, etc), etc. Clang, on the other hand doesn't track this particular case of a deducable return type that is deduced immediately versus one that is deduced 'later'. So if we implement the DWARF5 representation, all deducible return type functions would get adverse GDB behavior (including deduced return type lambda functions, inline deduced return type functions, etc). Also, we can't just do this for auto types that are not deduced - because Clang marks even the declaration's return type as deduced (& provides the underlying type) once a definition is seen that allows the deduction. So we have to ignore even deduced types - but we can't do that for auto variables (because this representation only applies to function declarations - variables and function definitions need the real type so the function can be called, etc) so we'd need to add an extra flag to the type unwrapping/creation code to indicate when we want to see through deduced types and when we don't. It's also not as simple as just checking at the top level when building a function type (for one thing, we reuse the function type building for building function pointer types which might also have 'auto' in them - but be the type of a variable instead) because the auto might be arbitrarily deeply nested ("auto &", "auto (*)()", etc...) So, with all that said, let's do the simple thing that works in existing debuggers for now and treat these functions the same way we do function templates and implicit special members: omit them from the member list, since they can't be correctly called anyway (without knowing the return type the ABI isn't know and a function call could put the arguments in the wrong place) so they're not much use to the user. At some point in the future, when GDB understands the DWARF5 representation better it might be worth plumbing through the extra type builder handling to avoid looking through AutoType for some callers, etc... llvm-svn: 221704
* CGOpenMPRuntime.h: Fix a couple of \param(s) introduced in r221663. ↵NAKAMURA Takumi2014-11-111-2/+2
| | | | | | [-Wdocumentation] llvm-svn: 221676
* [OPENMP] Codegen for threadprivate variablesAlexey Bataev2014-11-116-16/+328
| | | | | | | | | For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
* InstrProf: Remove an unnecessary helper function (NFC)Justin Bogner2014-11-111-26/+12
| | | | | | | VisitSubStmtRBraceState is really just Visit, as long as VisitCompoundStatement handles braces correctly. llvm-svn: 221659
* CGExpr.cpp: Suppress a warning. [-Wunused-variable]NAKAMURA Takumi2014-11-111-0/+2
| | | | llvm-svn: 221655
* [Sanitizer] Refactor sanitizer options in LangOptions.Alexey Samsonov2014-11-113-5/+5
| | | | | | | | | | | | | | | | | | Get rid of ugly SanitizerOptions class thrust into LangOptions: * Make SanitizeAddressFieldPadding a regular language option, and rely on default behavior to initialize/reset it. * Make SanitizerBlacklistFile a regular member LangOptions. * Introduce the helper class "SanitizerSet" to represent the set of enabled sanitizers and make it a member of LangOptions. It is exactly the entity we want to cache and modify in CodeGenFunction, for instance. We'd also be able to reuse SanitizerSet in CodeGenOptions for storing the set of recoverable sanitizers, and in the Driver to represent the set of sanitizers turned on/off by the commandline flags. No functionality change. llvm-svn: 221653
* Propagate SanitizerKind into CodeGenFunction::EmitCheck() call.Alexey Samsonov2014-11-106-48/+85
| | | | | | | | | | | | | | | | Make sure CodeGenFunction::EmitCheck() knows which sanitizer it emits check for. Make CheckRecoverableKind enum an implementation detail and move it away from header. Currently CheckRecoverableKind is determined by the type of sanitizer ("unreachable" and "return" are unrecoverable, "vptr" is always-recoverable, all the rest are recoverable). This will change in future if we allow to specify which sanitizers are recoverable, and which are not by -fsanitize-recover= flag. No functionality change. llvm-svn: 221635
* ARM ABI: simplify decisions on whether args can be expanded.Tim Northover2014-11-071-35/+21
| | | | | | | | | | | | Homogeneous aggregates on AAPCS_VFP ARM need to be passed *without* being flattened (e.g. [2 x float] rather than "float, float") for various weird ABI reasons. However, this isn't the case for anything else; further, we know at the ABIArgInfo::getDirect callsites whether this flattening is allowed. So, we can get more unified ARM code, with a simpler Clang, by just using that knowledge directly. llvm-svn: 221559
* Introduce a SanitizerKind enum to LangOptions.Alexey Samsonov2014-11-0711-65/+75
| | | | | | | | | | | | | Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
* CodeGen, Itanium: Properly dllimport RTTI dataDavid Majnemer2014-11-071-1/+10
| | | | | | | | | | We would blindly assume that RTTI data should have the same linkage as the vtable because we didn't think the RTTI data was external. This oversight stemmed because we didn't take dllimport into account. This fixes PR21512. llvm-svn: 221511
* Return a DIDescriptor from CGDebugInfo::getDeclarationOrDefinition...Frederic Riss2014-11-062-5/+5
| | | | | | | ... instead of a DIScope that might wrap something that's not actually a DIScope (eg. a DIGlobalVariable); llvm-svn: 221481
* Don't manually insert L prefixes.Rafael Espindola2014-11-061-180/+122
| | | | | | Simply marking the symbol private conveys the desire to hide them to LLVM. llvm-svn: 221451
* cmake: Conditionalize CodeGen's dependency on intrinsics_genReid Kleckner2014-11-051-1/+10
| | | | | | | | Custom targets in cmake cannot be exported, and this dependency is only needed in the combined build to ensure that Intrinsics.gen is created before compiling CodeGen. In the standalone, all of LLVM is build first. llvm-svn: 221391
* [DebugInfo] Do not record artificial global initializer functions in the ↵Frederic Riss2014-11-051-1/+4
| | | | | | | | | | | | | | | DeclCache. When we are generating the global initializer functions, we call CGDebugInfo::EmitFunctionStart() with a valid decl which is describing the initialized global variable. Do not update the DeclCache with this key as it will overwrite the the cached variable DIGlobalVariable with the newly created artificial DISubprogram. One could wonder if we should put artificial subprograms in the DIE tree at all (there are vaild uses for them carrying line information though). llvm-svn: 221385
* IR: MDNode => Value: Update for LLVM API change in r221375Duncan P. N. Exon Smith2014-11-051-1/+1
| | | | llvm-svn: 221376
* Debug info: Emit the correct type for the __FuncPtr field in a blockAdrian Prantl2014-11-051-2/+4
| | | | | | | | descriptor. rdar://problem/15984431 llvm-svn: 221326
* Use the new LLVM_END_WITH_NULL nameReid Kleckner2014-11-041-1/+1
| | | | llvm-svn: 221217
* Lower __builtin_fabs* to @llvm.fabs.*Reid Kleckner2014-11-031-0/+7
| | | | | | | | | mingw64's headers implement fabs by calling __builtin_fabs, so using the library call results in an infinite loop. If the backend legalizes @llvm.fabs as a call to fabs later, things should work out, as the crt provides a definition. llvm-svn: 221206
* Remove dead AST type argument to EmitFAbsReid Kleckner2014-11-031-5/+5
| | | | llvm-svn: 221205
* Implement vaarg lowering for ppc32. Lowering of scalars and aggregatesRoman Divacky2014-11-031-3/+101
| | | | | | is supported. Complex numbers are not. llvm-svn: 221170
* Emit OpenCL local global variables without zeorinitializerMatt Arsenault2014-11-031-1/+9
| | | | | | | | Local variables are not initialized, and every target has been (incorrectly) ignoring the unnecessary request for zero initialization. llvm-svn: 221162
* Don't dllimport inline functions when targeting MinGW (PR21366)Hans Wennborg2014-11-031-0/+8
| | | | | | | | | | | | It turns out that MinGW never dllimports of exports inline functions. This means that code compiled with Clang would fail to link with MinGW-compiled libraries since we might try to import functions that are not imported. To fix this, make Clang never dllimport inline functions when targeting MinGW. llvm-svn: 221154
OpenPOWER on IntegriCloud