[x32] Add __ILP32__ macro for ILP32 platforms

Summary:
Add __ILP32__ and _ILP32 macro for corresponding platforms.
Cover x86_64-*-*-gnux32 with test.

Test Plan: test added

Reviewers: chandlerc, at

[x32] Add __ILP32__ macro for ILP32 platforms

Summary:
Add __ILP32__ and _ILP32 macro for corresponding platforms.
Cover x86_64-*-*-gnux32 with test.

Test Plan: test added

Reviewers: chandlerc, atanasyan

Subscribers: cfe-commits, dschuff, zinovy.nis

Differential Revision: http://reviews.llvm.org/D4473

llvm-svn: 212931

show more ...

Avoid definining more GCC specific predefined macros in clang-cl

Reviewers: hansw, rnk

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D4419

llvm-svn: 212753

Turn some Twine locals into const char * variables.

No functionality change, just stylistic cleanup. Change made by clang-tidy
and clang-format.

llvm-svn: 212544

Fix layering of file remapping and header search initialization

These two functions initialize the source manager and header search objects and
shouldn't be in InitPreprocessor which is concerned wi

Fix layering of file remapping and header search initialization

These two functions initialize the source manager and header search objects and
shouldn't be in InitPreprocessor which is concerned with priming the
preprocessor itself and predefining macros.

llvm-svn: 212434

show more ...

Do not define __STRICT_ANSI__ in clang-cl

llvm-svn: 212066

Implement predefined stdint macros

Add predefined stdint macros that match the given patterns:

U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}
U?INT{PTR,MAX}_{MAX,TYPE}

http://reviews.llvm.org/D4141

Implement predefined stdint macros

Add predefined stdint macros that match the given patterns:

U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}
U?INT{PTR,MAX}_{MAX,TYPE}

http://reviews.llvm.org/D4141

Author: binji
llvm-svn: 211657

show more ...

Add -std=c++1z flag for C++17 features.

llvm-svn: 211030

Do not predefine __EXCEPTIONS in clang-cl (PR19977)

Patch by Ehsan Akhgari! (Test tweak by me.)

Differential Revision: http://reviews.llvm.org/D4065

llvm-svn: 210582

[C++11] Use 'nullptr'. Frontend edition.

llvm-svn: 209389

Revert "Move -fms-extensions predefined macros into InitPreprocessor"

This reverts commit r206413.

This was proposed before, but it's not clear if this is really a good
idea:
http://reviews.llvm.or

Revert "Move -fms-extensions predefined macros into InitPreprocessor"

This reverts commit r206413.

This was proposed before, but it's not clear if this is really a good
idea:
http://reviews.llvm.org/D3034

llvm-svn: 206415

show more ...

Move -fms-extensions predefined macros into InitPreprocessor

If someone on Linux asks for -fms-extensions, there's no reason not to
define the feature test macros that MSVC defines.

llvm-svn: 206413

-fms-extensions: Don't define __PRETTY_FUNCTION__ to __FUNCTION__

This reverts r90596 from 2009. Having this macro definition makes Clang
strictly less useful with -fms-extensions.

llvm-svn: 205729

Implement the MS extension __identifier properly: take a token and strip it of
its keywordliness.

llvm-svn: 203987

Make __LITTLE_ENDIAN__/__BIG_ENDOAN__ common PredefinedMacros

llvm-svn: 203455

[OPENMP] Updated comments and _OPENMP macro value for OpenMP 4.0 (for 'omp simd' support)

llvm-svn: 203114

Revert "Preprocessor: Add __ALIGNOF_MAX_ALIGN_T__"

This commit reverts r201037, it's functionality is not needed given the
definition of std::max_align_t in libcxx circa r201843.

llvm-svn: 202667

Update __cplusplus to match the value in the C++14 DIS preview (D3937).

llvm-svn: 202003

[stackprotector] Add command line option -fstack-protector-strong

This option has the following effects:
* It adds the sspstrong IR attribute to each function within the CU.
* It defines the macro

[stackprotector] Add command line option -fstack-protector-strong

