summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [ubsan] array-bounds: Ignore params with constant sizeVedant Kumar2017-12-081-8/+0
| | | | | | | | | | This is a follow-up to r320128. Eli pointed out that there is some gray area in the language standard about whether the constant size is exact, or a lower bound. https://reviews.llvm.org/D40940 llvm-svn: 320185
* [ubsan] Use pass_object_size info in bounds checksVedant Kumar2017-12-081-0/+54
| | | | | | | | | Teach UBSan's bounds check to opportunistically use pass_object_size information to check array accesses. rdar://33272922 llvm-svn: 320128
* Revert "[CodeGen] Add initial support for union members in TBAA"Hal Finkel2017-12-031-20/+13
| | | | | | | | This reverts commit r319413. See PR35503. We can't use "union member" as the access type here like this. llvm-svn: 319629
* [CodeGen] Add initial support for union members in TBAAIvan A. Kosarev2017-11-301-13/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The basic idea behind this patch is that since in strict aliasing mode all accesses to union members require their outermost enclosing union objects to be specified explicitly, then for a couple given accesses to union members of the form p->a.b.c... q->x.y.z... it is known they can only alias if both p and q point to the same union type and offset ranges of members a.b.c... and x.y.z... overlap. Note that the actual types of the members do not matter. Specifically, in this patch we do the following: * Make unions to be valid TBAA base access types. This enables generation of TBAA type descriptors for unions. * Encode union types as structures with a single member of a special "union member" type. Currently we do not encode information about sizes of types, but conceptually such union members are considered to be of the size of the whole union. * Encode accesses to direct and indirect union members, including member arrays, as accesses to these special members. All accesses to members of a union thus get the same offset, which is the offset of the union they are part of. This means the existing LLVM TBAA machinery is able to handle such accesses with no changes. While this is already an improvement comparing to the current situation, that is, representing all union accesses as may-alias ones, there are further changes planned to complete the support for unions. One of them is storing information about access sizes so we can distinct accesses to non-overlapping union members, including accesses to different elements of member arrays. Another change is encoding type sizes in order to make it possible to compute offsets within constant-indexed array elements. These enhancements will be addressed with separate patches. Differential Revision: https://reviews.llvm.org/D39455 llvm-svn: 319413
* [CFI] Add CFI-icall pointer type generalizationVlad Tsyrklevich2017-10-311-1/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change allows generalizing pointers in type signatures used for cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag. This works by 1) emitting an additional generalized type signature metadata node for functions and 2) llvm.type.test()ing for the generalized type for translation units with the flag specified. This flag is incompatible with -fsanitize-cfi-cross-dso because it would require emitting twice as many type hashes which would increase artifact size. Reviewers: pcc, eugenis Reviewed By: pcc Subscribers: kcc Differential Revision: https://reviews.llvm.org/D39358 llvm-svn: 317044
* [CodeGen] Propagate may-alias'ness of lvalues with TBAA infoIvan A. Kosarev2017-10-311-47/+43
| | | | | | | | | | | | | This patch fixes various places in clang to propagate may-alias TBAA access descriptors during construction of lvalues, thus eliminating the need for the LValueBaseInfo::MayAlias flag. This is part of D38126 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D39008 llvm-svn: 316988
* CodeGen: Fix insertion position of addrspace cast for allocaYaxun Liu2017-10-301-1/+5
| | | | | | | | | | | | | | | | | | | | For non-zero alloca addr space, alloca is usually casted to default addr space immediately. For non-vla, alloca is inserted at AllocaInsertPt, therefore the addr space cast should also be insterted at AllocaInsertPt. However, for vla, alloca is inserted at the current insertion point of IRBuilder, therefore the addr space cast should also inserted at the current insertion point of IRBuilder. Currently clang always insert addr space cast at AllocaInsertPt, which causes invalid IR. This patch fixes that. Differential Revision: https://reviews.llvm.org/D39374 llvm-svn: 316909
* [CodeGen] Generate TBAA info for reference loadsIvan A. Kosarev2017-10-301-48/+46
| | | | | | Differential Revision: https://reviews.llvm.org/D39177 llvm-svn: 316896
* CodeGen: Fix missing debug loc due to allocaYaxun Liu2017-10-241-2/+1
| | | | | | | | | | | | Builder save/restores insertion pointer when emitting addr space cast for alloca, but does not save/restore debug loc, which causes verifier failure for certain call instructions. This patch fixes that. Differential Revision: https://reviews.llvm.org/D39069 llvm-svn: 316484
* [CodeGen] Fix generation of TBAA info for array-to-pointer conversionsIvan A. Kosarev2017-10-201-2/+8
| | | | | | | | | | Resolves: Fatal error: Offset not zero at the point of scalar access. http://llvm.org/PR34992 Differential Revision: https://reviews.llvm.org/D39083 llvm-svn: 316211
* [CodeGen] Refine generation of TBAA info for bit-field lvaluesIvan A. Kosarev2017-10-171-63/+51
| | | | | | | | | | | | | | | | | The main change is that now we generate TBAA info before constructing the resulting lvalue instead of constructing lvalue with some default TBAA info and fixing it as necessary afterwards. We also keep the TBAA info close to lvalue base info, which is supposed to simplify their future merging. This patch should not bring in any functional changes. This is part of D38126 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38947 llvm-svn: 315989
* [CodeGen] Pass TBAA info along with lvalue base info everywhereIvan A. Kosarev2017-10-171-6/+6
| | | | | | | | | | | | | | This patch addresses the rest of the cases where we pass lvalue base info, but do not provide corresponding TBAA info. This patch should not bring in any functional changes. This is part of D38126 reworked to be a separate patch to make reviewing easier. Differential Revision: https://reviews.llvm.org/D38945 llvm-svn: 315986
* [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-171-36/+51
| | | | | | | | base info Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315984
* Revert "[CodeGen] EmitPointerWithAlignment() to generate TBAA info along ↵Ivan A. Kosarev2017-10-131-44/+30
| | | | | | | | | | with LValue base info", r315731. With this change we fail on the clang-x86_64-linux-selfhost-modules builder. Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315739
* [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-131-30/+44
| | | | | | | | base info Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315731
* [CodeGen] emitOMPArraySectionBase() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-131-5/+10
| | | | | | | | base info Differential Revision: https://reviews.llvm.org/D38795 llvm-svn: 315715
* [CodeGen] getNaturalTypeAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-131-11/+9
| | | | | | | | | | base info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38794 llvm-svn: 315708
* [CodeGen] EmitLoadOfReference() to generate TBAA info along with LValue base ↵Ivan A. Kosarev2017-10-131-4/+8
| | | | | | | | | | info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38793 llvm-svn: 315705
* [CodeGen] EmitLoadOfPointer() to generate TBAA info along with LValue base infoIvan A. Kosarev2017-10-131-4/+8
| | | | | | | | This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38791 llvm-svn: 315704
* [CodeGen] EmitCXXMemberDataPointerAddress() to generate TBAA info along with ↵Ivan A. Kosarev2017-10-131-3/+4
| | | | | | | | | | LValue base info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38788 llvm-svn: 315702
* [OPENMP] Fix PR34926: Fix handling of the array sections passed asAlexey Bataev2017-10-121-6/+1
| | | | | | | | | function params. Codegen could crash if the array section base expression is the function parameter. llvm-svn: 315586
* [CodeGen] Generate TBAA info along with LValue base infoIvan A. Kosarev2017-10-121-18/+35
| | | | | | | | | | | | | | | | | | This patch enables explicit generation of TBAA information in all cases where LValue base info is propagated or constructed in non-trivial ways. Eventually, we will consider each of these cases to make sure the TBAA information is correct and not too conservative. For now, we just fall back to generating TBAA info from the access type. This patch should not bring in any functional changes. This is part of D38126 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38733 llvm-svn: 315575
* [CodeGen] Do not construct complete LValue base info in trivial casesIvan A. Kosarev2017-10-101-50/+30
| | | | | | | | | | | | | Besides obvious code simplification, avoiding explicit creation of LValueBaseInfo objects makes it easier to make TBAA information to be part of such objects. This is part of D38126 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38695 llvm-svn: 315289
* [OPENMP] Capture references to global variables.Alexey Bataev2017-10-061-2/+6
| | | | | | | | In C++11 variable to global variables are considered as constant expressions and these variables are not captured in the outlined regions. Patch allows capturing of such variables in the OpenMP regions. llvm-svn: 315074
* Refine generation of TBAA information in clangIvan A. Kosarev2017-10-061-28/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is an attempt to clarify and simplify generation and propagation of TBAA information. The idea is to pack all values that describe a memory access, namely, base type, access type and offset, into a single structure. This is supposed to make further changes, such as adding support for unions and array members, easier to prepare and review. DecorateInstructionWithTBAA() is no more responsible for converting types to tags. These implicit conversions not only complicate reading the code, but also suggest assigning scalar access tags while we generally prefer full-size struct-path tags. TBAAPathTag is replaced with TBAAAccessInfo; the latter is now the type of the keys of the cache map that translates access descriptors to metadata nodes. Fixed a bug with writing to a wrong map in getTBAABaseTypeMetadata() (former getTBAAStructTypeInfo()). We now check for valid base access types every time we dereference a field. The original code only checks the top-level base type. See isValidBaseType() / isTBAAPathStruct() calls. Some entities have been renamed to sound more adequate and less confusing/misleading in presence of path-aware TBAA information. Now we do not lookup twice for the same cache entry in getAccessTagInfo(). Refined relevant comments and descriptions. Differential Revision: https://reviews.llvm.org/D37826 llvm-svn: 315048
* [CodeGen] Unify generation of scalar and struct-path TBAA tagsIvan A. Kosarev2017-10-051-20/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes it possible to produce access tags in a uniform manner regardless whether the resulting tag will be a scalar or a struct-path one. getAccessTagInfo() now takes care of the actual translation of access descriptors to tags and can handle all kinds of accesses. Facilities that specific to scalar accesses are eliminated. Some more details: * DecorateInstructionWithTBAA() is not responsible for conversion of types to access tags anymore. Instead, it takes an access descriptor (TBAAAccessInfo) and generates corresponding access tag from it. * getTBAAInfoForVTablePtr() reworked to getTBAAVTablePtrAccessInfo() that now returns the virtual-pointer access descriptor and not the virtual-point type metadata. * Added function getTBAAMayAliasAccessInfo() that returns the descriptor for may-alias accesses. * getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now it is the only way to generate access tag by a given access descriptor. It is capable of producing both scalar and struct-path tags, depending on options and availability of the base access type. getTBAAScalarTagInfo() and its cache ScalarTagMetadataCache are eliminated. * Now that we do not need to care about whether the resulting access tag should be a scalar or struct-path one, getTBAAStructTypeInfo() is renamed to getBaseTypeInfo(). * Added function getTBAAAccessInfo() that constructs access descriptor by a given QualType access type. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314979
* Revert r314977 "[CodeGen] Unify generation of scalar and struct-path TBAA tags"Ivan A. Kosarev2017-10-051-38/+40
| | | | | | | | D37826 has been mistakenly committed where it should be the patch from D38503. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314978
* [CodeGen] Unify generation of scalar and struct-path TBAA tagsIvan A. Kosarev2017-10-051-40/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes it possible to produce access tags in a uniform manner regardless whether the resulting tag will be a scalar or a struct-path one. getAccessTagInfo() now takes care of the actual translation of access descriptors to tags and can handle all kinds of accesses. Facilities that specific to scalar accesses are eliminated. Some more details: * DecorateInstructionWithTBAA() is not responsible for conversion of types to access tags anymore. Instead, it takes an access descriptor (TBAAAccessInfo) and generates corresponding access tag from it. * getTBAAInfoForVTablePtr() reworked to getTBAAVTablePtrAccessInfo() that now returns the virtual-pointer access descriptor and not the virtual-point type metadata. * Added function getTBAAMayAliasAccessInfo() that returns the descriptor for may-alias accesses. * getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now it is the only way to generate access tag by a given access descriptor. It is capable of producing both scalar and struct-path tags, depending on options and availability of the base access type. getTBAAScalarTagInfo() and its cache ScalarTagMetadataCache are eliminated. * Now that we do not need to care about whether the resulting access tag should be a scalar or struct-path one, getTBAAStructTypeInfo() is renamed to getBaseTypeInfo(). * Added function getTBAAAccessInfo() that constructs access descriptor by a given QualType access type. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314977
* [CodeGen] Introduce generic TBAA access descriptorsIvan A. Kosarev2017-10-031-24/+18
| | | | | | | | | | | | | With this patch we implement a concept of TBAA access descriptors that are capable of representing both scalar and struct-path accesses in a generic way. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38456 llvm-svn: 314780
* [ubsan] Skip alignment checks which are folded awayVedant Kumar2017-10-031-3/+4
| | | | | | | | | | | | Don't emit alignment checks which the IR constant folder throws away. I've tested this out on X86FastISel.cpp. While this doesn't decrease end-to-end compile-time significantly, it results in 122 fewer type checks (1% reduction) overall, without adding any real complexity. Differential Revision: https://reviews.llvm.org/D37544 llvm-svn: 314752
* [ubsan] Save the result of getLLVMContext. NFC.Vedant Kumar2017-10-031-6/+6
| | | | llvm-svn: 314751
* [ubsan] Add helpers to decide when null/vptr checks are required. NFC.Vedant Kumar2017-10-031-8/+15
| | | | llvm-svn: 314750
* [ubsan] Save a ptrtoint when emitting alignment checksVedant Kumar2017-10-031-5/+10
| | | | | | | The alignment check emits a ptrtoint instruction which can be reused in the call to the diagnostic handler. llvm-svn: 314749
* [CodeGen] Have a special function to get TBAA info for may-alias accessesIvan A. Kosarev2017-10-021-8/+5
| | | | | | | | | This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38408 llvm-svn: 314660
* [CodeGen] Do not refer to complete TBAA info where we actually deal with ↵Ivan A. Kosarev2017-10-021-18/+19
| | | | | | | | | | | | | | just TBAA access types This patch fixes misleading names of entities related to getting, setting and generation of TBAA access type descriptors. This is effectively an attempt to provide a review for D37826 by breaking it into smaller pieces. Differential Revision: https://reviews.llvm.org/D38404 llvm-svn: 314657
* [OpenCL] Handle address space conversion while setting type alignment.Anastasia Stulova2017-09-271-2/+5
| | | | | | | | | Added missing addrspacecast case in alignment computation logic of pointer type emission in IR generation. Differential Revision: https://reviews.llvm.org/D37804 llvm-svn: 314304
* Allow specifying sanitizers in blacklistsVlad Tsyrklevich2017-09-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
* [ubsan] Function Sanitizer: Don't require writable text segmentsVedant Kumar2017-09-131-5/+4
| | | | | | | | | | | | | | | | | | This change will make it possible to use -fsanitize=function on Darwin and possibly on other platforms. It fixes an issue with the way RTTI is stored into function prologue data. On Darwin, addresses stored in prologue data can't require run-time fixups and must be PC-relative. Run-time fixups are undesirable because they necessitate writable text segments, which can lead to security issues. And absolute addresses are undesirable because they break PIE mode. The fix is to create a private global which points to the RTTI, and then to encode a PC-relative reference to the global into prologue data. Differential Revision: https://reviews.llvm.org/D37597 llvm-svn: 313096
* [CodeGen] Treat all vector fields as mayaliasHal Finkel2017-09-031-2/+2
| | | | | | | | | | | | | | | Because it is common to treat vector types as an array of their elements, or even some other type that's not the element type, and thus index into them, we can't use struct-path TBAA for these accesses. Even though we already treat all vector types as equivalent to 'char', we were using field-offset information for them with TBAA, and this renders undefined the intra-value indexing we intend to allow. Note that, although 'char' is universally aliasing, with path TBAA, we can still differentiate between access to s.a and s.b in struct { char a, b; } s;. We can't use this capability as-is for vector types. Fixes PR33967. llvm-svn: 312447
* Minimal runtime for UBSan.Evgeniy Stepanov2017-08-291-22/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: An implementation of ubsan runtime library suitable for use in production. Minimal attack surface. * No stack traces. * Definitely no C++ demangling. * No UBSAN_OPTIONS=log_file=/path (very suid-unfriendly). And no UBSAN_OPTIONS in general. * as simple as possible Minimal CPU and RAM overhead. * Source locations unnecessary in the presence of (split) debug info. * Values and types (as in A+B overflows T) can be reconstructed from register/stack dumps, once you know what type of error you are looking at. * above two items save 3% binary size. When UBSan is used with -ftrap-function=abort, sometimes it is hard to reason about failures. This library replaces abort with a slightly more informative message without much extra overhead. Since ubsan interface in not stable, this code must reside in compiler-rt. Reviewers: pcc, kcc Subscribers: srhines, mgorny, aprantl, krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D36810 llvm-svn: 312029
* [IRGen] Evaluate constant static variables referenced through memberAlex Lorenz2017-08-251-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expressions C++ allows us to reference static variables through member expressions. Prior to this commit, non-integer static variables that were referenced using a member expression were always emitted using lvalue loads. The old behaviour introduced an inconsistency between regular uses of static variables and member expressions uses. For example, the following program compiled and linked successfully: struct Foo { constexpr static const char *name = "foo"; }; int main() { return Foo::name[0] == 'f'; } but this program failed to link because "Foo::name" wasn't found: struct Foo { constexpr static const char *name = "foo"; }; int main() { Foo f; return f.name[0] == 'f'; } This commit ensures that constant static variables referenced through member expressions are emitted in the same way as ordinary static variable references. rdar://33942261 Differential Revision: https://reviews.llvm.org/D36876 llvm-svn: 311772
* [OPENMP] Fix for PR34014: OpenMP 4.5: Target construct in static methodAlexey Bataev2017-08-221-0/+1
| | | | | | | | | | of class fails to map class static variable. If the global variable is captured and it has several redeclarations, sometimes it may lead to a compiler crash. Patch fixes this by working only with canonical declarations. llvm-svn: 311479
* Extract IRGen's constant-emitter into its own helper class and clean upJohn McCall2017-08-151-3/+7
| | | | | | | | | | | | 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
* Add OpenCL 2.0 atomic builtin functions as Clang builtinYaxun Liu2017-08-041-1/+1
| | | | | | | | | | | | | | | | | | | | | OpenCL 2.0 atomic builtin functions have a scope argument which is ideally represented as synchronization scope argument in LLVM atomic instructions. Clang supports translating Clang atomic builtin functions to LLVM atomic instructions. However it currently does not support synchronization scope of LLVM atomic instructions. Without this, users have to use LLVM assembly code to implement OpenCL atomic builtin functions. This patch adds OpenCL 2.0 atomic builtin functions as Clang builtin functions, which supports generating LLVM atomic instructions with synchronization scope operand. Currently only constant memory scope argument is supported. Support of non-constant memory scope argument will be added later. Differential Revision: https://reviews.llvm.org/D28691 llvm-svn: 310082
* [ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't ↵Vedant Kumar2017-08-021-4/+4
| | | | | | | | | | | | | | | | | | available In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I did not see the need for the two checks to have separate null checking logic for the same pointer. I expected the two checks to either always be enabled together, or to be mutually compatible. In the mailing list discussion re: r309007 it became clear that that isn't the case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean, it's useful to have -fsanitize=vptr emit its own null check. That's what this patch does: with it, -fsanitize=vptr can be used without -fsanitize=null. Differential Revision: https://reviews.llvm.org/D36112 llvm-svn: 309846
* [ubsan] Null-check pointers in -fsanitize=vptr (PR33881)Vedant Kumar2017-07-251-5/+20
| | | | | | | | | | | | | | | | | | | The instrumentation generated by -fsanitize=vptr does not null check a user pointer before loading from it. This causes crashes in the face of UB member calls (this=nullptr), i.e it's causing user programs to crash only after UBSan is turned on. The fix is to make run-time null checking a prerequisite for enabling -fsanitize=vptr, and to then teach UBSan to reuse these run-time null checks to make -fsanitize=vptr safe. Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build Differential Revision: https://reviews.llvm.org/D35735 https://bugs.llvm.org/show_bug.cgi?id=33881 llvm-svn: 309007
* CodeGen: Insert addr space cast for automatic/temp var at right positionYaxun Liu2017-07-181-0/+3
| | | | | | | | | | | The uses of alloca may be in different blocks other than the block containing the alloca. Therefore if the alloca addr space is non-zero and it needs to be casted to default address space, the cast needs to be inserted in the same BB as the alloca insted of the current builder insert point since the current insert point may be in a different BB. Differential Revision: https://reviews.llvm.org/D35438 llvm-svn: 308313
* [ubsan] Teach the pointer overflow check that "p - <unsigned> <= p" (PR33430)Vedant Kumar2017-07-131-1/+3
| | | | | | | | | | | | | | | | | | | | | The pointer overflow check gives false negatives when dealing with expressions in which an unsigned value is subtracted from a pointer. This is summarized in PR33430 [1]: ubsan permits the result of the subtraction to be greater than "p", but it should not. To fix the issue, we should track whether or not the pointer expression is a subtraction. If it is, and the indices are unsigned, we know to expect "p - <unsigned> <= p". I've tested this by running check-{llvm,clang} with a stage2 ubsan-enabled build. I've also added some tests to compiler-rt, which are in D34122. [1] https://bugs.llvm.org/show_bug.cgi?id=33430 Differential Revision: https://reviews.llvm.org/D34121 llvm-svn: 307955
* CodeGen: Fix address space of global variableYaxun Liu2017-07-081-12/+26
| | | | | | | | | | | | | 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: Cast temporary variable to proper address spaceYaxun Liu2017-06-191-11/+33
| | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud