summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic
Commit message (Collapse)AuthorAgeFilesLines
...
* Implement IRGen for the x86 vectorcall conventionReid Kleckner2014-10-311-0/+2
| | | | | | | | | | | | | | | The most complex aspect of the convention is the handling of homogeneous vector and floating point aggregates. Reuse the homogeneous aggregate classification code that we use on PPC64 and ARM for this. This convention also has a C mangling, and we apparently implement that in both Clang and LLVM. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D6063 llvm-svn: 221006
* [PowerPC] Initial VSX intrinsic support, with min/max for vector doubleBill Schmidt2014-10-311-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have initial support for VSX, we can begin adding intrinsics for programmer access to VSX instructions. This patch performs the necessary enablement in the front end, and tests it by implementing intrinsics for minimum and maximum using the vector double data type. The main change in the front end is to no longer disallow "vector" and "double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector" and "long double" must still be disallowed. The new intrinsics are accessed via vec_max and vec_min with changes in lib/Headers/altivec.h. Note that for v4f32, we already access corresponding VMX builtins, but with VSX enabled we should use the forms that allow all 64 vector registers. The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def. I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is similar to, but much smaller than, builtins-ppc-altivec.c. This allows us to test VSX IR generation without duplicating CHECK lines for the existing bazillion Altivec tests. Since vector double is now legal when VSX is available, I've modified the error message, and changed where we test for it and for vector long double, since the target machine isn't visible in the old place. This serendipitously removed a not-pertinent warning about 'long' being deprecated when used with 'vector', when "vector long double" is encountered and we just want to issue an error. The existing tests test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been updated accordingly, and I've added test/Parser/vsx.c to verify that "vector double" is now legitimate with VSX enabled. There is a companion patch for LLVM. llvm-svn: 220989
* Get rid of SanitizerOptions::Disabled global. NFC.Alexey Samsonov2014-10-301-4/+11
| | | | | | | | | SanitizerOptions is not even a POD now, so having global variable of this type, is not nice. Instead, provide a regular constructor and clear() method, and let each CodeGenFunction has its own copy of SanitizerOptions it uses. llvm-svn: 220920
* Use enumerators instead of hardcoded integers when we decide if keyword is ↵Serge Pavlov2014-10-291-28/+38
| | | | | | enabled. llvm-svn: 220849
* Make VFS and FileManager match the current MemoryBuffer API.Benjamin Kramer2014-10-264-100/+65
| | | | | | | This eliminates converting back and forth between the 3 formats and gives us a more homogeneous interface. llvm-svn: 220657
* Add frontend support for __vectorcallReid Kleckner2014-10-241-2/+3
| | | | | | | | | | | | | Wire it through everywhere we have support for fastcall, essentially. This allows us to parse the MSVC "14" CTP headers, but we will miscompile them because LLVM doesn't support __vectorcall yet. Reviewed By: Aaron Ballman Differential Revision: http://reviews.llvm.org/D5808 llvm-svn: 220573
* [modules] Add support for 'textual header' directives.Richard Smith2014-10-221-19/+15
| | | | | | | | This allows a module to specify that it logically contains a file, but that said file is non-modular and intended for textual inclusion. This allows layering checks to work properly in the presence of such files. llvm-svn: 220448
* Remove unused DiagnosticsEngine::NumErrorsSuppressed member.Rafael Espindola2014-10-222-2/+0
| | | | | | Patch by Brad King! llvm-svn: 220413
* Fixup for r220403: Use getFileLoc() instead of getSpellingLoc() in ↵Alexey Samsonov2014-10-221-1/+1
| | | | | | | | | SanitizerBlacklist. This also handles the case where function name (not its body) is obtained from macro expansion. llvm-svn: 220407
* SanitizerBlacklist: Use spelling location for blacklisting purposes.Alexey Samsonov2014-10-221-1/+2
| | | | | | | | | When SanitizerBlacklist decides if the SourceLocation is blacklisted, we need to first turn it into a SpellingLoc before fetching the filename and scanning "src:" entries. Otherwise we will fail to fecth the correct filename for function definitions coming from macro expansion. llvm-svn: 220403
* Switch C compilations to C11 by default.Richard Smith2014-10-201-3/+3
| | | | | | | | This is long-since overdue, and matches GCC 5.0. This should also be backwards-compatible, because we already supported all of C11 as an extension in C99 mode. llvm-svn: 220244
* Use the triple's isiOS() method instead of checking the value directly. NFC.Bob Wilson2014-10-191-1/+1
| | | | llvm-svn: 220158
* [ASan] Improve blacklisting of global variables.Alexey Samsonov2014-10-171-18/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the way we blacklist global variables in ASan. Now the global is excluded from instrumentation (either regular bounds checking, or initialization-order checking) if: 1) Global is explicitly blacklisted by its mangled name. This part is left unchanged. 2) SourceLocation of a global is in blacklisted source file. This changes the old behavior, where instead of looking at the SourceLocation of a variable we simply considered llvm::Module identifier. This was wrong, as identifier may not correspond to the file name, and we incorrectly disabled instrumentation for globals coming from #include'd files. 3) Global is blacklisted by type. Now we build the type of a global variable using Clang machinery (QualType::getAsString()), instead of llvm::StructType::getName(). After this commit, the active users of ASan blacklist files may have to revisit them (this is a backwards-incompatible change). llvm-svn: 220097
* SanitizerBlacklist: blacklist functions by their source location.Alexey Samsonov2014-10-171-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Teach SanitizerBlacklist to blacklist by SourceLocation. NFC.Alexey Samsonov2014-10-161-2/+9
| | | | llvm-svn: 219993
* Insert poisoned paddings between fields in C++ classes so that ↵Kostya Serebryany2014-10-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove one of SanitizerBlacklist::isIn() overloads. NFC.Alexey Samsonov2014-10-161-8/+12
| | | | | | | | The final goal is to get rid of all the rest overloads that accept LLVM objects (llvm::Function and llvm::GlobalVariable), and pass in source-level entities instead. llvm-svn: 219937
* [CMake] clangBasic: Add Core to LINK_COMPONENTS introduced by r219840.NAKAMURA Takumi2014-10-161-0/+1
| | | | llvm-svn: 219880
* Move SanitizerBlacklist object from CodeGenModule to ASTContext.Alexey Samsonov2014-10-151-0/+3
| | | | | | | | Soon we'll need to have access to blacklist before the CodeGen phase (see http://reviews.llvm.org/D5687), so parse and construct the blacklist earlier. llvm-svn: 219857
* Move SanitizerBlacklist to clangBasic. NFC.Alexey Samsonov2014-10-152-0/+52
| | | | | | | | | | | | This change moves SanitizerBlacklist.h from lib/CodeGen to public Clang headers in include/clang/Basic. SanitizerBlacklist is currently only used in CodeGen to decide which functions/modules should be instrumented, but this will soon change as ASan will optionally modify class layouts during AST construction (http://reviews.llvm.org/D5687). We need blacklist machinery to be available at this point. llvm-svn: 219840
* As requested by Matt Thomas, use long long for intmax_t and int64_t onJoerg Sonnenberger2014-10-151-0/+4
| | | | | | PPC64/NetBSD. llvm-svn: 219839
* Set ABI and DescriptionString first to reduce OS specific logic.Joerg Sonnenberger2014-10-151-10/+13
| | | | | | Use switch for FreeBSD check to allow easier extension. llvm-svn: 219838
* ARM: remove ARM/Thumb distinction for preferred alignment.Tim Northover2014-10-141-60/+30
| | | | | | | | | | | | 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-7/+7
| | | | | | | | | | | 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
* Adds support for the Cortex-A17 processor to ClangRenato Golin2014-10-131-3/+3
| | | | | | Patch by Matthew Wahab. llvm-svn: 219607
* [PowerPC] Reduce names from Power8Vector to P8VectorBill Schmidt2014-10-101-4/+4
| | | | | | Per Hal Finkel's review, improving typability of some variable names. llvm-svn: 219515
* [PowerPC] Add feature for Power8 vector extensionsBill Schmidt2014-10-101-1/+9
| | | | | | | | | | | | | | | | | | The current VSX feature for PowerPC specifies availability of the VSX instructions added with the 2.06 architecture version. With 2.07, the architecture adds new instructions to both the Category:Vector and Category:VSX instruction sets. Additionally, unaligned vector storage operations have improved performance. This patch adds a feature to provide access to the new instructions and performance capabilities of Power8. For compatibility with GCC, the feature is controlled via a new -mpower8-vector switch, and the feature causes the __POWER8_VECTOR__ builtin define to be generated by the preprocessor. There is a companion patch for llvm being committed at the same time. llvm-svn: 219502
* [OPENMP] 'omp teams' directive basic support.Alexey Bataev2014-10-091-0/+14
| | | | | | Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive. llvm-svn: 219385
* Revert "[OPENMP] 'omp teams' directive basic support. Includes parsing and ↵Renato Golin2014-10-081-14/+0
| | | | | | | | | semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive." This reverts commit r219197 because it broke ARM self-hosting buildbots with segmentation fault errors in many tests. llvm-svn: 219289
* [OPENMP] 'omp teams' directive basic support.Alexey Bataev2014-10-071-0/+14
| | | | | | Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive. llvm-svn: 219197
* Patch to wrap up '_' as separator in version numbersFariborz Jahanian2014-10-061-2/+2
| | | | | | | | | in availability attribute by preserving this info. in VersionTuple and using it in pretty printing of attributes and yet using '.' as separator when diagnosing unavailable message calls. rdar://18490958 llvm-svn: 219124
* Adds 'override' to overriding methods. NFC.Fariborz Jahanian2014-10-011-13/+13
| | | | | | These were uncoveredby my yet undelivered patch. llvm-svn: 218774
* [ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DPOliver Stannard2014-10-011-3/+3
| | | | | | | | | The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modeled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218748
* Make sure aggregates are properly alligned on MSP430.Job Noorman2014-09-301-1/+1
| | | | llvm-svn: 218666
* [OPENMP] Parsing/Sema of directive omp parallel for simdAlexander Musman2014-09-231-7/+19
| | | | llvm-svn: 218299
* Silence a signed/unsigned mismatch warning from MSVC; NFC.Aaron Ballman2014-09-191-1/+1
| | | | llvm-svn: 218121
* [x86] Enable broadwell target in clang.Robert Khasanov2014-09-191-5/+37
| | | | | | Added -madx option llvm-svn: 218116
* [OPENMP] Initial parsing/sema analysis of 'target' directive.Alexey Bataev2014-09-191-0/+10
| | | | llvm-svn: 218110
* [X86, inlineasm] Do not allow using constraint 'x' for a variable larger thanAkira Hatanaka2014-09-181-1/+2
| | | | | | | | 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-1/+2
| | | | | | | 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-181-3/+23
| | | | llvm-svn: 218064
* Parsing/Sema of directive omp for simdAlexander Musman2014-09-181-3/+16
| | | | llvm-svn: 218029
* Basic: use hex string for __ARM_FP macroSaleem Abdulrasool2014-09-181-1/+2
| | | | | | | The ARM ACLE describes the values as hex constants rather than numeric constants; follow suit. Address post-commit review comments from Jon Roelofs. llvm-svn: 218009
* [X86, inline-asm] Check that the input size is correct for constraints R, q, Q,Akira Hatanaka2014-09-171-1/+26
| | | | | | | | | | | 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
* Basic: add support for ARM ACLE 6.5.1Saleem Abdulrasool2014-09-171-12/+32
| | | | | | | | Extend ARM ACLE support (Section 6.5.1) for AArch32. Define __ARM_FP if hardware floating point support is available as per the value defined by the ACLE. llvm-svn: 217957
* Basic: use range-based for loops for ARM targetSaleem Abdulrasool2014-09-171-19/+20
| | | | | | | Tweak handleTargetFeature for the ARM(32) target to use range based for loops. NFC. llvm-svn: 217956
* Basic: whitespace fixup for ARM target infoSaleem Abdulrasool2014-09-171-2/+1
| | | | | | Fix whitespace. NFC. llvm-svn: 217955
* [ARM] Add ACLE predefines: maxmin, rounding and h/w integer divisionJames Molloy2014-09-151-0/+8
| | | | | | Patch by Assad Hashmi! llvm-svn: 217760
* No need to use PNaCl's calling convention since PNaCl now uses a separate ↵JF Bastien2014-09-121-3/+0
| | | | | | approach for calling conventions. llvm-svn: 217696
* Add support for le64.JF Bastien2014-09-121-0/+60
| | | | | | | | | | | | | | | | | Summary: le64 is a generic little-endian 64-bit processor, mimicking le32. Also see the associated LLVM change. Test Plan: make check-all Reviewers: dschuff Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5318 llvm-svn: 217694
OpenPOWER on IntegriCloud