#
d2b9fc88 |
| 06-May-2019 |
Hans Wennborg <hans@hanshq.net> |
Revert r359949 "[clang] adding explicit(bool) from c++2a"
This caused Clang to start erroring on the following:
struct S { template <typename = int> explicit S(); };
struct T : S {};
Revert r359949 "[clang] adding explicit(bool) from c++2a"
This caused Clang to start erroring on the following:
struct S { template <typename = int> explicit S(); };
struct T : S {};
struct U : T { U(); }; U::U() {}
$ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {} ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {}; ^ 1 error generated.
See discussion on the cfe-commits email thread.
This also reverts the follow-ups r359966 and r359968.
> this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934
llvm-svn: 360024
show more ...
|
#
5fe2ddbd |
| 04-May-2019 |
Nicolas Lesser <blitzrakete@gmail.com> |
[clang] adding explicit(bool) from c++2a
this patch adds support for the explicit bool specifier.
Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage o
[clang] adding explicit(bool) from c++2a
this patch adds support for the explicit bool specifier.
Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added.
This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.
Patch by Tyker
Differential Revision: https://reviews.llvm.org/D60934
llvm-svn: 359949
show more ...
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3 |
|
#
3f62fa69 |
| 25-Feb-2019 |
Alexey Bader <alexey.bader@intel.com> |
[SYCL] Add clang front-end option to enable SYCL device compilation flow.
Patch by Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
llvm-svn: 354773
|
#
10ab78e8 |
| 23-Feb-2019 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Enable coroutines under -std=c++2a.
llvm-svn: 354736
|
#
1e25464f |
| 20-Feb-2019 |
Nemanja Ivanovic <nemanja.i.ibm@gmail.com> |
Make predefined FLT16 macros conditional on support for the type
We unconditionally predefine these macros. However, they may be used to determine if the type is supported. In that case, there are u
Make predefined FLT16 macros conditional on support for the type
We unconditionally predefine these macros. However, they may be used to determine if the type is supported. In that case, there are unnecessary failures to compile the code.
This is the proposed fix for https://bugs.llvm.org/show_bug.cgi?id=40559
Differential revision: https://reviews.llvm.org/D57577
llvm-svn: 354512
show more ...
|
Revision tags: llvmorg-7.1.0, llvmorg-7.1.0-rc1 |
|
#
e88e2b99 |
| 07-Feb-2019 |
Anastasia Stulova <anastasia.stulova@arm.com> |
[OpenCL][PR40603] In C++ preserve compatibility with OpenCL C v2.0
Valid OpenCL C code should still compile in C++ mode.
This change enables extensions and OpenCL types.
Differential Revision: htt
[OpenCL][PR40603] In C++ preserve compatibility with OpenCL C v2.0
Valid OpenCL C code should still compile in C++ mode.
This change enables extensions and OpenCL types.
Differential Revision: https://reviews.llvm.org/D57824
llvm-svn: 353431
show more ...
|
Revision tags: llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
#
8dfa4ad9 |
| 11-Jan-2019 |
Chris Kennelly <ckennelly@google.com> |
Implementation Feature Test Macros for P0722R3
Summary: P1353R0, adopted in San Diego, specified an implementation feature test macro for destroying delete (P0722R3).
The implementation of the feat
Implementation Feature Test Macros for P0722R3
Summary: P1353R0, adopted in San Diego, specified an implementation feature test macro for destroying delete (P0722R3).
The implementation of the feature (https://reviews.llvm.org/rL315662) is not guarded behind a flag, so the macro is not conditional on language version.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D55741
llvm-svn: 350934
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
#
0a6b5b65 |
| 04-Dec-2018 |
Erich Keane <erich.keane@intel.com> |
PTH-- Remove feature entirely-
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 Toke
PTH-- Remove feature entirely-
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
show more ...
|
#
28ddb91d |
| 14-Nov-2018 |
Richard Smith <richard-llvm@metafoo.co.uk> |
[c++20] Implement P0482R6: enable -fchar8_t by default in C++20 mode.
This unfortunately results in a substantial breaking change when switching to C++20, but it's not yet clear what / how much we s
[c++20] Implement P0482R6: enable -fchar8_t by default in C++20 mode.
This unfortunately results in a substantial breaking change when switching to C++20, but it's not yet clear what / how much we should do about that. We may want to add a compatibility conversion from u8 string literals to const char*, similar to how C++98 provided a compatibility conversion from string literals to non-const char*, but that's not handled by this patch.
The feature can be disabled in C++20 mode with -fno-char8_t.
llvm-svn: 346892
show more ...
|
Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
#
fa98390b |
| 30-Oct-2018 |
Erik Pilkington <erik.pilkington@gmail.com> |
NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)
We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separat
NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)
We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.
Differential revision: https://reviews.llvm.org/D53547
llvm-svn: 345637
show more ...
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3 |
|
#
e4c3c6c8 |
| 30-Aug-2018 |
Artem Belevich <tra@google.com> |
Reverted the "[CUDA/OpenMP] Define only some host macros during device compilation"
The changes were breaking CUDA compilation.
Reverted revisions: r340681 D50845 [CUDA/OpenMP] Define only som
Reverted the "[CUDA/OpenMP] Define only some host macros during device compilation"
The changes were breaking CUDA compilation.
Reverted revisions: r340681 D50845 [CUDA/OpenMP] Define only some host macros during device compilation r340772 D51312 [OpenMP][NVPTX] Use appropriate _CALL_ELF macro when offloading r340967 D51441 Add predefined macro __gnu_linux__ for proper aux-triple
llvm-svn: 341115
show more ...
|
#
0e9a76db |
| 29-Aug-2018 |
Yaxun Liu <Yaxun.Liu@amd.com> |
Add predefined macro __gnu_linux__ for proper aux-triple
Clang predefine macro __linx__ for aux-triple with Linux OS but does not predefine macro __gnu_linux__. This causes some compilation error fo
Add predefined macro __gnu_linux__ for proper aux-triple
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
show more ...
|
#
7af5d66b |
| 27-Aug-2018 |
Gheorghe-Teodor Bercea <gheorghe-teod.bercea@ibm.com> |
[OpenMP][NVPTX] Use appropriate _CALL_ELF macro when offloading
Summary: When offloading to a device and using the powerpc64le version of the auxiliary triple, the _CALL_ELF macro is not set correct
[OpenMP][NVPTX] Use appropriate _CALL_ELF macro when offloading
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
show more ...
|
#
931939bf |
| 25-Aug-2018 |
Jonas Hahnfeld <hahnjo@hahnjo.de> |
[CUDA/OpenMP] Define only some host macros during device compilation
When compiling CUDA or OpenMP device code Clang parses header files that expect certain predefined macros from the host architect
[CUDA/OpenMP] Define only some host macros during device compilation
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
show more ...
|
Revision tags: llvmorg-7.0.0-rc2 |
|
#
e5015abf |
| 03-Aug-2018 |
Volodymyr Sapsai <vsapsai@apple.com> |
[Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.
Libc++ needs to know when aligned allocation is supported by clang, but is otherwise unavailable at link time. Otherwise
[Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.
Libc++ needs to know when aligned allocation is supported by clang, but is otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with alignment arguments.
This patch implements the following changes:
* The `__cpp_aligned_new` feature test macro to no longer be defined when aligned allocation is otherwise enabled but unavailable.
* The Darwin driver no longer passes `-faligned-alloc-unavailable` when the user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`.
* Instead of a warning Clang now generates a hard error when an aligned allocation or deallocation function is referenced but unavailable.
Patch by Eric Fiselier.
Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith
Reviewed By: rsmith
Subscribers: Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D45015
llvm-svn: 338934
show more ...
|
Revision tags: llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3 |
|
#
20eb9baa |
| 14-Jun-2018 |
Richard Smith <richard-llvm@metafoo.co.uk> |
P0096R5, P0941R2: Update to match latest feature test macro specification.
llvm-svn: 334677
|
Revision tags: llvmorg-6.0.1-rc2 |
|
#
51055730 |
| 30-May-2018 |
Richard Smith <richard-llvm@metafoo.co.uk> |
As discussed with SG10, bump version of __cpp_deduction_guides macro to indicate support for P0620R0.
llvm-svn: 333587
|
#
404bbcbd |
| 22-May-2018 |
David Chisnall <csdavec@swan.ac.uk> |
Revert "Revert r332955 "GNUstep Objective-C ABI version 2""
llvm-svn: 332963
|
#
84466335 |
| 22-May-2018 |
Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> |
Revert r332955 "GNUstep Objective-C ABI version 2"
Reverted due to buildbot failures. Seems like isnumber() is some Apple addition to cctype.
llvm-svn: 332957
|
#
79356eef |
| 22-May-2018 |
David Chisnall <csdavec@swan.ac.uk> |
GNUstep Objective-C ABI version 2
Summary: This includes initial support for the (hopefully final) updated Objective-C ABI, developed here:
https://github.com/davidchisnall/clang-gnustep-abi-2
It
GNUstep Objective-C ABI version 2
Summary: This includes initial support for the (hopefully final) updated Objective-C ABI, developed here:
https://github.com/davidchisnall/clang-gnustep-abi-2
It also includes some cleanups and refactoring from older GNU ABIs.
The current version is ELF only, other formats to follow.
Reviewers: rjmccall, DHowett-MSFT
Reviewed By: rjmccall
Subscribers: smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D46052
llvm-svn: 332950
show more ...
|
#
66f9577f |
| 21-May-2018 |
Alexey Bataev <a.bataev@hotmail.com> |
[OPENMP-SIMD] Fix PR37536: Fix definition of _OPENMP macro.
if `-fopenmp-simd` is specified alone, `_OPENMP` macro should not be defined. If `-fopenmp-simd` is specified along with the `-fopenmp`,
[OPENMP-SIMD] Fix PR37536: Fix definition of _OPENMP macro.
if `-fopenmp-simd` is specified alone, `_OPENMP` macro should not be defined. If `-fopenmp-simd` is specified along with the `-fopenmp`, `_OPENMP` macro should be defined with the value `201511`.
llvm-svn: 332852
show more ...
|
#
9fc8faf9 |
| 09-May-2018 |
Adrian Prantl <aprantl@apple.com> |
Remove \brief commands from doxygen comments.
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of years now. Thi
Remove \brief commands from doxygen comments.
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
show more ...
|
#
3a8244df |
| 01-May-2018 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Implement P0482R2, support for char8_t type.
This is not yet part of any C++ working draft, and so is controlled by the flag -fchar8_t rather than a -std= flag. (The GCC implementation is controlled
Implement P0482R2, support for char8_t type.
This is not yet part of any C++ working draft, and so is controlled by the flag -fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a flag with the same name.)
This implementation is experimental, and will be removed or revised substantially to match the proposal as it makes its way through the C++ committee.
llvm-svn: 331244
show more ...
|
#
9061e4f4 |
| 25-Apr-2018 |
Yaxun Liu <Yaxun.Liu@amd.com> |
[HIP] Add predefined macros __HIPCC__ and __HIP_DEVICE_COMPILE__
Differential Revision: https://reviews.llvm.org/D45441
llvm-svn: 330824
|