summaryrefslogtreecommitdiffstats
path: root/clang/test/Preprocessor
Commit message (Collapse)AuthorAgeFilesLines
* [X86] Remove what little support we had for MPXCraig Topper2019-08-291-22/+0
| | | | | | | | | | | | | | | -Deprecate -mmpx and -mno-mpx command line options -Remove CPUID detection of mpx for -march=native -Remove MPX from all CPUs -Remove MPX preprocessor define I've left the "mpx" string in the backend so we don't fail on old IR, but its not connected to anything. gcc has also deprecated these command line options. https://www.phoronix.com/scan.php?page=news_item&px=GCC-Patch-To-Drop-MPX Differential Revision: https://reviews.llvm.org/D66669 llvm-svn: 370393
* Allow standards-based attributes to have leading and trailing underscores.Aaron Ballman2019-08-152-0/+7
| | | | | | This gives library implementers a way to use standards-based attributes that do not conflict with user-defined macros of the same name. Attributes in C2x require this behavior normatively (C2x 6.7.11p4), but there's no reason to not have the same behavior in C++, especially given that such attributes may be used by a C library consumed by a C++ compilation. llvm-svn: 369033
* Add __has_builtin support for builtin function-like type traits.Richard Smith2019-08-142-1/+52
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously __has_builtin(__builtin_*) would return false for __builtin_*s that we modeled as keywords rather than as functions (because they take type arguments). With this patch, all builtins that are called with function-call-like syntax return true from __has_builtin (covering __builtin_* and also the __is_* and __has_* type traits and the handful of similar builtins without such a prefix). Update the documentation on __has_builtin and on type traits to match. While doing this I noticed the type trait documentation was out of date and incomplete; that's fixed here too. Reviewers: aaron.ballman Subscribers: jfb, kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66100 llvm-svn: 368785
* [X86] Support -march=tigerlakePengfei Wang2019-08-121-0/+127
| | | | | | | | | | | | Support -march=tigerlake for x86. Compare with Icelake Client, It include 4 more new features ,they are avx512vp2intersect, movdiri, movdir64b, shstk. Patch by Xiang Zhang (xiangzhangllvm) Differential Revision: https://reviews.llvm.org/D65840 llvm-svn: 368543
* Don't diagnose errors when a file matches an include componentReid Kleckner2019-08-093-0/+5
| | | | | | | | | This regressed in r368322, and was reported as PR42948 and on the mailing list. The fix is to ignore the specific error code for this case. The problem doesn't seem to reproduce on Windows, where a different error code is used instead. llvm-svn: 368475
* [Preprocessor] Always discard body of #define if we failed to parse itIlya Biryukov2019-08-011-0/+5
| | | | | | | | | | | | | | | | | | | | Summary: Preivously we would only discard it if we failed to parse parameter lists. If we do not consume the body, parser sees tokens inside directive. In turn, this leads to spurious diagnostics and a crash in TokenBuffer, see the added tests. Reviewers: sammccall Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65517 llvm-svn: 367530
* [AArch64] Disable __ARM_FEATURE_SVE without ACLE.Sander de Smalen2019-07-301-1/+1
| | | | | | | | | | | | | | | | | The Arm C Language Extensions for SVE document specifies that __ARM_FEATURE_SVE should be set when the compiler supports SVE and implements all the extensions described in the document. This is currently not yet the case, so the feature should be disabled until the compiler can provide all the extensions as described. Reviewers: c-rhodes, rengolin, rovka, ktkachov Reviewed By: rengolin Differential Revision: https://reviews.llvm.org/D65404 llvm-svn: 367301
* Implement P1771Erich Keane2019-07-251-1/+1
| | | | | | | | | | | | | As passed in the Cologne meeting and treated by Core as a DR, [[nodiscard]] was applied to constructors so that they can be diagnosed in cases where the user forgets a variable name for a type. The intent is to enable the library to start using this on the constructors of scope_guard/lock_guard. Differential Revision: https://reviews.llvm.org/D64914 llvm-svn: 367027
* [OpenCL] Rename lang mode flag for C++ modeAnastasia Stulova2019-07-251-1/+1
| | | | | | | | | | | | Rename lang mode flag to -cl-std=clc++/-cl-std=CLC++ or -std=clc++/-std=CLC++. This aligns with OpenCL C conversion and removes ambiguity with OpenCL C++. Differential Revision: https://reviews.llvm.org/D65102 llvm-svn: 367008
* [clang, test] Fix Clang :: Headers/max_align.c on 64-bit SPARCRainer Orth2019-07-231-0/+1
| | | | | | | | | | | | | | | | | | | | | Clang :: Headers/max_align.c currently FAILs on 64-bit SPARC: error: 'error' diagnostics seen but not expected: File /vol/llvm/src/clang/dist/test/Headers/max_align.c Line 12: static_assert failed due to requirement '8 == _Alignof(max_align_t)' "" 1 error generated. This happens because SuitableAlign isn't defined for SPARCv9 unlike SPARCv8 (which uses the default of 64 bits). gcc's sparc/sparc.h has #define BIGGEST_ALIGNMENT (TARGET_ARCH64 ? 128 : 64) This patch sets SuitableAlign to match and updates the corresponding testcase. Tested on sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D64487 llvm-svn: 366820
* Revert the change to the [[nodiscard]] feature test macro value.Aaron Ballman2019-07-221-1/+1
| | | | | | This value only gets bumped once both P1301 and P1771 are implemented. llvm-svn: 366682
* Implement P1301R4, which allows specifying an optional message on the ↵Aaron Ballman2019-07-201-1/+1
| | | | | | | | [[nodiscard]] attribute. This also bumps the attribute feature test value and introduces the notion of a C++2a extension warning. llvm-svn: 366626
* [RISCV] Hard float ABI supportAlex Bradbury2019-07-181-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The RISC-V hard float calling convention requires the frontend to: * Detect cases where, once "flattened", a struct can be passed using int+fp or fp+fp registers under the hard float ABI and coerce to the appropriate type(s) * Track usage of GPRs and FPRs in order to gate the above, and to determine when signext/zeroext attributes must be added to integer scalars This patch attempts to do this in compliance with the documented ABI, and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as author of that code I've tagged you as reviewer for initial feedback on my usage. Note that a previous version of the ABI indicated that when passing an int+fp struct using a GPR+FPR, the int would need to be sign or zero-extended appropriately. GCC never did this and the ABI was changed, which makes life easier as ABIArgInfo::CoerceAndExpand can't currently handle sign/zero-extension attributes. Re-landed after backing out 366450 due to missed hunks. Differential Revision: https://reviews.llvm.org/D60456 llvm-svn: 366480
* Revert "[RISCV] Hard float ABI support" r366450Alex Bradbury2019-07-181-24/+0
| | | | | | The commit was missing a few hunks. Will fix and recommit. llvm-svn: 366454
* [RISCV] Hard float ABI supportAlex Bradbury2019-07-181-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | The RISC-V hard float calling convention requires the frontend to: * Detect cases where, once "flattened", a struct can be passed using int+fp or fp+fp registers under the hard float ABI and coerce to the appropriate type(s) * Track usage of GPRs and FPRs in order to gate the above, and to determine when signext/zeroext attributes must be added to integer scalars This patch attempts to do this in compliance with the documented ABI, and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as author of that code I've tagged you as reviewer for initial feedback on my usage. Note that a previous version of the ABI indicated that when passing an int+fp struct using a GPR+FPR, the int would need to be sign or zero-extended appropriately. GCC never did this and the ABI was changed, which makes life easier as ABIArgInfo::CoerceAndExpand can't currently handle sign/zero-extension attributes. Differential Revision: https://reviews.llvm.org/D60456 llvm-svn: 366450
* Change a lit test to permit vendor specific clang versionNathan Lanza2019-07-161-1/+1
| | | | | | | A test manually checks for the string `__VERSION__ "Clang`. This needs to permit vendor specific variants. llvm-svn: 366166
* Allow for vendor prefixes in a list testNathan Lanza2019-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Preprocessor/init.c contains a line that explicitly checks for the string __VERSION__ "Clang{{.*}} It's valid to have a toolchain configured to emit a vendor prefix before the word Clang. e.g. __VERSION__ "Vendor Clang{{.*}} Subscribers: fedor.sergeev, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64772 llvm-svn: 366159
* Update __VERSION__ to remove the hardcoded 4.2.1 versionSylvestre Ledru2019-07-151-2/+2
| | | | | | | | | | | | | | | | | | Summary: Just like in https://reviews.llvm.org/D56803 for -dumpversion Reviewers: rnk Reviewed By: rnk Subscribers: dexonsmith, lebedev.ri, hubert.reinterpretcast, xbolva00, fedor.sergeev, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63048 llvm-svn: 366091
* [TargetParser][ARM] Account dependencies when processing target featuresAlexandros Lamprineas2019-07-141-6/+23
| | | | | | | | | | Teaches ARM::appendArchExtFeatures to account dependencies when processing target features: i.e. when you say -march=armv8.1-m.main+mve.fp+nofp it means mve.fp should get discarded too. (Split from D63936) Differential Revision: https://reviews.llvm.org/D64048 llvm-svn: 366031
* Support __seg_fs and __seg_gs on x86JF Bastien2019-07-141-0/+7
| | | | | | | | | | | | | | | | | | | | | Summary: GCC supports named address spaces macros: https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html clang does as well with address spaces: https://clang.llvm.org/docs/LanguageExtensions.html#memory-references-to-specified-segments Add the __seg_fs and __seg_gs macros for compatibility with GCC. <rdar://problem/52944935> Subscribers: jkorous, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64676 llvm-svn: 366028
* This reverts commit 632a36bfcfc8273c1861f04ff6758d863c47c784.Sylvestre Ledru2019-07-131-0/+4
| | | | | | | | | | | | Some targets such as Python 2.7.16 still use VERSION in their builds. Without VERSION defined, the source code has syntax errors. Reverting as it will probably break many other things. Noticed by Sterling Augustine llvm-svn: 365992
* Remove __VERSION__Sylvestre Ledru2019-07-121-4/+0
| | | | | | | | | | | | | | | | | | | | Summary: It has been introduced in 2011 for gcc compat: https://github.com/llvm-mirror/clang/commit/ad1a4c6e89594e704775ddb6b036ac982fd68cad it is probably time to remove it Reviewers: rnk, dexonsmith Reviewed By: rnk Subscribers: dschuff, aheejin, fedor.sergeev, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64062 llvm-svn: 365962
* [SystemZ] Add support for new cpu architecture - arch13Ulrich Weigand2019-07-121-1/+16
| | | | | | | | | | | | | | | | | This patch series adds support for the next-generation arch13 CPU architecture to the SystemZ backend. This includes: - Basic support for the new processor and its features. - Support for low-level builtins mapped to new LLVM intrinsics. - New high-level intrinsics in vecintrin.h. - Indicate support by defining __VEC__ == 10303. Note: No currently available Z system supports the arch13 architecture. Once new systems become available, the official system name will be added as supported -march name. llvm-svn: 365933
* Fix has_attribute.cpp test on Windows after r364102Reid Kleckner2019-06-211-2/+2
| | | | llvm-svn: 364108
* Fix __has_cpp_attribute expansion to produce trailing L and (whereRichard Smith2019-06-211-85/+67
| | | | | | | | necessary) leading whitespace. Simplify unit test and extend to cover no_unique_address attribute. llvm-svn: 364102
* Fix tests after r363749Aaron Puchert2019-06-183-0/+8
| | | | | | | We changed -Wmissing-prototypes there, which was used in these tests via -Weverything. llvm-svn: 363754
* Clang :: Sema/wchar.c has long been failing on Solaris:Rainer Orth2019-06-171-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | error: 'error' diagnostics expected but not seen: File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 22: initializing wide char array with non-wide string literal error: 'error' diagnostics seen but not expected: File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 20: array initializer must be an initializer list File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 22: array initializer must be an initializer list It turns out the definition is wrong, as can be seen in GCC's gcc/config/sol2.h: /* wchar_t is called differently in <wchar.h> for 32 and 64-bit compilations. This is called for by SCD 2.4.1, p. 6-83, Figure 6-65 (32-bit) and p. 6P-10, Figure 6.38 (64-bit). */ #undef WCHAR_TYPE #define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") The following patch implements this, and at the same time corrects the wint_t definition which is the same: /* Same for wint_t. See SCD 2.4.1, p. 6-83, Figure 6-66 (32-bit). There's no corresponding 64-bit definition, but this is what Solaris 8 <iso/wchar_iso.h> uses. */ #undef WINT_TYPE #define WINT_TYPE (TARGET_64BIT ? "int" : "long int") Clang :: Preprocessor/wchar_t.c and Clang :: Sema/format-strings.c need to be adjusted to account for that. Tested on i386-pc-solaris2.11, x86_64-pc-solaris2.11, and x86_64-pc-linux-gnu. Differential Revision: https://reviews.llvm.org/D62944 llvm-svn: 363612
* [CUDA] Fix grep pattern in cuda-types.cuHubert Tong2019-06-101-20/+20
| | | | | | | | | | | | | | | | | | | | | | | Summary: vertical-line is not a BRE special character. POSIX.1-2017 XBD Section 9.3.2 indicates that the interpretation of `\|` is undefined. This patch uses EREs instead. Additionally, the pattern is further fixed so that `SIZEOF` and `WIDTH` macros are checked. Reviewers: jlebar, daltenty, xingxue, jasonliu, tra Reviewed By: tra Subscribers: jfb, jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63029 llvm-svn: 362991
* [ARM] Add ACLE feature macros for MVESjoerd Meijer2019-06-071-0/+21
| | | | | | | | | | | | | | | If MVE is present at all, then the macro __ARM_FEATURE_MVE is defined to a value which has bit 0 set for integer MVE, and bit 1 set for floating-point MVE. (Floating-point MVE implies integer MVE, so if this macro is defined at all then it will be set to 1 or 3, never 2.) Patch mostly by Simon Tatham Differential Revision: https://reviews.llvm.org/D60710 llvm-svn: 362806
* [ARM] Fix bugs introduced by the fp64/d32 rework.Simon Tatham2019-06-072-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
* [X86] -march=cooperlake (clang)Pengfei Wang2019-06-071-0/+99
| | | | | | | | | | Support intel -march=cooperlake in clang Patch by Shengchen Kan (skan) Differential Revision: https://reviews.llvm.org/D62835 llvm-svn: 362781
* [X86] Add ENQCMD instructionsPengfei Wang2019-06-061-0/+7
| | | | | | | | | | | | For more details about these instructions, please refer to the latest ISE document: https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference. Patch by Tianqing Wang (tianqing) Differential Revision: https://reviews.llvm.org/D62282 llvm-svn: 362685
* [X86] Add VP2INTERSECT instructionsPengfei Wang2019-05-311-0/+10
| | | | | | | | | | Support intel AVX512 VP2INTERSECT instructions in clang Patch by Xiang Zhang (xiangzhangllvm) Differential Revision: https://reviews.llvm.org/D62367 llvm-svn: 362196
* Fix the predefined exponent limit macros for the 16-bit IEEE format.John McCall2019-05-311-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The magnitude range of normalized _Float16 is 2^-14 (~6e-5) to (2-2^-10)*2^15 (65504). You might think, then, that the code is correct to defne FLT16_MIN_EXP and FLT16_MAX_EXP to be -14 and 15 respectively. However, for some reason the C specification actually specifies a bias for these macros: C11 5.2.4.2.2: - minimum negative integer such that FLT_RADIX raised to one less than that power is a normalized floating-point number, e_min: FLT_MIN_EXP DBL_MIN_EXP LDBL_MIN_EXP - maximum integer such that FLT_RADIX raised to one less than that power is a representable finite floating-point number, e_max: FLT_MAX_EXP DBL_MAX_EXP LDBL_MAX_EXP FLT16_MIN_EXP and FLT16_MAX_EXP should clearly be biased the same way, and other compilers do in fact do so, as do our OpenCL headers for `half`. Additionally, FLT16_MIN_10_EXP is just wrong. llvm-svn: 362183
* Make __has_builtin work with __builtin_LINE and friends.Eric Fiselier2019-05-291-0/+9
| | | | | | | | | | The source location builtins are implemented as keywords, but __has_builtin should still report true for them. This patch also fixes a test failure on systemz where the alignment of string literals is 2 not 1. llvm-svn: 361920
* [Preprocessor] Fix crash emitting note with framework location for "file not ↵Volodymyr Sapsai2019-05-272-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | found" error. A filename can be remapped with a header map to point to a framework header and we can find the corresponding framework without the header. But if the original filename doesn't have a remapped framework name, we'll fail to find its location and will dereference a null pointer during diagnostics emission. Fix by tracking remappings better and emit the note only if a framework is found before any of the remappings. rdar://problem/48883447 Reviewers: arphaman, erik.pilkington, jkorous Reviewed By: arphaman Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D61707 llvm-svn: 361779
* [WebAssembly] Add multivalue and tail-call target featuresThomas Lively2019-05-231-0/+22
| | | | | | | | | | | | | | | | Summary: These features will both be implemented soon, so I thought I would save time by adding the boilerplate for both of them at the same time. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62047 llvm-svn: 361516
* [ARM][CMSE] Add commandline option and feature macroJaved Absar2019-05-211-0/+20
| | | | | | | | | | | Defines macro ARM_FEATURE_CMSE to 1 for v8-M targets and introduces -mcmse option which for v8-M targets sets ARM_FEATURE_CMSE to 3. A diagnostic is produced when the option is given on architectures without support for Security Extensions. Reviewed By: dmgreen, snidertm Differential Revision: https://reviews.llvm.org/D59879 llvm-svn: 361261
* Reland "[Clang][PP] Add the __FILE_NAME__ builtin macro"Kristina Brooks2019-05-165-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | This relands commit rL360833 which caused issues on Win32 bots due to path handling/normalization differences. Now this uses `sys::path::filename` which should handle additional edge cases on Win32. Original commit: "[Clang][PP] Add the __FILE_NAME__ builtin macro" This patch adds the __FILE_NAME__ macro that expands to the last component of the path, similar to __FILE__ except with a guarantee that only the last path component (without the separator) will be rendered. I intend to follow through with discussion of this with WG14 as a potential inclusion in the C standard or failing that, try to discuss this with GCC developers since this extension is desired by GCC and Clang users/developers alike. Differential Revision: https://reviews.llvm.org/D61756 llvm-svn: 360938
* [X86] Stop implicitly enabling avx512vl when avx512bf16 is enabled.Craig Topper2019-05-161-2/+2
| | | | | | | | Previously we were doing this so that the 256 bit selectw builtin could be used in the implementation of the 512->256 bit conversion intrinsic. After this commit we now use a masked convert builtin that will emit the intrinsic call and the 256-bit select from custom code in CGBuiltin. Then the header only needs to call that one intrinsic. llvm-svn: 360924
* Add AIX Version MacrosXing Xue2019-05-161-0/+123
| | | | | | | | | | | | | | | | | | | | Summary: - This patch checks the AIX version and defines the appropriate macros. - Follow up to a comment on D59048. Author: andusy Reviewers: hubert.reinterpretcast, jasonliu, sfertile, xingxue Reviewed By: sfertile Subscribers: jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61530 llvm-svn: 360900
* Revert r360833 until I can work out the issue with Win32 botsKristina Brooks2019-05-165-53/+0
| | | | | | | | | This reverts "r360833: [Clang][PP] Add the __FILE_NAME__ builtin macro." The tests are failing on Windows bots, reverting the patchset until I can work out why. llvm-svn: 360842
* [Clang][PP] Add the __FILE_NAME__ builtin macro.Kristina Brooks2019-05-165-0/+53
| | | | | | | | | | | | | | | | This patch adds the `__FILE_NAME__` macro that expands to the last component of the path, similar to `__FILE__` except with a guarantee that only the last path component (without the separator) will be rendered. I intend to follow through with discussion of this with WG14 as a potential inclusion in the C standard or failing that, try to discuss this with GCC developers since this extension is desired by GCC and Clang users/developers alike. Differential Revision: https://reviews.llvm.org/D61756 llvm-svn: 360833
* Fixed tests where grep was not matching the linefeedAlexandre Ganea2019-05-104-6/+12
| | | | | | | | When files are synchronized locally as CRLF on Windows, grep didn't match the newline. Switched to FileCheck instead. Differential Revision: https://reviews.llvm.org/D61496 llvm-svn: 360467
* Replace lit feature keyword 'non-ms-sdk' with 'ms-sdk'; eliminatePaul Robinson2019-05-101-2/+2
| | | | | | 'non-ps4-sdk' and use just 'ps4'. llvm-svn: 360425
* Enable intrinsics of AVX512_BF16, which are supported for BFLOAT16 in Cooper ↵Luo, Yuanke2019-05-061-0/+15
| | | | | | | | | | | | | | | | | | | | | | | Lake Summary: 1. Enable infrastructure of AVX512_BF16, which is supported for BFLOAT16 in Cooper Lake; 2. Enable intrinsics for VCVTNE2PS2BF16, VCVTNEPS2BF16 and DPBF16PS instructions, which are Vector Neural Network Instructions supporting BFLOAT16 inputs and conversion instructions from IEEE single precision. For more details about BF16 intrinsic, please refer to the latest ISE document: https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference Patch by LiuTianle Reviewers: craig.topper, smaslov, LuoYuanke, wxiao3, annita.zhang, spatel, RKSimon Reviewed By: craig.topper Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60552 llvm-svn: 360018
* [c++20] Implement tweaked __VA_OPT__ rules from P1042R1:Richard Smith2019-05-042-4/+34
| | | | | | | | | | * __VA_OPT__ is expanded if the *expanded* __VA_ARGS__ is non-empty, not if the original argument contained no tokens. * Placemarkers at the start and end of __VA_OPT__ are retained just long enough to paste them with adjacent ## operators. We never paste "across" a discarded placemarker. llvm-svn: 359964
* [WebAssembly] Use the "wasm32-wasi" triple in testsDan Gohman2019-04-301-2/+2
| | | | | | | | | | | Similar to https://reviews.llvm.org/D61334, update clang tests to use the "wasm32-wasi" triple, removing the "-musl" environment and omitting the "-unknown" vendor. Differential Revision: https://reviews.llvm.org/D61338 Reviewer: sbc100 llvm-svn: 359630
* [AArch64] Add support for MTE intrinsicsJaved Absar2019-04-261-0/+3
| | | | | | | | | | | | This provides intrinsics support for Memory Tagging Extension (MTE), which was introduced with the Armv8.5-a architecture. These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined. Each intrinsic is described in detail in the ACLE Q1 2019 documentation: https://developer.arm.com/docs/101028/latest Reviewed By: Tim Nortover, David Spickett Differential Revision: https://reviews.llvm.org/D60485 llvm-svn: 359348
* [BPF] do not generate predefined macro bpfYonghong Song2019-04-261-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | "DefineStd(Builder, "bpf", Opts)" generates the following three macros: bpf __bpf __bpf__ and the macro "bpf" is due to the fact that the target language is C which allows GNU extensions. The name "bpf" could be easily used as variable name or type field name. For example, in current linux kernel, there are four places where bpf is used as a field name. If the corresponding types are included in bpf program, the compilation error will occur. This patch removed predefined macro "bpf" as well as "__bpf" which is rarely used if used at all. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D61173 llvm-svn: 359310
OpenPOWER on IntegriCloud