summaryrefslogtreecommitdiffstats
path: root/clang/test/Preprocessor
Commit message (Collapse)AuthorAgeFilesLines
* [MSP430] Ajust f32/f64 alignment according to MSP430 EABIAnton Korobeynikov2019-01-251-1/+1
| | | | | | | | Patch by Kristina Bessonova! Differential Revision: https://reviews.llvm.org/D57015 llvm-svn: 352177
* [WebAssembly] Add a __wasi__ target macroDan Gohman2019-01-241-0/+7
| | | | | | | | | This adds a `__wasi__` macro for the wasi OS, similar to `__linux__` etc. for other OS's. Differential Revision: https://reviews.llvm.org/D57155 llvm-svn: 352105
* [WebAssembly] Support __float128Dan Gohman2019-01-241-0/+1
| | | | | | | | This enables support for the "__float128" keyword. Differential Revision: https://reviews.llvm.org/D57154 llvm-svn: 352100
* [WebAssembly] Factor commonality between wasm32 and wasm64 in ↵Dan Gohman2019-01-241-633/+342
| | | | | | | | | | | test/Preprocessor/init.c Use the -check-prefixes= feature to merge most of the WEBASSEMBLY32 and WEBASSEMBLY64 test checks into a shared WEBASSEMBLY test check. Differential Revision: https://reviews.llvm.org/D57153 llvm-svn: 352099
* [MSVC Compat] Fix typo correction for inclusion directives.Volodymyr Sapsai2019-01-151-0/+1
| | | | | | | | | | | | | | | In MSVC compatibility mode we were checking not the typo corrected filename but the original filename. Reviewers: christylee, compnerd Reviewed By: christylee Subscribers: jkorous, dexonsmith, sammccall, hokein, cfe-commits Differential Revision: https://reviews.llvm.org/D56631 llvm-svn: 351232
* [test] Update support for Exynos M4 (NFC)Evandro Menezes2019-01-111-1/+2
| | | | | | Update test cases for Exynos M4. llvm-svn: 350954
* [WebAssembly] Add unimplemented-simd128 feature, gate builtinsThomas Lively2019-01-101-0/+9
| | | | | | | | | | | Summary: Depends on D56501. Also adds a macro define `__wasm_unimplemented_simd128__` for feature detection of unimplemented SIMD builtins. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, sunfish, kristina, cfe-commits, rrwinterton llvm-svn: 350909
* Android is not GNU, so don't claim that it is.Dan Albert2019-01-081-0/+2
| | | | | | | | | | | | Reviewers: pirama, srhines Reviewed By: srhines Subscribers: kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D55953 llvm-svn: 350664
* [Clang] Add __builtin_launderEric Fiselier2018-12-141-0/+1
| | | | | | | | | | | | | | | | | Summary: This patch adds `__builtin_launder`, which is required to implement `std::launder`. Additionally GCC provides `__builtin_launder`, so thing brings Clang in-line with GCC. I'm not exactly sure what magic `__builtin_launder` requires, but based on previous discussions this patch applies a `@llvm.invariant.group.barrier`. As noted in previous discussions, this may not be enough to correctly handle vtables. Reviewers: rnk, majnemer, rsmith Reviewed By: rsmith Subscribers: kristina, Romain-Geissler-1A, erichkeane, amharc, jroelofs, cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D40218 llvm-svn: 349195
* Basic: make `int_least64_t` and `int_fast64_t` match on DarwinSaleem Abdulrasool2018-12-121-12/+12
| | | | | | | | | The Darwin targets use `int64_t` and `uint64_t` to define the `int_least64_t` and `int_fast64_t` types. The underlying type is actually a `long long`. Match the types to allow the printf specifiers to work properly and have the compiler vended macros match the implementation on the target. llvm-svn: 348939
* [Hexagon] Add support for Hexagon V66Krzysztof Parzyszek2018-12-051-0/+24
| | | | llvm-svn: 348415
* PTH-- Remove feature entirely-Erich Keane2018-12-041-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debugging a boost build with a modified version of Clang, I discovered that the PTH implementation stores TokenKind in 8 bits. However, we currently have 368 TokenKinds. The result is that the value gets truncated and the wrong token gets picked up when including PTH files. It seems that this will go wrong every time someone uses a token that uses the 9th bit. Upon asking on IRC, it was brought up that this was a highly experimental features that was considered a failure. I discovered via googling that BoostBuild (mostly Boost.Math) is the only user of this feature, using the CC1 flag directly. I believe that this can be transferred over to normal PCH with minimal effort: https://github.com/boostorg/build/issues/367 Based on advice on IRC and research showing that this is a nearly completely unused feature, this patch removes it entirely. Note: I considered leaving the build-flags in place and making them emit an error/warning, however since I've basically identified and warned the only user, it seemed better to just remove them. Differential Revision: https://reviews.llvm.org/D54547 Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9 llvm-svn: 348266
* [X86] Add -march=cascadelake support in clang.Craig Topper2018-11-271-0/+97
| | | | | | | | | | This is skylake-avx512 with the addition of avx512vnni ISA. Patch by Jianping Chen Differential Revision: https://reviews.llvm.org/D54792 llvm-svn: 347682
* Fix combining pragma __debug dump & parser_crash with -EDavid Blaikie2018-11-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Previously these would be transformed into annotation tokens and the preprocessor would then assume they were real tokens with source locations and assert/UB. Other pragmas that produce annotation tokens aren't a problem because they aren't handled if the parser isn't hooked up - ParsePragma.cpp registers those handlers & isn't run for pure preprocessing. So they're treated as unknown pragmas & printed verbatim by the preprocessor. Perhaps these pragmas should be treated the same way? But they got mixed in with other __debug pragmas that do need to be handled during preprocessing. The third __debug pragma that produces an annotation token is 'captured' - which had its own fix for this issue - by not inserting the annotation token in the first place if it detected that it was in preprocessing mode. I've removed that fix (from Lex/Pragma.cpp) in favor of the more general one in Frontend/PrintPreprocessedOutput.cpp. llvm-svn: 346928
* Introduce the _Clang scoped attribute token.Aaron Ballman2018-11-091-11/+27
| | | | | | Currently, we only accept clang as the scoped attribute identifier for double square bracket attributes provided by Clang, but this has the potential to conflict with user-defined macros. To help alleviate these concerns, this introduces the _Clang scoped attribute identifier as an alias for clang. It also introduces a warning with a fixit on the off chance someone attempts to use __clang__ as the scoped attribute (which is a predefined compiler identification macro). llvm-svn: 346521
* [AArch64] Implement FP16FML intrinsicsBryan Chan2018-10-251-12/+18
| | | | | | | | | | | | | Generate the FP16FML intrinsics into arm_neon.h (AArch64 only for now). Add two new type modifiers to NeonEmitter to handle the new prototypes. Define __ARM_FEATURE_FP16FML when +fp16fml is enabled and guard the intrinsics with the macro in arm_neon.h. Based on a patch by Gao Yiling. Differential Revision: https://reviews.llvm.org/D53633 llvm-svn: 345344
* Support accepting __gnu__ as a scoped attribute namespace that aliases to gnu.Aaron Ballman2018-10-241-11/+15
| | | | | | This is useful in libstdc++ to avoid clashes with identifiers in the user's namespace. llvm-svn: 345132
* Add language standard aliases for -std=c18, -std=gnu18, and -std=iso9899:2018.Aaron Ballman2018-10-181-0/+1
| | | | | | As described in D40225, the C17 standard was balloted and approved in 2017, but the ISO publication process delayed the actual publication until 2018. WG14 considers the release to be C17 and describes it as such, but users can still be confused by the publication year which is why -std=c18 adds value. These aliases map to c17 and are all supported by GCC 8.x with the same behavior. Note that the value of __STDC_VERSION__ remains at 201710L. llvm-svn: 344749
* [AArch64] Define __ELF__ for aarch64-none-elf and other similar triples.Eli Friedman2018-10-171-0/+1
| | | | | | | | "aarch64-none-elf" is commonly used for AArch64 baremetal toolchains. Differential Revision: https://reviews.llvm.org/D53348 llvm-svn: 344710
* [X86] Remove FeatureRTM from Skylake processor listCraig Topper2018-10-101-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There are a LOT of Skylakes and later without TSX-NI. Examples: - SKL: https://ark.intel.com/products/136863/Intel-Core-i3-8121U-Processor-4M-Cache-up-to-3-20-GHz- - KBL: https://ark.intel.com/products/97540/Intel-Core-i7-7560U-Processor-4M-Cache-up-to-3-80-GHz- - KBL-R: https://ark.intel.com/products/149091/Intel-Core-i7-8565U-Processor-8M-Cache-up-to-4-60-GHz- - CNL: https://ark.intel.com/products/136863/Intel-Core-i3-8121U-Processor-4M-Cache-up-to-3_20-GHz This feature seems to be present only on high-end desktop and server chips (I can't find any SKX without). This commit leaves it disabled for all processors, but can be re-enabled for specific builds with -mrtm. Matches https://reviews.llvm.org/D53041 Patch by Thiago Macieira Reviewers: erichkeane, craig.topper Reviewed By: craig.topper Subscribers: lebedev.ri, cfe-commits Differential Revision: https://reviews.llvm.org/D53042 llvm-svn: 344117
* Introduce code_model macrosAli Tamur2018-10-081-18/+22
| | | | | | | | | | | | | | | | | | | Summary: gcc defines macros such as __code_model_small_ based on the user passed command line flag -mcmodel. clang accepts a flag with the same name and similar effects, but does not generate any macro that the user can use. This cl narrows the gap between gcc and clang behaviour. However, achieving full compatibility with gcc is not trivial: The set of valid values for mcmodel in gcc and clang are not equal. Also, gcc defines different macros for different architectures. In this cl, we only tackle an easy part of the problem and define the macro only for x64 architecture. When the user does not specify a mcmodel, the macro for small code model is produced, as is the case with gcc. Reviewers: compnerd, MaskRay Reviewed By: MaskRay Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D52920 llvm-svn: 344000
* [AArch64][ARM] Context sensitive meaning of cryptoSjoerd Meijer2018-10-041-0/+95
| | | | | | | | | | | | | | For AArch64, crypto means: - sm4 + sha3 + sha2 + aes for Armv8.4-A and up, and - sha2 + aes for Armv8.3-A and earlier. For AArch32: Crypto means sha2 + aes, because the Armv8.2-A crypto instructions were added to AArch64 only. Differential Revision: https://reviews.llvm.org/D50179 llvm-svn: 343758
* [Preprocessor] Fix a crash when handling non-alpha include header.Haojian Wu2018-10-011-0/+3
| | | | | | | | | | | | | Summary: the crash is casued by an assertion in StringRef. (llvm::StringRef::front() const: Assertion `!empty()' failed.) Reviewers: sammccall Subscribers: jsji, cfe-commits Differential Revision: https://reviews.llvm.org/D52721 llvm-svn: 343481
* [X86] Add the movbe instruction intrinsics from icc.Craig Topper2018-09-281-0/+32
| | | | | | | | | | These intrinsics exist in icc. They can be found on the Intel Intrinsics Guide website. All the backend support is in place to pattern match a load+bswap or a bswap+store pattern to the MOVBE instructions. So we just need to get the frontend to emit the correct IR. The pointer arguments in icc are declared as void so I had to jump through a packed struct to forcing a specific alignment on the load/store. Same trick we use in the unaligned vector load/store intrinsics Differential Revision: https://reviews.llvm.org/D52586 llvm-svn: 343343
* [ARM] Prevent DSP and SIM32 being set for v6mSam Parker2018-09-281-0/+7
| | | | | | | | | My previous change (rL340911) set the two features for architectures >= 6, which wrongly includes v6m. Now set to >= 6 and not Cortex-M. Differential Revision: https://reviews.llvm.org/D52644 llvm-svn: 343309
* [ARM/AArch64][v8.5A] Add Armv8.5-A targetOliver Stannard2018-09-261-0/+15
| | | | | | | | | | | This patch allows targetting Armv8.5-A from Clang. Most of the implementation is in TargetParser, so this is mostly just adding tests. Patch by Pablo Barrio! Differential revision: https://reviews.llvm.org/D52491 llvm-svn: 343111
* [ARM][AArch64] Add feature +fp16fmlSjoerd Meijer2018-09-242-5/+72
| | | | | | | | | | | | | | | | | | | | | Armv8.4-A adds a few FP16 instructions that can optionally be implemented in CPUs of Armv8.2-A and above. This patch adds a feature to clang to permit selection of these instructions. This interacts with the +fp16 option as follows: Prior to Armv8.4-A: *) +fp16fml implies +fp16 *) +nofp16 implies +nofp16fml From Armv8.4-A: *) The above conditions apply, additionally: +fp16 implies +fp16fml Patch by Bernard Ogden. Differential Revision: https://reviews.llvm.org/D50229 llvm-svn: 342862
* Remove failing test.Zachary Turner2018-09-201-3/+0
| | | | | | | | | | Removing on behalf of Jorge Moya. This test is broken on Windows due to it actually being able to resolve the path. There is an actual Windows-specific bug somewhere, but we already have sufficient test coverage of this with a different test, so removing this was the approach suggested by Jorge. llvm-svn: 342693
* Add testcases for r342667.Eric Christopher2018-09-202-0/+6
| | | | llvm-svn: 342668
* Basic: correct `__WINT_TYPE__` on WindowsSaleem Abdulrasool2018-09-192-4/+4
| | | | | | | | | Windows uses `unsigned short` for `wint_t`. Correct the type definition as vended by the compiler. This type is defined in corecrt.h and is unconditionally typedef'ed. cl does not have an equivalent to `__WINT_TYPE__` which is why this was never detected. llvm-svn: 342557
* Diagnose likely typos in #include directives.Richard Smith2018-09-132-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When someone writes #include "<some_file>" or #include " some_file " the compiler returns "file not fuond..." with fonts and quotes that may make it hard to see there are excess quotes or surprising bytes in the filename. Assuming that files are usually logically named and start and end with an alphanumeric character, we can check for the file's existence by stripping the non-alphanumeric leading or trailing characters. If the file is found, emit a non-fatal error with a FixItHint. Patch by Christy Lee! Reviewers: aaron.ballman, erikjv, rsmith Reviewed By: rsmith Subscribers: lebedev.ri, xbolva00, sammccall, modocache, erikjv, aaron.ballman, cfe-commits Differential Revision: https://reviews.llvm.org/D51333 llvm-svn: 342177
* Fix test regression in r341862Erich Keane2018-09-101-10/+0
| | | | | | | The commit updates when AES is enabled, but failed to update the tests. This patch fixes them. llvm-svn: 341871
* Revert the tests that should've been reverted in rL341115Artem Belevich2018-08-302-67/+1
| | | | llvm-svn: 341118
* Add predefined macro __gnu_linux__ for proper aux-tripleYaxun Liu2018-08-291-1/+3
| | | | | | | | | | | | Clang predefine macro __linx__ for aux-triple with Linux OS but does not predefine macro __gnu_linux__. This causes some compilation error for certain applications, e.g. Eigen. This patch fixes that. Differential Revision: https://reviews.llvm.org/D51441 llvm-svn: 340967
* [ARM] Set __ARM_FEATURE_SIMD32 for +dsp coresSam Parker2018-08-291-4/+8
| | | | | | | | | | | | | | ARM_FEATURE_DSP is already set for targets with the +dsp feature. In the backend, this target feature is also used to represent the availability of the of the instructions that the ACLE guard through the __ARM_FEATURE_SIMD32 macro. We don't have any cores that implement one and not the other, so set this macro for cores later than V6 or for Cortex-M cores that the target parser, or user, reports that the 'dsp' instructions are supported. Differential Revision: https://reviews.llvm.org/D51093 llvm-svn: 340911
* [OpenMP][NVPTX] Use appropriate _CALL_ELF macro when offloadingGheorghe-Teodor Bercea2018-08-271-4/+6
| | | | | | | | | | | | | | Summary: When offloading to a device and using the powerpc64le version of the auxiliary triple, the _CALL_ELF macro is not set correctly to 2 resulting in the attempt to include a header that does not exist. This patch fixes this problem. Reviewers: Hahnfeld, ABataev, caomhin Reviewed By: Hahnfeld Subscribers: guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D51312 llvm-svn: 340772
* [CUDA/OpenMP] Define only some host macros during device compilationJonas Hahnfeld2018-08-251-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling CUDA or OpenMP device code Clang parses header files that expect certain predefined macros from the host architecture. To make this work the compiler passes the host triple via the -aux-triple argument and (until now) pulls in all macros for that "auxiliary triple" unconditionally. However this results in defines like __SSE_MATH__ that will trigger inline assembly making use of the "advertised" target features. See the discussion of D47849 and PR38464 for a detailed explanation of the encountered problems. Instead of blacklisting "known bad" examples this patch starts adding defines that are needed for certain headers like bits/wordsize.h and bits/mathinline.h. The disadvantage of this approach is that it decouples the definitions from their target toolchain. However in my opinion it's more important to keep definitions for one header close together. For one this will include a clear documentation why these particular defines are needed. Furthermore it simplifies maintenance because adding defines for a new header or support for a new aux-triple only needs to touch one piece of code. Differential Revision: https://reviews.llvm.org/D50845 llvm-svn: 340681
* [clang][mips] Set __mips_fpr correctly for -mfpxxStefan Maksimovic2018-08-221-3/+38
| | | | | | | | | | | | | | | | | | | | Set __mips_fpr to 0 if o32 ABI is used with either -mfpxx or none of -mfp32, -mfpxx, -mfp64 being specified. Introduce additional checks: -mfpxx is only to be used in conjunction with the o32 ABI. report an error when incompatible options are provided. Formerly no errors were raised when combining n32/n64 ABIs with -mfp32 and -mfpxx. There are other cases when __mips_fpr should be set to 0 that are not covered, ex. using o32 on a mips64 cpu which is valid but not supported in the backend as of yet. Differential Revision: https://reviews.llvm.org/D50557 llvm-svn: 340391
* [Android] Increase default new alignment for AndroidPirama Arumuga Nainar2018-08-011-1/+1
| | | | | | | | | | | | | | Summary: Android's memory allocators also guarantee 8-byte alignment for 32-bit architectures and 16-byte alignment for 64-bit. Reviewers: rsmith Subscribers: cfe-commits, srhines, enh Differential Revision: https://reviews.llvm.org/D50112 llvm-svn: 338603
* [Preprocessor] Stop entering included files after hitting a fatal error.Volodymyr Sapsai2018-07-254-0/+15
| | | | | | | | | | | | | | | | | Fixes a problem when we have multiple inclusion cycles and try to enumerate all possible ways to reach the max inclusion depth. rdar://problem/38871876 Reviewers: bruno, rsmith, jkorous, aaron.ballman Reviewed By: bruno, jkorous, aaron.ballman Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D48786 llvm-svn: 337953
* [WebAssembly] Change size_t to `unsigned long`.Dan Gohman2018-07-241-20/+20
| | | | | | | | | | | | Changing it to unsigned long (which is 32-bit on wasm32) makes it the same type as wasm64 (where unsigned long is 64-bit), which would eliminate the most common cause for mangled names being different between wasm32 and wasm64. For example, export lists containing symbol names could now often be the same between wasm32 and wasm64. Differential Revision: https://reviews.llvm.org/D40526 llvm-svn: 337783
* [MS] Update _MSVC_LANG values for C++17 and C++2aReid Kleckner2018-07-232-103/+110
| | | | | | Fixes PR38262 llvm-svn: 337715
* By popular demand, switch in64_t on NetBSD/AArch64 and NetBSD/PowerPC64Joerg Sonnenberger2018-07-172-36/+36
| | | | | | to long for consistency with other 64bit platforms. llvm-svn: 337271
* [hmaptool] Turn %hmaptool into a proper substitutionBenjamin Kramer2018-06-223-3/+3
| | | | | | | This is still super ugly, but at least it doesn't require working directories to just line up perfectly for python to find the tool. llvm-svn: 335330
* Re-apply: Add python tool to dump and construct header mapsBruno Cardoso Lopes2018-06-219-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | Header maps are binary files used by Xcode, which are used to map header names or paths to other locations. Clang has support for those since its inception, but there's not a lot of header map testing around. Since it's a binary format, testing becomes pretty much brittle and its hard to even know what's inside if you don't have the appropriate tools. Add a python based tool that allows creating and dumping header maps based on a json description of those. While here, rewrite tests to use the tool and remove the binary files from the tree. This tool was initially written by Daniel Dunbar. Thanks to Stella Stamenova for helping make this work on Windows. Differential Revision: https://reviews.llvm.org/D46485 rdar://problem/39994722 llvm-svn: 335295
* Revert "Add python tool to dump and construct header maps"Bruno Cardoso Lopes2018-06-219-28/+11
| | | | | | | | | | | This reverts commit fcfa2dd517ec1a6045a81e8247e346d630a22618. Broke bots: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11315 http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/10411/steps/test-check-all/logs/stdio llvm-svn: 335196
* Add python tool to dump and construct header mapsBruno Cardoso Lopes2018-06-209-11/+28
| | | | | | | | | | | | | | | | | | | | | | | Header maps are binary files used by Xcode, which are used to map header names or paths to other locations. Clang has support for those since its inception, but there's not a lot of header map testing around. Since it's a binary format, testing becomes pretty much brittle and its hard to even know what's inside if you don't have the appropriate tools. Add a python based tool that allows creating and dumping header maps based on a json description of those. While here, rewrite tests to use the tool and remove the binary files from the tree. This tool was initially written by Daniel Dunbar. Differential Revision: https://reviews.llvm.org/D46485 rdar://problem/39994722 llvm-svn: 335177
* [PowerPC] The __float128 type should only be available on Power9Stefan Pintilie2018-06-131-1/+1
| | | | | | | | | | | | Diasble the use of the type __float128 for PPC machines older than Power9. The use of -mfloat128 for PPC machine older than Power9 will result in an error. Differential Revision: https://reviews.llvm.org/D48088 llvm-svn: 334613
* [PATCH 2/2] [test] Add support for Samsung Exynos M4 (NFC)Evandro Menezes2018-06-062-0/+19
| | | | | | Add test cases for Exynos M4. llvm-svn: 334116
* [x86] invpcid intrinsicGabor Buella2018-05-251-0/+14
| | | | | | | | | | | | An intrinsic for an old instruction, as described in the Intel SDM. Reviewers: craig.topper, rnk Reviewed By: craig.topper, rnk Differential Revision: https://reviews.llvm.org/D47142 llvm-svn: 333256
OpenPOWER on IntegriCloud