Only define __SIZEOF_FLOAT128__ on x86 as intended in r304012

GCC only defines it on x86.

llvm-svn: 304013

Enable __float128 for mingw for GCC compatibility and define __SIZEOF_FLOAT128__ on x86

GCC defines __FLOAT128__ on Power and __SIZEOF_FLOAT128__ on x86. We're
just following the inconsistency for n

Enable __float128 for mingw for GCC compatibility and define __SIZEOF_FLOAT128__ on x86

GCC defines __FLOAT128__ on Power and __SIZEOF_FLOAT128__ on x86. We're
just following the inconsistency for now so users have some way to test.

Effectively merges this patch as requested by Martell Malone:
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-clang/0107-enable-__float128-for-X86-MinGW.patch

llvm-svn: 304012

show more ...

[coroutines] Bump __cpp_coroutines version

Summary: This patch is needed so that Libc++ can actually tess if Clang supports coroutines, instead of just paying lip service with a partial implementati

[coroutines] Bump __cpp_coroutines version

Summary: This patch is needed so that Libc++ can actually tess if Clang supports coroutines, instead of just paying lip service with a partial implementation. Otherwise the libc++ test suite will fail against older versions of Clang

Reviewers: GorNishanov, rsmith

Reviewed By: GorNishanov

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D33536

llvm-svn: 303867

show more ...

Refactor frontend InputKind to prepare for treating module maps as a distinct kind of input.

No functionality change intended.

llvm-svn: 301442

Add __CLANG_ATOMIC_<TYPE>_LOCK_FREE macros for use in MSVC compatibility mode.

Summary:
Libc++ currently implements the `ATOMIC_<TYPE>_LOCK_FREE` macros using the `__GCC_ATOMIC_<TYPE>_LOCK_FREE` mac

Add __CLANG_ATOMIC_<TYPE>_LOCK_FREE macros for use in MSVC compatibility mode.

Summary:
Libc++ currently implements the `ATOMIC_<TYPE>_LOCK_FREE` macros using the `__GCC_ATOMIC_<TYPE>_LOCK_FREE` macros. However these are not available when MSVC compatibility is enabled even though C11 `_Atomic` is. This prevents libc++ from correctly implementing `ATOMIC_<TYPE>_LOCK_FREE`.

This patch adds an alternative spelling `__CLANG_ATOMIC_<TYPE>_LOCK_FREE` that is enabled with `-fms-compatibility`.

Reviewers: rsmith, aaron.ballman, majnemer, zturner, compnerd, jfb, rnk

Reviewed By: rsmith

Subscribers: BillyONeal, smeenai, jfb, cfe-commits, dschuff

Differential Revision: https://reviews.llvm.org/D32265

llvm-svn: 300914

show more ...

Bump __cplusplus for C++17 to 201703L per the C++17 DIS.

llvm-svn: 298299

Revert r291477 "[Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin"

It caused PR31864. There is a patch in progress to fix that, but let's
revert in the meantime.

llvm-svn: 296063

[c++1z] Mark constexpr lambdas as done on status page and start advertising
them via feature test macro __cpp_constexpr.

Thanks to Faisal for implementing this feature!

llvm-svn: 295791

[c++1z] Add some more tests for class template argument deduction, add
feature-test macro, and mark feature as done on status page.

llvm-svn: 295011

[Frontend] The macro that describes the Objective-C bool type should
be defined for non Objective-C code as well

rdar://29794915

Differential Revision: https://reviews.llvm.org/D28349

llvm-svn: 29

[Frontend] The macro that describes the Objective-C bool type should
be defined for non Objective-C code as well

rdar://29794915

Differential Revision: https://reviews.llvm.org/D28349

llvm-svn: 292617

show more ...

[Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

Correct the logic used to set ATOMIC_*_LOCK_FREE preprocessor macros not
to rely on the ABI alignment of types. Instead, just assume

[Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

Correct the logic used to set ATOMIC_*_LOCK_FREE preprocessor macros not
to rely on the ABI alignment of types. Instead, just assume all those
types are aligned correctly by default since clang uses safe alignment
for _Atomic types even if the underlying types are aligned to a lower
boundary by default.

For example, the 'long long' and 'double' types on x86 are aligned to
32-bit boundary by default. However, '_Atomic long long' and '_Atomic
double' are aligned to 64-bit boundary, therefore satisfying
the requirements of lock-free atomic operations.

This fixes PR #19355 by correcting the value of
__GCC_ATOMIC_LLONG_LOCK_FREE on x86, and therefore also fixing
the assumption made in libc++ tests. This also fixes PR #30581 by
applying a consistent logic between the functions used to implement
both interfaces.

Differential Revision: https://reviews.llvm.org/D28213

llvm-svn: 291477

show more ...

Add __cpp_structured_bindings feature test macro for structured bindings, per
latest (provisional) draft of SD-6.

llvm-svn: 290082

[c++1z] cxx_status: mark p0195r2 as done.

llvm-svn: 290081

Recommit r289979 [OpenCL] Allow disabling types and declarations associated with extensions

Fixed undefined behavior due to cast integer to bool in initializer list.

llvm-svn: 290056

Revert r289979 due to regressions

llvm-svn: 289991

[OpenCL] Allow disabling types and declarations associated with extensions

Added a map to associate types and declarations with extensions.

Refactored existing diagnostic for disabled types associa

[OpenCL] Allow disabling types and declarations associated with extensions

Added a map to associate types and declarations with extensions.

Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation.

Fixed some bugs for types associated with extensions.

Allow users to use pragma to declare types and functions for supported extensions, e.g.

#pragma OPENCL EXTENSION the_new_extension_name : begin
// declare types and functions associated with the extension here
#pragma OPENCL EXTENSION the_new_extension_name : end

Differential Revision: https://reviews.llvm.org/D21698

llvm-svn: 289979

show more ...

Replace APFloatBase static fltSemantics data members with getter functions

At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirec

Replace APFloatBase static fltSemantics data members with getter functions

At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.

Differential Revision: https://reviews.llvm.org/D26671

llvm-svn: 289647

show more ...

p0012r1: define corresponding feature test macro

llvm-svn: 288452

[Frontend] Add a predefined macro that describes the Objective-C bool type

This commit adds a new predefined macro named __OBJC_BOOL_IS_BOOL that describes
the Objective-C boolean type: its value is

[Frontend] Add a predefined macro that describes the Objective-C bool type

This commit adds a new predefined macro named __OBJC_BOOL_IS_BOOL that describes
the Objective-C boolean type: its value is zero if the Objective-C boolean uses
the signed character type, otherwise its value is one as the Objective-C boolean
uses the builtin boolean type.

rdar://21170440

Differential Revision: https://reviews.llvm.org/D26234

llvm-svn: 287529

show more ...

Add comment explaining this mysterious macro name.

llvm-svn: 285631

Mark aligned allocation as done.

llvm-svn: 283724

[coroutines] Rename driver flag -fcoroutines to -fcoroutines-ts

Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.

Patch mostly by EricWF.

Reviewers: rnk, cfe-commits, rsmith, E

[coroutines] Rename driver flag -fcoroutines to -fcoroutines-ts

Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.

Patch mostly by EricWF.

Reviewers: rnk, cfe-commits, rsmith, EricWF

Subscribers: mehdi_amini

Differential Revision: https://reviews.llvm.org/D25130

llvm-svn: 283064

show more ...

P0035R4: add predefined __STDCPP_DEFAULT_NEW_ALIGNMENT__ macro. By default, we
assume that ::operator new provides no more alignment than is necessary for any
primitive type, except when we're on a G

P0035R4: add predefined __STDCPP_DEFAULT_NEW_ALIGNMENT__ macro. By default, we
assume that ::operator new provides no more alignment than is necessary for any
primitive type, except when we're on a GNU OS, where glibc's malloc guarantees
to provide 64-bit alignment on 32-bit systems and 128-bit alignment on 64-bit
systems. This can be controlled by the command-line -fnew-alignment flag.

llvm-svn: 282974

show more ...

Mark P0127R3 as done, and replace its __has_feature check with the corresponding SD-6 macro.

llvm-svn: 282652

Add a couple more tentative names for upcoming SD-6 feature checks. These might
not reflect the final chosen names, but supporting them now seems to have
little downside.

llvm-svn: 282629