summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic
Commit message (Collapse)AuthorAgeFilesLines
* [ItaniumMangle] Refactor long double/__float128 mangling and fix the mangled ↵Fangrui Song2019-07-093-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | code In gcc PowerPC, long double has 3 mangling schemes: -mlong-double-64: `e` -mlong-double-128 -mabi=ibmlongdouble: `g` -mlong-double-128 -mabi=ieeelongdouble: `u9__ieee128` (gcc <= 8.1: `U10__float128`) The current useFloat128ManglingForLongDouble() bisection is not suitable when we support -mlong-double-128 in clang (D64277). Replace useFloat128ManglingForLongDouble() with getLongDoubleMangling() and getFloat128Mangling() to allow 3 mangling schemes. I also deleted the `getTriple().isOSBinFormatELF()` check (the Darwin support has gone: https://reviews.llvm.org/D50988). For x86, change the mangled code of __float128 from `U10__float128` to `g`. `U10__float128` was wrongly copied from PowerPC. The test will be added to `test/CodeGen/x86-long-double.cpp` in D64277. Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D64276 llvm-svn: 365480
* [X86][PPC] Support -mlong-double-64Fangrui Song2019-07-092-20/+13
| | | | | | | | | | | | | | | | | | | | | | | | -mlong-double-64 is supported on some ports of gcc (i386, x86_64, and ppc{32,64}). On many other targets, there will be an error: error: unrecognized command line option '-mlong-double-64' This patch makes the driver option -mlong-double-64 available for x86 and ppc. The CC1 option -mlong-double-64 is available on all targets for users to test on unsupported targets. LongDoubleSize is added as a VALUE_LANGOPT so that the option can be shared with -mlong-double-128 when we support it in clang. Also, make powerpc*-linux-musl default to use 64-bit long double. It is currently the only supported ABI on musl and is also how people configure powerpc*-linux-musl-gcc. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D64067 llvm-svn: 365412
* [RISCV] Specify registers used for exception handlingAlex Bradbury2019-07-081-0/+9
| | | | | | | | | Implements the handling of __builtin_eh_return_regno(). Differential Revision: https://reviews.llvm.org/D63417 Patch by Edward Jones. llvm-svn: 365305
* [PowerPC] Support constraint code "ww"Fangrui Song2019-07-041-1/+2
| | | | | | | | | | | | | Summary: "ww" and "ws" are both constraint codes for VSX vector registers that hold scalar double data. "ww" is preferred for float while "ws" is preferred for double. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D64119 llvm-svn: 365106
* Fix MSVC "signed/unsigned mismatch" warning. NFCI.Simon Pilgrim2019-07-031-1/+2
| | | | | | Fixes PR42426. llvm-svn: 365019
* Change std::{lower,upper}_bound to llvm::{lower,upper}_bound or ↵Fangrui Song2019-07-033-12/+8
| | | | | | llvm::partition_point. NFC llvm-svn: 365006
* Fix build failure due to missing breakYaxun Liu2019-06-261-0/+2
| | | | llvm-svn: 364380
* [ARM] Support inline assembler constraints for MVE.Simon Tatham2019-06-251-0/+11
| | | | | | | | | | | | | | | | | | | | | "To" selects an odd-numbered GPR, and "Te" an even one. There are some 8.1-M instructions that have one too few bits in their register fields and require registers of particular parity, without necessarily using a consecutive even/odd pair. Also, the constraint letter "t" should select an MVE q-register, when MVE is present. This didn't need any source changes, but some extra tests have been added. Reviewers: dmgreen, samparker, SjoerdMeijer Subscribers: javed.absar, eraman, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60709 llvm-svn: 364331
* AMDGPU: Fix target builtins for gfx10Matt Arsenault2019-06-221-0/+2
| | | | | | This wasn't setting some of the features from older generations. llvm-svn: 364123
* PR42301: Abort cleanly if we encounter a huge source file rather thanRichard Smith2019-06-211-0/+25
| | | | | | | | | | crashing. Ideally we wouldn't care about the size of a file so long as it fits in memory, but in practice we have lots of hardocded assumptions that unsigned can be used to index files, string literals, and so on. llvm-svn: 364103
* [RISCV] Mark TLS as supportedLewis Revill2019-06-191-1/+0
| | | | | | | | Inform Clang that TLS is implemented by LLVM for RISC-V Differential Revision: https://reviews.llvm.org/D57055 llvm-svn: 363776
* Clang :: Sema/wchar.c has long been failing on Solaris:Rainer Orth2019-06-171-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Targets] Move soft-float-abi filtering to `initFeatureMap`George Burgess IV2019-06-142-14/+25
| | | | | | | | | | | | | | | | | | ARM has a special target feature called soft-float-abi. This feature is special, since we get it passed to us explicitly in the frontend, but filter it out before it can land in any target feature strings in LLVM IR. __attribute__((target(""))) doesn't quite filter these features out properly, so today, we get warnings about soft-float-abi being an unknown feature from the backend. This CL has us filter soft-float-abi out at a slightly different point, so we don't end up passing these invalid features to the backend. Differential Revision: https://reviews.llvm.org/D61750 llvm-svn: 363346
* [AMDGPU] gfx1011/gfx1012 clang supportStanislav Mekhanoshin2019-06-141-0/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D63308 llvm-svn: 363345
* [RISCV] Add inline asm constraints I, J & K for RISC-VLewis Revill2019-06-112-3/+21
| | | | | | | | | | | | | | | | This allows the constraints I, J & K to be used in inline asm for RISC-V, with the following semantics (equivalent to GCC): I: Any 12-bit signed immediate. J: Integer zero only. K: Any 5-bit unsigned immediate. See the GCC definitions here: https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html Differential Revision: https://reviews.llvm.org/D54091 llvm-svn: 363055
* [X86] Attempt to make the Intel core CPU inheritance a little more readable ↵Craig Topper2019-06-101-24/+27
| | | | | | | | | | | | and maintainable The recently added cooperlake CPU has made our already ugly switch statement even worse. There's a CPU exclusion list around the bf16 feature in the cooper lake block. I worry that we'll have to keep adding new CPUs to that until bf16 intercepts a client space CPU. We have several other exclusion lists in other parts of the switch due to skylakeserver, cascadelake, and cooperlake not having sgx. Another for cannonlake not having clwb but having all other features from skx. This removes all these special ifs at the cost of some duplication of features and a goto. I've copied all of the skx features into either cannonlake or icelakeclient(for clwb). And pulled sklyakeserver, cascadelake, and cooperlake out of the main inheritance chain into their own chain. At the end of skylakeserver we merge back into the main chain at skylakeclient but below sgx. I think this is at least easier to follow. Differential Revision: https://reviews.llvm.org/D63018 llvm-svn: 362965
* [ARM] Add ACLE feature macros for MVE.David Green2019-06-071-0/+1
| | | | | | Fixup uninitialised variable. llvm-svn: 362814
* [ARM] Add ACLE feature macros for MVESjoerd Meijer2019-06-072-0/+30
| | | | | | | | | | | | | | | 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-071-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+11
| | | | | | | | | | 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-062-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-312-1/+8
| | | | | | | | | | Support intel AVX512 VP2INTERSECT instructions in clang Patch by Xiang Zhang (xiangzhangllvm) Differential Revision: https://reviews.llvm.org/D62367 llvm-svn: 362196
* [ARM] Add CLI support for Armv8.1-M and MVESjoerd Meijer2019-05-301-0/+2
| | | | | | | | | | | | Given the existing infrastructure in LLVM side for +fp and +fp.dp, this is more or less trivial, needing only one tiny source change and a couple of tests. Patch by Simon Tatham. Differential Revision: https://reviews.llvm.org/D60699 llvm-svn: 362096
* [ARM] Replace fp-only-sp and d16 with fp64 and d32.Simon Tatham2019-05-281-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those two subtarget features were awkward because their semantics are reversed: each one indicates the _lack_ of support for something in the architecture, rather than the presence. As a consequence, you don't get the behavior you want if you combine two sets of feature bits. Each SubtargetFeature for an FP architecture version now comes in four versions, one for each combination of those options. So you can still say (for example) '+vfp2' in a feature string and it will mean what it's always meant, but there's a new string '+vfp2d16sp' meaning the version without those extra options. A lot of this change is just mechanically replacing positive checks for the old features with negative checks for the new ones. But one more interesting change is that I've rearranged getFPUFeatures() so that the main FPU feature is appended to the output list *before* rather than after the features derived from the Restriction field, so that -fp64 and -d32 can override defaults added by the main feature. Reviewers: dmgreen, samparker, SjoerdMeijer Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60691 llvm-svn: 361845
* [X86] Split multi-line chained assignments into single lines to avoid making ↵Craig Topper2019-05-231-26/+24
| | | | | | | | clang-format create triangle shaped indentation. Simplify one if statement to remove a bunch of string matches. NFCI We had an if statement that checked over every avx512* feature to see if it should enabled avx512f. Since they are all prefixed with avx512 just check for that instead. llvm-svn: 361557
* [WebAssembly] Add multivalue and tail-call target featuresThomas Lively2019-05-232-0/+28
| | | | | | | | | | | | | | | | 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
* [OpenCL] Support pipe keyword in C++ modeSven van Haastregt2019-05-221-2/+3
| | | | | | | | | | | | Support the OpenCL C pipe feature in C++ for OpenCL mode, to preserve backwards compatibility with OpenCL C. Various changes had to be made in Parse and Sema to enable pipe-specific diagnostics, so enable a SemaOpenCL test for C++. Differential Revision: https://reviews.llvm.org/D62181 llvm-svn: 361382
* [PPC64] Fix PPC64TargetInfo ABI on clang side after D61950Fangrui Song2019-05-221-1/+2
| | | | llvm-svn: 361365
* [PPC64] Fix PPC64TargetInfo after D61950Fangrui Song2019-05-221-0/+1
| | | | llvm-svn: 361363
* [PPC64] Parse -elfv1 -elfv2 when specified on target tripleFangrui Song2019-05-221-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: For big-endian powerpc64, the default ABI is ELFv1. OpenPower ABI ELFv2 is supported when -mabi=elfv2 is specified. FreeBSD support for PowerPC64 ELFv2 ABI with LLVM is in progress[1]. This patch adds an alternative way to specify ELFv2 ABI on target triple [2]. The following results are expected: ELFv1 when using: -target powerpc64-unknown-freebsd12.0 -target powerpc64-unknown-freebsd12.0 -mabi=elfv1 -target powerpc64-unknown-freebsd12.0-elfv1 ELFv2 when using: -target powerpc64-unknown-freebsd12.0 -mabi=elfv2 -target powerpc64-unknown-freebsd12.0-elfv2 [1] https://wiki.freebsd.org/powerpc/llvm-elfv2 [2] https://clang.llvm.org/docs/CrossCompilation.html Patch by Alfredo Dal'Ava Júnior! Differential Revision: https://reviews.llvm.org/D61950 llvm-svn: 361355
* [DebugInfo] Don't emit checksums when compiling a preprocessed CPPAlexandre Ganea2019-05-211-2/+7
| | | | | | | | Fixes PR41215 Differential Revision: https://reviews.llvm.org/D60283 llvm-svn: 361296
* [ARM][CMSE] Add commandline option and feature macroJaved Absar2019-05-211-0/+9
| | | | | | | | | | | 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
* [X86] Stop implicitly enabling avx512vl when avx512bf16 is enabled.Craig Topper2019-05-161-3/+1
| | | | | | | | 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-1/+17
| | | | | | | | | | | | | | | | | | | | 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
* [AMDGPU] gfx1010 clang targetStanislav Mekhanoshin2019-05-132-1/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D61875 llvm-svn: 360634
* [Preamble] Stop circular inclusion of main file when building preambleNikolai Kosjar2019-05-101-1/+1
| | | | | | | | | | | | | | | If a header file was processed for the second time, we could end up with a wrong conditional stack and skipped ranges: In the particular example, if the header guard is evaluated the second time and it is decided to skip the conditional block, the corresponding "#endif" is never seen since the preamble does not include it and we end up in the Tok.is(tok::eof) case with a wrong conditional stack. Detect the circular inclusion, emit a diagnostic and stop processing the inclusion. llvm-svn: 360418
* Assume `__cxa_allocate_exception` returns an under-aligned memory onAkira Hatanaka2019-05-101-0/+31
| | | | | | | | | | | | | | | | | | | | | Darwin if the version of libc++abi isn't new enough to include the fix in r319123 This patch resurrects r264998, which was committed to work around a bug in libc++abi that was causing _cxa_allocate_exception to return a memory that wasn't double-word aligned. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160328/154332.html In addition, this patch makes clang issue a warning if the type of the thrown object requires an alignment that is larger than the minimum guaranteed by the target C++ runtime. rdar://problem/49864414 Differential Revision: https://reviews.llvm.org/D61667 llvm-svn: 360404
* [clang] Fix a bug that reports UTF32 (LE) files as UTF16 (LE) onesOwen Pan2019-05-081-3/+3
| | | | | | | | Also fix a typo for the SCSU byte order mark. Differential Revision: https://reviews.llvm.org/D61628 llvm-svn: 360256
* -frewrite-imports: Add support for wildcard rules in umbrella modules withDavid Blaikie2019-05-071-0/+15
| | | | | | | | | | This trips over a few other limitations, but in the interests of incremental development I'm starting here & I'll look at the issues with -verify and filesystem checks (the fact that the behavior depends on the existence of a 'foo' directory even though it shouldn't need it), etc. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D61656 llvm-svn: 360195
* Fix typo in risc-v register aliases.Eric Christopher2019-05-071-1/+1
| | | | | | | | Patch by John. Differential Revision: https://reviews.llvm.org/D61464 llvm-svn: 360104
* Enable intrinsics of AVX512_BF16, which are supported for BFLOAT16 in Cooper ↵Luo, Yuanke2019-05-062-0/+14
| | | | | | | | | | | | | | | | | | | | | | | 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
* [COFF, ARM64] Align global symbol by size for ARM64 MSVC ABITom Tan2019-05-023-1/+20
| | | | | | | | | | | | | | | | | According to alignment section in below ARM64 ABI document, MSVC could increase alignment of global data based on its total size. Clang doesn't do this. Compile the same symbol into different alignments by Clang and MSVC could cause link error because some instruction encodings, like 64-bit LDR/STR with immediate, require the target to be 8 bytes aligned, and linker could choose code stream with such LDR/STR instruction from MSVC and 4 bytes aligned data from Clang into final image, which actually cannot be linked together (see https://bugs.llvm.org/show_bug.cgi?id=41506 for more details). https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#alignment Differential Revision: https://reviews.llvm.org/D61225 llvm-svn: 359744
* AMDGPU: Enable _Float16Yaxun Liu2019-04-301-0/+3
| | | | llvm-svn: 359594
* [AArch64] Initialize HasMTEVitaly Buka2019-04-271-0/+1
| | | | llvm-svn: 359366
* [AArch64] Add support for MTE intrinsicsJaved Absar2019-04-262-0/+6
| | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | "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
* [CUDA] Implemented _[bi]mma* builtins.Artem Belevich2019-04-251-0/+2
| | | | | | | | | | | | | | | | These builtins provide access to the new integer and sub-integer variants of MMA (matrix multiply-accumulate) instructions provided by CUDA-10.x on sm_75 (AKA Turing) GPUs. Also added a feature for PTX 6.4. While Clang/LLVM does not generate any PTX instructions that need it, we still need to pass it through to ptxas in order to be able to compile code that uses the new 'mma' instruction as inline assembly (e.g used by NVIDIA's CUTLASS library https://github.com/NVIDIA/cutlass/blob/master/cutlass/arch/mma.h#L101) Differential Revision: https://reviews.llvm.org/D60279 llvm-svn: 359248
* [Builtins] Implement __builtin_is_constant_evaluated for use in C++2aEric Fiselier2019-04-241-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is built on the back of Bill Wendling's work for `__builtin_constant_p()`. More tests to come, but early feedback is appreciated. I plan to implement warnings for common mis-usages like those belowe in a following patch: ``` void foo(int x) { if constexpr (std::is_constant_evaluated())) { // condition is always `true`. Should use plain `if` instead. foo_constexpr(x); } else { foo_runtime(x); } } ``` Reviewers: rsmith, MaskRay, bruno, void Reviewed By: rsmith Subscribers: dexonsmith, zoecarver, fdeazeve, kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D55500 llvm-svn: 359067
* [FileSystemStatCache] Return std::error_code from stat cache methodsHarlan Haskins2019-04-162-23/+25
| | | | | | | | | | | | | | | | | | | | | | Summary: Previously, we would return true/false signifying if the cache/lookup succeeded or failed. Instead, provide clients with the underlying error that was thrown while attempting to look up in the cache. Since clang::FileManager doesn't make use of this information, it discards the error that's received and casts away to bool. This change is NFC. Reviewers: benlangmuir, arphaman Subscribers: dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60735 llvm-svn: 358509
* [C++20] Implement context-sensitive header-name lexing and pp-import parsing ↵Richard Smith2019-04-111-1/+1
| | | | | | in the preprocessor. llvm-svn: 358231
OpenPOWER on IntegriCloud