summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic
Commit message (Collapse)AuthorAgeFilesLines
* [OPENMP] Add reverse_offload clause to requires directivePatrick Lyster2018-10-031-0/+2
| | | | llvm-svn: 343711
* Add support for unified_shared_memory clause on requires directivePatrick Lyster2018-10-011-0/+2
| | | | llvm-svn: 343472
* Use the container form llvm::sort(C, ...)Fangrui Song2018-09-301-1/+1
| | | | | | | | | There are a few leftovers of rC343147 that are not (\w+)\.begin but in the form of ([-[:alnum:]>.]+)\.begin or spanning two lines. Change them to use the container form in this commit. The 12 occurrences have been inspected manually for safety. llvm-svn: 343425
* [X86] Add the movbe instruction intrinsics from icc.Craig Topper2018-09-281-0/+3
| | | | | | | | | | 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-1/+1
| | | | | | | | | 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
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-261-2/+1
| | | | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: rsmith, #clang, dblaikie Reviewed By: rsmith, #clang Subscribers: mgrang, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52576 llvm-svn: 343147
* [ARM/AArch64][v8.5A] Add Armv8.5-A targetOliver Stannard2018-09-261-0/+2
| | | | | | | | | | | 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
* [OPENMP] Add support for OMP5 requires directive + unified_address clauseKelvin Li2018-09-261-0/+13
| | | | | | | | | Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
* [CUDA] Added basic support for compiling with CUDA-10.0Artem Belevich2018-09-242-0/+14
| | | | llvm-svn: 342924
* [VFS] Use llvm::StringMap instead of std::map. NFCEric Liu2018-09-241-1/+1
| | | | llvm-svn: 342889
* [AST] Various optimizations + refactoring in DeclarationName(Table)Bruno Ricci2018-09-211-15/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce the following optimizations in DeclarationName(Table): 1. Store common kinds inline in DeclarationName instead of DeclarationNameExtra. Currently the kind of C++ constructor, destructor, conversion function and overloaded operator names is stored in DeclarationNameExtra. Instead store it inline in DeclarationName. To do this align IdentifierInfo, CXXSpecialName, DeclarationNameExtra and CXXOperatorIdName to 8 bytes so that we can use the lower 3 bits of DeclarationName::Ptr. This is already the case on 64 bits archs anyway. This also allow us to remove DeclarationNameExtra from CXXSpecialName and CXXOperatorIdName, which shave off a pointer from CXXSpecialName. 2. Synchronize the enumerations DeclarationName::NameKind, DeclarationName::StoredNameKind and Selector::IdentifierInfoFlag. This makes DeclarationName::getNameKind much more efficient since we can replace the switch table by a single comparison and an addition. 3. Put the overloaded operator names inline in DeclarationNameTable to remove an indirection. This increase the size of DeclarationNameTable a little bit but this is not important since it is only used in ASTContext, and never copied nor moved from. This also get rid of the last dynamic allocation in DeclarationNameTable. Altogether these optimizations cut the run time of parsing all of Boost by about 0.8%. While we are at it, do the following NFC modifications: 1. Put the internal classes CXXSpecialName, CXXDeductionGuideNameExtra, CXXOperatorIdName, CXXLiteralOperatorIdName and DeclarationNameExtra in a namespace detail since these classes are only meant to be used by DeclarationName and DeclarationNameTable. Make this more explicit by making the members of these classes private and friending DeclarationName(Table). 2. Make DeclarationName::getFETokenInfo a non-template since every users are using it to get a void *. It was supposed to be used with a type to avoid a subsequent static_cast. 3. Change the internal functions DeclarationName::getAs* to castAs* since when we use them we already know the correct kind. This has no external impact since all of these are private. Reviewed By: erichkeane, rjmccall Differential Revision: https://reviews.llvm.org/D52267 llvm-svn: 342729
* Basic: correct `__WINT_TYPE__` on WindowsSaleem Abdulrasool2018-09-191-0/+1
| | | | | | | | | 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
* [Modules] Add platform and environment features to requires clauseBruno Cardoso Lopes2018-09-181-1/+33
| | | | | | | | | | | | | Allows module map writers to add build requirements based on platform/os. This helps when target features and language dialects aren't enough to conditionalize building a module, among other things, it allow module maps for different platforms to live in the same file. rdar://problem/43909745 Differential Revision: https://reviews.llvm.org/D51910 llvm-svn: 342499
* [VFS] vfs::directory_iterator yields path and file type instead of full StatusSam McCall2018-09-141-44/+37
| | | | | | | | | | | | | | | | | | | | | | | Summary: Most callers I can find are using only `getName()`. Type is used by the recursive iterator. Now we don't have to call stat() on every listed file (on most platforms). Exceptions are e.g. Solaris where readdir() doesn't include type information. On those platforms we'll still stat() - see D51918. The result is significantly faster (stat() can be slow). My motivation: this may allow us to improve clang IO on large TUs with long include search paths. Caching readdir() results may allow us to skip many stat() and open() operations on nonexistent files. Reviewers: bkramer Subscribers: fedor.sergeev, cfe-commits Differential Revision: https://reviews.llvm.org/D51921 llvm-svn: 342232
* When we leave a module header, make that header visible in itsRichard Smith2018-09-121-6/+5
| | | | | | includer's context, even if its overall module is unavailable. llvm-svn: 342096
* Move AESNI generation to Skylake and GoldmontErich Keane2018-09-101-2/+2
| | | | | | | | | | | | | | | | | | | The instruction set first appeared with Westmere, but not all processors in that and the next few generations have the instructions. According to Wikipedia[1], the first generation in which all SKUs have AES instructions are Skylake and Goldmont. I can't find any Skylake, Kabylake, Kabylake-R or Cannon Lake currently listed at https://ark.intel.com that says "Intel® AES New Instructions" "No". This matches GCC commit https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01940.html [1] https://en.wikipedia.org/wiki/AES_instruction_set Patch By: thiagomacieira Differential Revision: https://reviews.llvm.org/D51510 llvm-svn: 341862
* [VFS] Cache the current working directory for the real FS.Eric Liu2018-09-051-2/+16
| | | | | | | | | | Reviewers: sammccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51641 llvm-svn: 341455
* Adding HardLink Support to VirtualFileSystem.Ilya Biryukov2018-09-041-49/+119
| | | | | | | | | | | | | | | | | | | | | | | Summary: Added support of creating a hardlink from one file to another file. After a hardlink is added between two files, both file will have the same: 1. UniqueID (inode) 2. Size 3. Buffer This will bring replay of compilation closer to the actual compilation. There are instances where clang checks for the UniqueID of the file/header to be loaded which leads to a different behavior during replay as all files have different UniqueIDs. Patch by Utkarsh Saxena! Reviewers: ilya-biryukov Reviewed By: ilya-biryukov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51359 llvm-svn: 341366
* Add dump() method for SourceRangeStephen Kelly2018-08-301-0/+54
| | | | | | | | Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50662 llvm-svn: 341140
* [ARM] Set __ARM_FEATURE_SIMD32 for +dsp coresSam Parker2018-08-291-1/+1
| | | | | | | | | | | | | | 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
* Revert r323281 "Adjust MaxAtomicInlineWidth for i386/i486 targets."Hans Wennborg2018-08-241-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | As reported on http://lists.llvm.org/pipermail/cfe-dev/2018-August/058760.html, this broke i386-freebsd11 due to its lack of atomic 64 bit primitives. While that's not really this commit's fault, let's revert back to the old behaviour until this can be fixed. This means generating cmpxchg8b etc for i386 and i486 which don't technically support those, but that's been the behaviour for a long time, so a little longer probably doesn't hurt that much. > Adjust MaxAtomicInlineWidth for i386/i486 targets. > > This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6. > Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, > i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg. > So in this patch MaxAtomicInlineWidth is reset as follows: > For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. > For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. > For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. > > Differential Revision: https://reviews.llvm.org/D42154 llvm-svn: 340666
* Fix build bot after r340598.Eric Liu2018-08-241-8/+12
| | | | | | | Revert to the original behavior: only calculate real file path when file is opened and avoid using InterndPath for real path calculation. llvm-svn: 340602
* [FileManager] Do not call 'real_path' in getFile().Eric Liu2018-08-241-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This partially rolls back the change in D48903: https://github.com/llvm-mirror/clang/commit/89aa7f45a1f728144935289d4ce69d8522999de0#diff-0025af005307891b5429b6a834823d5eR318 `real_path` can be very expensive on real file systems, and calling it on each opened file can slow down the compilation. This also slows down deserialized ASTs for which real paths need to be recalculated for each input files again. For clangd code completion latency (using preamble): Before {F7039629} After {F7039630} Reviewers: ilya-biryukov, simark Reviewed By: ilya-biryukov Subscribers: kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D51159 llvm-svn: 340598
* [x86/retpoline] Split the LLVM concept of retpolines into separateChandler Carruth2018-08-232-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | subtarget features for indirect calls and indirect branches. This is in preparation for enabling *only* the call retpolines when using speculative load hardening. I've continued to use subtarget features for now as they continue to seem the best fit given the lack of other retpoline like constructs so far. The LLVM side is pretty simple. I'd like to eventually get rid of the old feature, but not sure what backwards compatibility issues that will cause. This does remove the "implies" from requesting an external thunk. This always seemed somewhat questionable and is now clearly not desirable -- you specify a thunk the same way no matter which set of things are getting retpolines. I really want to keep this nicely isolated from end users and just an LLVM implementation detail, so I've moved the `-mretpoline` flag in Clang to no longer rely on a specific subtarget feature by that name and instead to be directly handled. In some ways this is simpler, but in order to preserve existing behavior I've had to add some fallback code so that users who relied on merely passing -mretpoline-external-thunk continue to get the same behavior. We should eventually remove this I suspect (we have never tested that it works!) but I've not done that in this patch. Differential Revision: https://reviews.llvm.org/D51150 llvm-svn: 340515
* [clang][mips] Set __mips_fpr correctly for -mfpxxStefan Maksimovic2018-08-222-16/+63
| | | | | | | | | | | | | | | | | | | | 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
* AMDGPU: Move target code into TargetParserMatt Arsenault2018-08-212-193/+77
| | | | llvm-svn: 340292
* AMDGPU: Correct errors in device tableMatt Arsenault2018-08-161-2/+2
| | | | llvm-svn: 339934
* Add a newline to SourceLocation dump outputStephen Kelly2018-08-152-3/+4
| | | | | | | | | | | | | | Summary: Migrate callers to print(). dump() should be useful to downstreams and third parties as a debugging aid. Everyone trips up on this and creates confusing output. Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50661 llvm-svn: 339810
* AMDGPU: Fix enabling denormals by default on pre-VI targetsMatt Arsenault2018-08-082-66/+68
| | | | | | | | Fast FMAF is not a sufficient condition to enable denormals. Before VI, enabling denormals caused F32 instructions to run at F64 speeds. llvm-svn: 339278
* [NFC][VFS] Fix typos in comments.Volodymyr Sapsai2018-08-081-2/+2
| | | | llvm-svn: 339215
* [VFS] Unify iteration code for VFSFromYamlDirIterImpl, NFC intended.Volodymyr Sapsai2018-08-071-19/+10
| | | | | | | | | | | | | | First and subsequent iteration steps are similar, capture this similarity. Reviewers: bruno, benlangmuir Reviewed By: bruno Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50118 llvm-svn: 339199
* [VFS] Emit an error when entry at root level uses a relative path.Volodymyr Sapsai2018-08-071-3/+15
| | | | | | | | | | | | | | | | | | | | | Entries with only a filename prevent us from building a file system tree and cause the assertion > Assertion failed: (NewParentE && "Parent entry must exist"), function uniqueOverlayTree, file clang/lib/Basic/VirtualFileSystem.cpp, line 1303. Entries with a relative path are simply not discoverable during header search. rdar://problem/28990865 Reviewers: bruno, benlangmuir Reviewed By: bruno Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D49518 llvm-svn: 339164
* AMDGPU: Add builtin for s_dcache_wbMatt Arsenault2018-08-071-0/+1
| | | | llvm-svn: 339110
* AMDGPU: Add builtin for s_dcache_inv_volMatt Arsenault2018-08-071-1/+3
| | | | llvm-svn: 339109
* [VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi2018-08-062-17/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | requested name Summary: InMemoryFileSystem::status behaves differently than RealFileSystem::status. The Name contained in the Status returned by RealFileSystem::status will be the path as requested by the caller, whereas InMemoryFileSystem::status returns the normalized path. For example, when requested the status for "../src/first.h", RealFileSystem returns a Status with "../src/first.h" as the Name. InMemoryFileSystem returns "/absolute/path/to/src/first.h". The reason for this change is that I want to make a unit test in the clangd testsuite (where we use an InMemoryFileSystem) to reproduce a bug I get with the clangd program (where a RealFileSystem is used). This difference in behavior "hides" the bug in the unit test version. An indirect impact of this change is that a -Wnonportable-include-path warning is now emitted in test PCH/case-insensitive-include.c. This is because the real path of the included file (with the wrong case) was not available previously, whereas it is now. Reviewers: malaperle, ilya-biryukov, bkramer Reviewed By: ilya-biryukov Subscribers: eric_niebler, malaperle, omtcyfz, hokein, bkramer, ilya-biryukov, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D48903 llvm-svn: 339063
* Fix for broken build on clang-hexagon-elf for ambiguous call toLeonard Chan2018-08-061-1/+2
| | | | | | std::abs. llvm-svn: 339044
* [Fixed Point Arithmetic] Remove unused include.Benjamin Kramer2018-08-061-1/+0
| | | | | | lib/Basic cannot depend on lib/AST. llvm-svn: 339031
* [Fixed Point Arithmetic] Fixed Point ConstantLeonard Chan2018-08-062-0/+116
| | | | | | | | | | This patch proposes an abstract type that represents fixed point numbers, similar to APInt or APSInt that was discussed in https://reviews.llvm.org/D48456#inline-425585. This type holds a value, scale, and saturation and is meant to perform intermediate calculations on constant fixed point values. Currently this class is used as a way for handling the conversions between fixed point numbers with different sizes and radixes. For example, if I'm casting from a signed _Accum to a saturated unsigned short _Accum, I will need to check the value of the signed _Accum to see if it fits into the short _Accum which involves getting and comparing against the max/min values of the short _Accum. The FixedPointNumber class currently handles the radix shifting and extension when converting to a signed _Accum. Differential Revision: https://reviews.llvm.org/D48661 llvm-svn: 339028
* Try to make builtin address space declarations not uselessMatt Arsenault2018-08-021-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way address space declarations for builtins currently work is nearly useless. The code assumes the address spaces used for builtins is a confusingly named "target address space" from user code using __attribute__((address_space(N))) that matches the builtin declaration. There's no way to use this to declare a builtin that returns a language specific address space. The terminology used is highly cofusing since it has nothing to do with the the address space selected by the target to use for a language address space. This feature is essentially unused as-is. AMDGPU and NVPTX are the only in-tree targets attempting to use this. The AMDGPU builtins certainly do not behave as intended (i.e. all of the builtins returning pointers can never compile because the numbered address space never matches the expected named address space). The NVPTX builtins are missing tests for some, and the others seem to rely on an implicit addrspacecast. Change the used address space for builtins based on a target hook to allow using a language address space for a builtin. This allows the same builtin declaration to be used for multiple languages with similarly purposed address spaces (e.g. the same AMDGPU builtin can be used in OpenCL and CUDA even though the constant address spaces are arbitarily different). This breaks the possibility of using arbitrary numbered address spaces alongside the named address spaces for builtins. If this is an issue we probably need to introduce another builtin declaration character to distinguish language address spaces from so-called "target address spaces". llvm-svn: 338707
* [Android] Increase default new alignment for AndroidPirama Arumuga Nainar2018-08-011-2/+3
| | | | | | | | | | | | | | 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
* [AArch64][ARM] Add Armv8.4-A testsSjoerd Meijer2018-08-011-0/+4
| | | | | | | | | This adds tests for Armv8.4-A, and also some v8.2 and v8.3 tests that were missing. Differential Revision: https://reviews.llvm.org/D50068 llvm-svn: 338525
* Remove trailing spaceFangrui Song2018-07-3012-91/+91
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* Revert r338057 "[VirtualFileSystem] InMemoryFileSystem::status: Return a ↵Reid Kleckner2018-07-262-56/+17
| | | | | | | | Status with the requested name" This broke clang/test/PCH/case-insensitive-include.c on Windows. llvm-svn: 338084
* [ARM64] [Windows] Follow MS X86_64 C++ ABI when passing structsSanjin Sijaric2018-07-263-1/+8
| | | | | | | | | | | | | | | | | Summary: Microsoft's C++ object model for ARM64 is the same as that for X86_64. For example, small structs with non-trivial copy constructors or virtual function tables are passed indirectly. Currently, they are passed in registers when compiled with clang. Reviewers: rnk, mstorsjo, TomTan, haripul, javed.absar Reviewed By: rnk, mstorsjo Subscribers: kristof.beyls, chrib, llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D49770 llvm-svn: 338076
* [VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi2018-07-262-17/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | requested name Summary: InMemoryFileSystem::status behaves differently than RealFileSystem::status. The Name contained in the Status returned by RealFileSystem::status will be the path as requested by the caller, whereas InMemoryFileSystem::status returns the normalized path. For example, when requested the status for "../src/first.h", RealFileSystem returns a Status with "../src/first.h" as the Name. InMemoryFileSystem returns "/absolute/path/to/src/first.h". The reason for this change is that I want to make a unit test in the clangd testsuite (where we use an InMemoryFileSystem) to reproduce a bug I get with the clangd program (where a RealFileSystem is used). This difference in behavior "hides" the bug in the unit test version. Reviewers: malaperle, ilya-biryukov, bkramer Subscribers: cfe-commits, ioeric, ilya-biryukov, bkramer, hokein, omtcyfz Differential Revision: https://reviews.llvm.org/D48903 llvm-svn: 338057
* Revert "[VFS] Cleanups to VFS interfaces."Jordan Rupprecht2018-07-242-20/+19
| | | | | | This reverts commit r337834 due to test failures. llvm-svn: 337850
* [VFS] Cleanups to VFS interfaces.Sam McCall2018-07-242-19/+20
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: - add comments clarifying semantics - Status::copyWithNewName(Status, Name) --> instance method - Status::copyWithNewName(fs::file_status, Name) --> constructor (it's not a copy) - File::getName() -> getRealPath(), reflecting its actual behavior/function and stop returning status().getName() in the base class (callers can do this fallback if they want to, it complicates the contracts). This is mostly NFC, but the behavior of File::getName() affects FileManager's FileEntry::tryGetRealPathName(), which now fails in more cases: - non-real file cases - real-file cases where the underlying vfs::File was opened in a way that doesn't call realpath(). (In these cases we don't know a distinct real name, so in principle it seems OK) Reviewers: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49724 llvm-svn: 337834
* [WebAssembly] Change size_t to `unsigned long`.Dan Gohman2018-07-241-3/+5
| | | | | | | | | | | | 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
* NFC: Add the emacs c++ mode hint "-*- C++ -*-" to the headers that don't have itErik Pilkington2018-07-242-2/+2
| | | | | | https://llvm.org/docs/CodingStandards.html#file-headers llvm-svn: 337780
* [MS] Update _MSVC_LANG values for C++17 and C++2aReid Kleckner2018-07-231-2/+4
| | | | | | Fixes PR38262 llvm-svn: 337715
OpenPOWER on IntegriCloud