History log of /llvm-project/clang/lib/Frontend/InitPreprocessor.cpp (Results 176 – 200 of 493)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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


12345678910>>...20