summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* SanitizerBlacklist: blacklist functions by their source location.Alexey Samsonov2014-10-171-14/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the way we blacklist functions in ASan, TSan, MSan and UBSan. We used to treat function as "blacklisted" and turned off instrumentation in it in two cases: 1) Function is explicitly blacklisted by its mangled name. This part is not changed. 2) Function is located in llvm::Module, whose identifier is contained in the list of blacklisted sources. This is completely wrong, as llvm::Module may not correspond to the actual source file function is defined in. Also, function can be defined in a header, in which case user had to blacklist the .cpp file this header was #include'd into, not the header itself. Such functions could cause other problems - for instance, if the header was included in multiple source files, compiled separately and linked into a single executable, we could end up with both instrumented and non-instrumented version of the same function participating in the same link. After this change we will make blacklisting decision based on the SourceLocation of a function definition. If a function is not explicitly defined in the source file, (for example, the function is compiler-generated and responsible for initialization/destruction of a global variable), then it will be blacklisted if the corresponding global variable is defined in blacklisted source file, and will be instrumented otherwise. After this commit, the active users of blacklist files may have to revisit them. This is a backwards-incompatible change, but I don't think it's possible or makes sense to support the old incorrect behavior. I plan to make similar change for blacklisting GlobalVariables (which is ASan-specific). llvm-svn: 219997
* test/CodeGen/sections.c: add tripleHans Wennborg2014-10-161-1/+1
| | | | llvm-svn: 219969
* trying to fix the new test on hexagon-buildKostya Serebryany2014-10-161-10/+10
| | | | llvm-svn: 219965
* Insert poisoned paddings between fields in C++ classes so that ↵Kostya Serebryany2014-10-161-0/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | AddressSanitizer can find intra-object-overflow bugs Summary: The general approach is to add extra paddings after every field in AST/RecordLayoutBuilder.cpp, then add code to CTORs/DTORs that poisons the paddings (CodeGen/CGClass.cpp). Everything is done under the flag -fsanitize-address-field-padding. The blacklist file (-fsanitize-blacklist) allows to avoid the transformation for given classes or source files. See also https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow Test Plan: run SPEC2006 and some of the Chromium tests with -fsanitize-address-field-padding Reviewers: samsonov, rnk, rsmith Reviewed By: rsmith Subscribers: majnemer, cfe-commits Differential Revision: http://reviews.llvm.org/D5687 llvm-svn: 219961
* MS Compat: mark globals emitted in read-only sections constHans Wennborg2014-10-161-0/+10
| | | | | | | | | | | | | | | | | | | | They cannot be written to, so marking them const makes sense and may improve optimisation. As a side-effect, SectionInfos has to be moved from Sema to ASTContext. It also fixes this problem, that occurs when compiling ATL: warning LNK4254: section 'ATL' (C0000040) merged into '.rdata' (40000040) with different attributes The ATL headers are putting variables in a special section that's marked read-only. However, Clang currently can't model that read-onlyness in the IR. But, by making the variables const, the section does become read-only, and the linker warning is avoided. Differential Revision: http://reviews.llvm.org/D5812 llvm-svn: 219960
* Update for llvm change.Rafael Espindola2014-10-162-2/+2
| | | | llvm-svn: 219952
* [AArch64] Enable A53 erratum workaround (835769) by default for Android targetsBradley Smith2014-10-161-0/+27
| | | | llvm-svn: 219933
* specify dwarf version for SolarisAlexander Eremin2014-10-161-0/+1
| | | | llvm-svn: 219901
* CodeGen: Don't drop thread_local when emitting __thread aliasesDavid Majnemer2014-10-151-0/+5
| | | | | | | | | | | | CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a tentative definition. Even if the definition was already emitted, it would never mark the alias as thread_local. This fixes PR21288. llvm-svn: 219859
* test: simplify test furtherSaleem Abdulrasool2014-10-151-4/+7
| | | | | | Remove the use of an unnecessary function. NFC. llvm-svn: 219850
* ARM: remove ARM/Thumb distinction for preferred alignment.Tim Northover2014-10-141-2/+2
| | | | | | | | | | | | Thumb1 has legitimate reasons for preferring 32-bit alignment of types i1/i8/i16, since the 16-bit encoding of "add rD, sp, #imm" requires #imm to be a multiple of 4. However, this is a trade-off betweem code size and RAM usage; the DataLayout string is not the best place to represent it even if desired. So this patch removes the extra Thumb requirements, hopefully making ARM and Thumb completely compatible in this respect. llvm-svn: 219735
* ARM: set preferred aggregate alignment to 32 universally.Tim Northover2014-10-141-2/+2
| | | | | | | | | | | Before, ARM and Thumb mode code had different preferred alignments, which could lead to some rather unexpected results. There's justification for reducing it from the default 64-bits (wasted space), but I don't think there is for going below 32-bits. There's no actual ABI change here, just to reassure people. llvm-svn: 219720
* CodeGen: correct mangling for blocksSaleem Abdulrasool2014-10-141-0/+20
| | | | | | | | | | | | | | | This addresses a regression introduced with SVN r219393. A block may be contained within another block. In such a scenario, we would end up within a BlockDecl, which is not a NamedDecl (as the names are synthesised). The cast to a NamedDecl of the DeclContext would then assert as the types are unrelated. Restore the mangling behaviour to that prior to SVN r219393. If the current block is contained within a BlockDecl, walk up to the parent DeclContext, recursively, until we have a non-BlockDecl. This is expected to be a NamedDecl. Add in a couple of asserts to ensure that the assumption that we only encounter a block within a NamedDecl or a BlockDecl. llvm-svn: 219696
* Allow constant expressions in pragma loop hints.Tyler Nowicki2014-10-121-11/+73
| | | | | | | | Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
* [complex] Teach the other two binary operators on complex numbers (==Chandler Carruth2014-10-111-0/+51
| | | | | | | | | | | | | | | | | and !=) to support mixed complex and real operand types. This requires removing an assert from SemaChecking, and adding support both to the constant evaluator and the code generator to synthesize the imaginary part when needed. This seemed somewhat cleaner than having just the comparison operators force real-to-complex conversions. I've added test cases for these operations. I'm really terrified that there were *no* tests in-tree which exercised this. This turned up when trying to build R after my change to the complex type lowering. llvm-svn: 219570
* [complex] Use the much more powerful EmitCall routine to call libcallsChandler Carruth2014-10-111-9/+11
| | | | | | | | | | | for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
* [complex] Teach Clang to preserve different-type operands to arithmeticChandler Carruth2014-10-111-0/+367
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
* Promote null pointer constants used as arguments to variadic functionsReid Kleckner2014-10-101-0/+17
| | | | | | | | | | | | | | | Make it possible to pass NULL through variadic functions on 64-bit Windows targets. The Visual C++ headers define NULL to 0, when they should define it to 0LL on Win64 so that NULL is a pointer-sized integer. Fixes PR20949. Reviewers: thakis, rsmith Differential Revision: http://reviews.llvm.org/D5480 llvm-svn: 219456
* Fix compatibility issues in tests for PredefinedExpr with MSVC.Alexey Bataev2014-10-091-2/+2
| | | | llvm-svn: 219405
* [AVX512] Added VPCMPEQ intrinisics to headers.Robert Khasanov2014-10-084-0/+153
| | | | | | | | Added tests. Patch by Maxim Blumenthal <maxim.blumenthal@intel.com> llvm-svn: 219319
* Emit @llvm.assume for non-parameter lvalue align_value-attribute loadsHal Finkel2014-10-041-0/+95
| | | | | | | | | | | | | | | | | | | | | We already add the align parameter attribute for function parameters that have the align_value attribute (or those with a typedef type having that attribute), which is an important special case, but does not handle pointers with value alignment assumptions that come into scope in any other way. To handle the general case, emit an @llvm.assume-based alignment assumption whenever we load the pointer-typed lvalue of an align_value-attributed variable (except for function parameters, which we already deal with at entry). I'll also note that this is more general than Intel's described support in: https://software.intel.com/en-us/articles/data-alignment-to-assist-vectorization which states that the compiler inserts __assume_aligned directives in response to align_value-attributed variables only for function parameters and for the initializers of local variables. I think that we can make the optimizer deal with this more-general scheme (which could lead to a lot of calls to @llvm.assume inside of loop bodies, for example), but if not, I'll rework this to be less aggressive. llvm-svn: 219052
* Revert "Revert "DI: LLVM schema change: fold constants into string""Duncan P. N. Exon Smith2014-10-0310-15/+17
| | | | | | | | | | | | | | This reverts commit r218917, effectively reapplying r218913. Original commit message follows. -- Update debug info testcases for an LLVM metadata schema change to fold metadata constant operands into a single `MDString`. Part of PR17891. llvm-svn: 219011
* Make test/CodeGen/atomic-ops.c free-standingHal Finkel2014-10-031-3/+3
| | | | | | | | This test includes stdint.h (via stdatomic.h), which might include system headers (and that might not work, depending on the system configuration). Attempting to fix llvm-clang-lld-x86_64-debian-fast. llvm-svn: 218960
* Add an implementation of C11's stdatomic.hHal Finkel2014-10-031-8/+31
| | | | | | | | | | | | | | | | | | | | | | | | Adds a Clang-specific implementation of C11's stdatomic.h header. On systems, such as FreeBSD, where a stdatomic.h header is already provided, we defer to that header instead (using our __has_include_next technology). Otherwise, we provide an implementation in terms of our __c11_atomic_* intrinsics (that were created for this purpose). C11 7.1.4p1 requires function declarations for atomic_thread_fence, atomic_signal_fence, atomic_flag_test_and_set, atomic_flag_test_and_set_explicit, and atomic_flag_clear, and requires that they have external linkage. Accordingly, we provide these declarations, but if a user elides the shadowing macros and uses them, then they must have a libc (or similar) that actually provides definitions. atomic_flag is implemented using _Bool as the underlying type. This is consistent with the implementation provided by FreeBSD and also GCC 4.9 (at least when __GCC_ATOMIC_TEST_AND_SET_TRUEVAL == 1). Patch by Richard Smith (rebased and slightly edited by me -- Richard said I should drive at this point). llvm-svn: 218957
* Revert "DI: LLVM schema change: fold constants into string"Duncan P. N. Exon Smith2014-10-0210-17/+15
| | | | | | This reverts commit r218913 while I investigate some bots. llvm-svn: 218917
* DI: LLVM schema change: fold constants into stringDuncan P. N. Exon Smith2014-10-0210-15/+17
| | | | | | | | | Update debug info testcases for an LLVM metadata schema change to fold metadata constant operands into a single `MDString`. Part of PR17891. llvm-svn: 218913
* Initial support for the align_value attributeHal Finkel2014-10-021-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the align_value attribute. This attribute is supported by Intel's compiler (versions 14.0+), and several of my HPC users have requested support in Clang. It specifies an alignment assumption on the values to which a pointer points, and is used by numerical libraries to encourage efficient generation of vector code. Of course, we already have an aligned attribute that can specify enhanced alignment for a type, so why is this additional attribute important? The problem is that if you want to specify that an input array of T is, say, 64-byte aligned, you could try this: typedef double aligned_double attribute((aligned(64))); void foo(aligned_double *P) { double x = P[0]; // This is fine. double y = P[1]; // What alignment did those doubles have again? } the access here to P[1] causes problems. P was specified as a pointer to type aligned_double, and any object of type aligned_double must be 64-byte aligned. But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes undefined behavior. Getting round this problem requires a lot of awkward casting and hand-unrolling of loops, all of which is bad. With the align_value attribute, we can accomplish what we'd like in a well defined way: typedef double *aligned_double_ptr attribute((align_value(64))); void foo(aligned_double_ptr P) { double x = P[0]; // This is fine. double y = P[1]; // This is fine too. } This attribute does not create a new type (and so it not part of the type system), and so will only "propagate" through templates, auto, etc. by optimizer deduction after inlining. This seems consistent with Intel's implementation (thanks to Alexey for confirming the various Intel-compiler behaviors). As a final note, I would have chosen to call this aligned_value, not align_value, for better naming consistency with the aligned attribute, but I think it would be more useful to users to adopt Intel's name. llvm-svn: 218910
* Add __sync_fetch_and_nand (again)Hal Finkel2014-10-022-2/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to GCC 4.4, __sync_fetch_and_nand was implemented as: { tmp = *ptr; *ptr = ~tmp & value; return tmp; } but this was changed in GCC 4.4 to be: { tmp = *ptr; *ptr = ~(tmp & value); return tmp; } in response to this change, support for sync_fetch_and_nand (and sync_nand_and_fetch) was removed in r99522 in order to avoid miscompiling code depending on the old semantics. However, at this point: 1. Many years have passed, and the amount of code relying on the old semantics is likely smaller. 2. Through the work of many contributors, all LLVM backends have been updated such that "atomicrmw nand" provides the newer GCC 4.4+ semantics (this process was complete July of 2014 (added to the release notes in r212635). 3. The lack of this intrinsic is now a needless impediment to porting codes from GCC to Clang (I've now seen several examples of this). It is true, however, that we still set GNUC_MINOR to 2 (corresponding to GCC 4.2). To compensate for this, and to address the original concern regarding code relying on the old semantics, I've added a warning that specifically details the fact that the semantics have changed and that we provide the newer semantics. Fixes PR8842. llvm-svn: 218905
* Make sure aggregates are properly alligned on MSP430.Job Noorman2014-09-301-1/+1
| | | | llvm-svn: 218666
* clang/test/CodeGen/builtin-assume-aligned.c: Fix for -Asserts.NAKAMURA Takumi2014-09-261-9/+9
| | | | llvm-svn: 218507
* Support the assume_aligned function attributeHal Finkel2014-09-261-0/+23
| | | | | | | | | In addition to __builtin_assume_aligned, GCC also supports an assume_aligned attribute which specifies the alignment (and optional offset) of a function's return value. Here we implement support for the assume_aligned attribute by making use of the @llvm.assume intrinsic. llvm-svn: 218500
* CGBuiltin: Use frem instruction rather than libcall to implement fmodJan Vesely2014-09-261-0/+16
| | | | | | | | AFAICT the semantics of frem match libm's fmod. Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> Reviewed-by: Tom Stellard <tom@stellard.net> llvm-svn: 218488
* Simplify tests.Nico Weber2014-09-242-8/+2
| | | | | | | This reverts bits of r218166 that are no longer necessary now that r218394 made -Wmissing-prototype-for-cc a regular warning. llvm-svn: 218400
* Downgrade error about stdcall decls with no prototype to a warningReid Kleckner2014-09-241-1/+1
| | | | | | | | | | | | | | | | | | Fixes PR21027. The MIDL compiler produces code that does this. If we wanted to improve the warning, I think we could do this: void __stdcall f(); // Don't warn without -Wstrict-prototypes. void g() { f(); // Might warn, the user probably meant for f to take no args. f(1, 2, 3); // Warn, we have no idea what args f takes. f(1); // Error, this is insane, one of these calls is broken. } Reviewers: thakis Differential Revision: http://reviews.llvm.org/D5481 llvm-svn: 218394
* [x86] Fixed argument types in intrinsics:Robert Khasanov2014-09-242-7/+10
| | | | | | | | | | _addcarryx_u64 _addcarry_u64 _subborrow_u64 Thanks Pasi Parviainen for notice. llvm-svn: 218376
* [mips] Fix r218248's testcase to use -O1 instead of -O3.Daniel Sanders2014-09-231-3/+3
| | | | llvm-svn: 218298
* ms-inline-asm: Add a test case for the usage of labels in bracket expressionsEhsan Akhgari2014-09-221-0/+9
| | | | | | | | | | | | Summary: This is a test for this patch: http://reviews.llvm.org/D5445. Reviewers: rnk Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5446 llvm-svn: 218271
* Fix test/CodeGen/mips-varargs.c to use %clang_cc1Kaelyn Takata2014-09-221-3/+3
| | | | | | | Only tests under test/Driver should use %clang, and test/CodeGen in particular must always use %clang_cc1. llvm-svn: 218260
* clang/test/CodeGen/mips-varargs.c: Fixup for -Asserts.NAKAMURA Takumi2014-09-221-21/+20
| | | | llvm-svn: 218256
* [mips] Correct alignment of vectors passed in varargs for the O32 ABI.Daniel Sanders2014-09-221-0/+53
| | | | | | | | | | | | | | | | | | | Summary: Vectors are normally 16-byte aligned, however the O32 ABI enforces a maximum alignment of 8-bytes since the base of the stack is 8-byte aligned. Previously, this was enforced on the caller side, but not on the callee side. This fixes the output of OpenCL's printf when given vectors. Reviewers: atanasyan Reviewed By: atanasyan Subscribers: llvm-commits, pekka.jaaskelainen Differential Revision: http://reviews.llvm.org/D5433 llvm-svn: 218248
* ms-inline-asm: Scope inline asm labels to functionsEhsan Akhgari2014-09-223-8/+55
| | | | | | | | | | | | | | | | Summary: This fixes PR20023. In order to implement this scoping rule, we piggy back on the existing LabelDecl machinery, by creating LabelDecl's that will carry the "internal" name of the inline assembly label, which we will rewrite the asm label to. Reviewers: rnk Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D4589 llvm-svn: 218230
* Follow-up to r214408: Warn on other callee-cleanup functions without ↵Nico Weber2014-09-192-1/+9
| | | | | | | | | | | | | | | | | | prototype too. According to lore, we used to verifier-fail on: void __thiscall f(); int main() { f(1); } So that's fixed now. System headers use prototype-less __stdcall functions, so make that a warning that's DefaultError -- then it fires on regular code but is suppressed in system headers. Since it's used in system headers, we have codegen tests for this; massage them slightly so that they still compile. llvm-svn: 218166
* [x86] Add _addcarry_u{32|64} and _subborrow_u{32|64}.Robert Khasanov2014-09-191-0/+31
| | | | | | | | They are added to adxintrin.h but outside __ADX__ block. These intrinics generates adc and sbb correspondingly that were available before ADX llvm-svn: 218118
* [x86] Added _addcarryx_u32, _addcarryx_u64 intrinsicsRobert Khasanov2014-09-191-0/+17
| | | | llvm-svn: 218117
* [X86, inlineasm] Do not allow using constraint 'x' for a variable larger thanAkira Hatanaka2014-09-181-2/+9
| | | | | | | | 128-bit unless the target CPU supports AVX. rdar://problem/11846140 llvm-svn: 218082
* [X86, inline-asm] Allow 256-bit wide operands for the 'x' constraintsHans Wennborg2014-09-181-0/+6
| | | | | | | The 'x' constraint is for "any SSE register", and GCC seems to include the 256-bit ymm registers in that concept. llvm-svn: 218073
* [X86, inlineasm] Check that the output size is correct for the given constraint.Akira Hatanaka2014-09-182-2/+15
| | | | llvm-svn: 218064
* Fix test case.Akira Hatanaka2014-09-181-2/+2
| | | | | | This is another follow-up patch to r217996. llvm-svn: 218003
* Fix test case.Akira Hatanaka2014-09-181-1/+1
| | | | | | This is a follow-up to r217994. llvm-svn: 217996
* [X86, inline-asm] Check that the input size is correct for constraints R, q, Q,Akira Hatanaka2014-09-171-0/+22
| | | | | | | | | | | S, D, A, y, x, f, t, and u. This is a follow-up patch for r167717. rdar://problem/11846140 rdar://problem/17476970 llvm-svn: 217994
OpenPOWER on IntegriCloud