This option has the following effects:
* It adds the sspstrong IR attribute to each function within the CU.
* It defines the macro __SSP_STRONG__ with the value of 2.

Differential Revision: http://llvm-reviews.chandlerc.com/D2717

llvm-svn: 201120

show more ...

Preprocessor: Add __ALIGNOF_MAX_ALIGN_T__

TargetInfo::getSuitableAlign() was introduced in r146762 and is defined
as alignof(std::max_align_t).

Introduce __ALIGNOF_MAX_ALIGN_T__ which exposes getSu

Preprocessor: Add __ALIGNOF_MAX_ALIGN_T__

TargetInfo::getSuitableAlign() was introduced in r146762 and is defined
as alignof(std::max_align_t).

Introduce __ALIGNOF_MAX_ALIGN_T__ which exposes getSuitableAlign() so
that libc++ may take advantage of it.

llvm-svn: 201037

show more ...

Rename language option MicrosoftMode to MSVCCompat

There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, fol

Rename language option MicrosoftMode to MSVCCompat

There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.

MicrosoftExt (aka. fms-extensions):
Enable largely unobjectionable Microsoft language extensions to ease
portability. This mode, also supported by gcc, is used for building software
like FreeBSD and Linux kernel extensions that share code with Windows drivers.

MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
Turn on a special mode supporting 'heinous' extensions for drop-in
compatibility with the Microsoft Visual C++ product. Standards-compilant C and
C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.

Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.

See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'

No change in behaviour.

llvm-svn: 199209

show more ...

Move MS predefined type_info out of InitializePredefinedMacros

Instead of keeping it in amongst the macros, build the declaration at Sema init
the same way we do with other predeclared and builtin t

Move MS predefined type_info out of InitializePredefinedMacros

Instead of keeping it in amongst the macros, build the declaration at Sema init
the same way we do with other predeclared and builtin types.

In practice this means the declaration is marked implicit and therefore won't
show up as an unwanted user-declared type in tooling which has been a
frequently reported issue (though I haven't been able to cook up a test).

llvm-svn: 198497

show more ...

Add support for C++'s SD6 feature test macros.

llvm-svn: 195888

Add character set related __STDC_* definitions.

Clang uses UTF-16 and UTF-32 for its char16_t's and char32_t's
exclusively. This means that we can define __STDC_UTF_16__ and
__STDC_UTF_32__ uncondit

Add character set related __STDC_* definitions.

Clang uses UTF-16 and UTF-32 for its char16_t's and char32_t's
exclusively. This means that we can define __STDC_UTF_16__ and
__STDC_UTF_32__ unconditionally.

While there, define __STDC_MB_MIGHT_NEQ_WC__ for FreeBSD. FreeBSD's
wchar_t's don't encode characters as ISO-10646; the encoding depends on
the locale used. Because the character set used might not be a superset
of ASCII, we must define __STDC_MB_MIGHT_NEQ_WC__.

llvm-svn: 191631

show more ...

Add a define for the ObjFW runtime ABI version.

This removes __has_feature(objc_msg_lookup_stret), as it is not required
anymore after this patch.

Patch by Jonathan Schleifer!

llvm-svn: 190791

Add new methods for TargetInfo:
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeFo

Add new methods for TargetInfo:
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth.

As first commit for PR16752 fix: 'mode' attribute for unusual targets doesn't work properly
Description:
Troubles could be happened due to some assumptions in handleModeAttr function (see SemaDeclAttr.cpp).
For example, it assumes that 32 bit integer is 'int', while it could be 16 bit only.
Instead of asking target: 'which type do you want to use for int32_t ?' it just hardcodes general opinion. That doesn't looks pretty correct.
Please consider the next solution:
1. In Basic/TargetInfo add getIntTypeByWidth and getRealTypeByWidth virtual methods. By default current behaviour could be implemented here.
2. Fix handleModeAttr according to new methods in TargetInfo.
This approach is implemented in the patch attached to this post.

Fixes:
1st Commit (Current): Add new methods for TargetInfo:
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth

2nd Commit (Next): Fix SemaDeclAttr, handleModeAttr function.

llvm-svn: 190044

show more ...