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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
HIP is a language similar to CUDA (https://github.com/ROCm-Developer-Tools/HIP/blob/master/docs/markdown/hip_kernel_language.md ).
The language syntax is very similar, which allows a hip program to be compiled as a CUDA program by Clang. The main difference
is the host API. HIP has a set of vendor neutral host API which can be implemented on different platforms. Currently there is open source
implementation of HIP runtime on amdgpu target (https://github.com/ROCm-Developer-Tools/HIP).
This patch adds support of input kind and language standard hip.
When hip file is compiled, both LangOpts.CUDA and LangOpts.HIP is turned on. This allows compilation of hip program as CUDA
in most cases and only special handling of hip program is needed LangOpts.HIP is checked.
This patch also adds support of kernel launching of HIP program using HIP host API.
When -x hip is not specified, there is no behaviour change for CUDA.
Patch by Greg Rodgers.
Revised and lit test added by Yaxun Liu.
Differential Revision: https://reviews.llvm.org/D44984
llvm-svn: 330790
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here
Note: this is a recommit after a test failure took down the original (r318669)
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 320391
This adds -std=c17, -std=gnu17, and -std=iso9899:2017 as language mode flags for C17 and updates the value of __STDC_VERSION__ to the value based on the C17 FDIS. Given that this ballot cannot succeed until 2018, it is expected that we (and GCC) will add c18 flags as aliases once the ballot passes.
llvm-svn: 320089
This definition is similar to __WCHAR_MAX__, except that it applies to
wint_t. It's also documented as being supported by GCC 4.5 and later.
llvm-svn: 319746
Fedora27 is using a new version of glibc that refers to the _Float128 type. This
patch adds that name as an alias to float128. I also added some predefined macro
values for the digits, mantissa, epilon, etc (FloatMacros). For the test case, I
copied an existing float128 test. This functionality needs work long term, but
it should be sufficient to tread water for a while. At Intel we have test
servers running our LLVM compiler with various open source workloads, the server
has been upgraded to Fedora27 so many workloads are failing due to _Float128.
Patch-By: mibintc
Differential Revision: https://reviews.llvm.org/D40673
llvm-svn: 319703
This is a re-apply of r319294.
adds -fseh-exceptions and -fdwarf-exceptions flags
clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1
-fno-exceptions has a higher priority then specifying the model
move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag
move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check
remove unused USESEHExceptions from the MinGW Driver
fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models
Reviewers: rnk, mstorsjo
Differential Revision: https://reviews.llvm.org/D39673
llvm-svn: 319297
adds -fseh-exceptions and -fdwarf-exceptions flags
clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1
clang cc1 assumes dwarf is the default if none is passed
and -fno-exceptions has a higher priority then specifying the model
move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag
move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check
remove unused USESEHExceptions from the MinGW Driver
fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models
Reviewers: rnk, mstorsjo
Differential Revision: https://reviews.llvm.org/D39673
llvm-svn: 319294
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.”
See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits
this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate
patch for that which is linked here
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 318669
OpenCL 2.0 atomic builtin functions have a scope argument which is ideally
represented as synchronization scope argument in LLVM atomic instructions.
Clang supports translating Clang atomic builtin functions to LLVM atomic
instructions. However it currently does not support synchronization scope
of LLVM atomic instructions. Without this, users have to use LLVM assembly
code to implement OpenCL atomic builtin functions.
This patch adds OpenCL 2.0 atomic builtin functions as Clang builtin
functions, which supports generating LLVM atomic instructions with
synchronization scope operand.
Currently only constant memory scope argument is supported. Support of
non-constant memory scope argument will be added later.
Differential Revision: https://reviews.llvm.org/D28691
llvm-svn: 310082
Summary: Device offloading requires the specification of an additional flag containing the triple of the //other// architecture the code is being compiled on if such an architecture exists. If compiling for the host, the auxiliary triple flag will contain the triple describing the device and vice versa.
Reviewers: arpith-jacob, sfantao, caomhin, carlo.bertolli, ABataev, Hahnfeld, jlebar, hfinkel, tstellar
Reviewed By: Hahnfeld
Subscribers: rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D29339
llvm-svn: 306689
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
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
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
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
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
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
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
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
Currently, the Clang version is computed as follows:
1. LLVM defines major, minor, and patch versions, all statically set. Today,
these are 4, 0, and 0, respectively.
2. The static version numbers are combined into PACKAGE_VERSION along with a
suffix, so the result today looks like "4.0.0svn".
3. Clang extracts CLANG_VERSION from PACKAGE_VERSION using a regexp. The regexp
allows the patch level to omitted, and drops any non-digit trailing values.
Today, this result looks like "4.0.0".
4. CLANG_VERSION is then split further into CLANG_VERSION_MAJOR and
CLANG_VERSION_MINOR. Today, these resolve to 4 and 0, respectively.
5. If CLANG_VERSION matches a regexp with three version components, then
CLANG_VERSION_PATCHLEVEL is extracted and the CLANG_HAS_VERSION_PATCHLEVEL
variable is set to 1. Today, these values are 0 and 1, respectively.
6. The CLANG_VERSION_* variables (and CLANG_HAS_VERSION_PATCHLEVEL) are
configured into [llvm/tools/clang/]include/clang/Basic/Version.inc
verbatim by CMake.
7. In [llvm/tools/clang/]include/clang/Basic/Version.h, macros are defined
conditionally, based on CLANG_HAS_VERSION_PATCHLEVEL, to compute
CLANG_VERSION_STRING as either a two- or three-level version number. Today,
this value is "4.0.0", because despite the patchlevel being 0, it was
matched by regexp and is thus "HAS"ed by the preprocessor. This string is
then used wherever Clang's "version" is needed [*].
[*] Including, notably, by compiler-rt, for computing its installation path.
This change collapses steps 2-5 by defaulting Clang to use LLVM's (non-string)
version components for the Clang version (see [*] for why not PACKAGE_VERSION),
and collapses steps 6 and 7 by simply writing CLANG_VERSION_STRING into
Version.inc. The Clang version today always uses the patchlevel form, so the
collapsed Version.inc does not have logic for a version without a patch level.
Historically speaking, this technique began with the VER file in r82085 (which
survives in the form of the regexp in #3). The major, minor, and patchlevel
versions were introduced by r106863 (which remains in #4-6). The VER file itself
was deleted in favor of the LLVM version number in r106914. On the LLVM side,
the individual LLVM_VERSION_MAJOR, LLVM_VERSION_MINOR, and PACKAGE_VERSION
weren't introduced for nearly two more years, until r150405.
llvm-svn: 281666
OpenCL requires __ENDIAN_LITTLE__ be set for little endian targets.
The default for targets was also apparently big endian, so AMDGPU
was incorrectly reported as big endian. Set this from the triple
so targets don't have another place to set the endianness.
llvm-svn: 280787
The PIC and PIE levels are not independent. In fact, if PIE is defined
it is always the same as PIC.
This is clear in the driver where ParsePICArgs returns a PIC level and
a IsPIE boolean. Unfortunately that is currently lost and we pass two
redundant levels down the pipeline.
This patch keeps a bool and a PIC level all the way down to codegen.
llvm-svn: 273566
OpenMP version.
If '-fopenmp' option is provided '-fopenmp-version=' allows to control,
which version of OpenMP must be supported. Currently it affects only the
value of _OPENMP define.
llvm-svn: 270838
OpenMP 4.5.
According to OpenMP 4.5 the _OPENMP macro name is defined to have the decimal value yyyymm where yyyy and mm are the year and month designations of the version of the OpenMP API that the implementation supports. Clang supports OpenMP 4.5 so updated value of _OPENMP macro to 201511.
llvm-svn: 270822
Add supported OpenCL extensions to target info. It serves as default values to save the users of the burden setting each supported extensions and optional core features in command line.
Re-commit after fixing build error due to missing override attribute.
Differential Revision: http://reviews.llvm.org/D19484
llvm-svn: 269670
Revert r269431 due to build failure caused by warning msg:
llvm/tools/clang/lib/Basic/Targets.cpp:2090:9: error: 'setSupportedOpenCLOpts' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
void setSupportedOpenCLOpts() {
llvm-svn: 269435
Add supported OpenCL extensions to target info. It serves as default values to save the users of the burden setting each supported extensions and optional core features in command line.
Differential Revision: http://reviews.llvm.org/D19484
llvm-svn: 269431
OpenCL spec requires __OPENCL_C_VERSION__ to be defined based on -cl-std option. This patch implements that.
The patch also defines __FAST_RELAXED_MATH__ based on -cl-fast-relaxed-math option.
Also fixed a test using -std=c99 for OpenCL program. Limit allowed language standard of OpenCL to be OpenCL standards.
Differential Revision: http://reviews.llvm.org/D19071
llvm-svn: 267590
-H in gcc mode doesn't print -include headers, but they are included in
depfiles written by MMD and friends. Since /showIncludes is what's used instead
of depfiles, printing /FI there seems important (and matches cl.exe).
Instead of giving HeaderIncludeGen more options, just switch on ShowAllHeaders
in clang-cl mode and let clang::InitializePreprocessor() not put -include flags
in the <command line> block. This changes the behavior of -E slightly, and it
removes the <command line> flag from the output triggered by setting the
obscure CC_PRINT_HEADERS=1 env var to true while running clang. Both of these
seem ok to change.
http://reviews.llvm.org/D18401
llvm-svn: 264174
Use it to calculate UserLabelPrefix, instead of specifying it (often
incorrectly).
Note that the *actual* user label prefix has always come from the
DataLayout, and is handled within LLVM. The main thing clang's
TargetInfo::UserLabelPrefix did was to set the #define value. Having
these be different from each-other is just silly.
Differential Revision: http://reviews.llvm.org/D17183
llvm-svn: 262737
Currently clang requires several additional command
line options in order to enable new features needed
during CUDA compilation. This patch makes these
options default.
* Automatically include cuda_runtime.h if we've found
a valid CUDA installation.
* Disable automatic CUDA header inclusion during unit tests.
* Added test case for command line construction.
* Enabled target overloads and relaxed call checks that are
needed in order to include CUDA headers.
* Added CUDA-7.5 installation path to the CUDA installation search list.
* Define __CUDA__ macro to indicate CUDA compilation.
llvm-svn: 253389
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
llvm-svn: 251041
* adds -aux-triple option to specify target triple
* propagates aux target info to AST context and Preprocessor
* pulls in target specific preprocessor macros.
* pulls in target-specific builtins from aux target.
* sets appropriate host or device attribute on builtins.
Differential Revision: http://reviews.llvm.org/D12917
llvm-svn: 248299
- introduces a new cc1 option -fmodule-format=[raw,obj]
with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
a PCHContainerReader.
Thanks to Richard Smith for reviewing this patch!
llvm-svn: 242499
A PCHContainerOperations abstract interface provides operations for
creating and unwrapping containers for serialized ASTs (precompiled
headers and clang modules). The default implementation is
RawPCHContainerOperations, which uses a flat file for the output.
The main application for this interface will be an
ObjectFilePCHContainerOperations implementation that uses LLVM to
wrap the module in an ELF/Mach-O/COFF container to store debug info
alongside the AST.
rdar://problem/20091852
llvm-svn: 240225
in-progress implementation of the Concepts TS. The recommended feature
test macro __cpp_experimental_concepts is set to 1 (as opposed to
201501) to indicate that the feature is enabled, but the
implementation is incomplete.
The link to the Concepts TS in cxx_status is updated to refer to the
PDTS (N4377). Additional changes related to __has_feature and
__has_extension are to follow in a later change.
Relevant tests include:
test/Lexer/cxx-features.cpp
The test file is updated with testing of the C++14 + Concepts TS mode.
The expected behaviour is the same as that of the C++14 modes except
for the case of __cpp_experimental_concepts."
- Hubert Tong.
Being committed for Hubert (as per his understanding with Richard Smith) as we start work on the concepts-ts following our preliminary strategy session earlier today.
The patch is tiny and seems quite standard.
Thanks Hubert!
llvm-svn: 237982
Previously we were setting LangOptions::GNUInline (which controls whether we
use traditional GNU inline semantics) if the language did not have the C99
feature flag set. The trouble with this is that C++ family languages also
do not have that flag set, so we ended up setting this flag in C++ modes
(and working around it in a few places downstream by also checking CPlusPlus).
The fix is to check whether the C89 flag is set for the target language,
rather than whether the C99 flag is cleared. This also lets us remove most
CPlusPlus checks. We continue to test CPlusPlus when deciding whether to
pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC.
There is a change in semantics in two other places
where we weren't checking both CPlusPlus and GNUInline
(FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and
FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to
put us back into line with GCC's semantics (test case: test/CodeGen/inline.c).
While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it,
it didn't have any effect before, and supporting it just makes things more
complicated.
Differential Revision: http://reviews.llvm.org/D9333
llvm-svn: 237299
Before C11 there was only the DECIMAL_DIG definition. As of C11, we now
have one definition per floating point type (e.g. DBL_DECIMAL_DIG).
Change the existing code to define the new versions. To remain backward
compatible, define __DECIMAL_DIG__ as __LDBL_DECIMAL_DIG__.
Also update the tests. It seems that some of the existing test vectors
were incorrect. Change all tests for __DECIMAL_DIG__ to expect
__LDBL_DECIMAL_DIG__. Add tests for *_DECIMAL_DIG for FreeBSD/amd64, as
I happen to have such a system laying around. I've validated that the
values are in sync with <float.h>.
llvm-svn: 230207
Partially revert r223927 because LLVM gained support for 128-bit integers
in r227089. Modify and keep the tests that verify the definition of the
macro __SIZEOF_INT128__ for MIPS64 BE & LE in the preprocessor.
llvm-svn: 228918
For compatibility with GCC (and because it's generally helpful information
otherwise inaccessible to the preprocessor). This appears to be canonically the
alignment of max_align_t (e.g. on i386, __BIGGEST_ALIGNMENT__ is 4 even though
vector types will be given greater alignment).
Patch mostly by Mats Petersson
llvm-svn: 228367
This is a temporary workaround while MIPS64 has not yet fully supported
128-bit integers. But declaration of int128 type is necessary even though
`__SIZEOF_INT128__` is undefined because c++ standard header files like
`limits` throw error message if `__int128` is not available.
Patch by Sagar Thakur.
Differential Revision: http://reviews.llvm.org/D6402
llvm-svn: 223927
Summary:
Allow CUDA host device functions with two code paths using __CUDA_ARCH__
to differentiate between code path being compiled.
For example:
__host__ __device__ void host_device_function(void) {
#ifdef __CUDA_ARCH__
device_only_function();
#else
host_only_function();
#endif
}
Patch by Jacques Pienaar.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D6457
llvm-svn: 223271
This option was misleading because it looked like it enabled the
language feature of SEH (__try / __except), when this option was really
controlling which EH personality function to use. Mingw only supports
SEH and SjLj EH on x86_64, so we can simply do away with this flag.
llvm-svn: 221963
This adds a flag called -fseh-exceptions that uses the native Windows
.pdata and .xdata unwind mechanism to throw exceptions. The other EH
possibilities are DWARF and SJLJ exceptions.
Patch by Martell Malone!
Reviewed By: asl, rnk
Differential Revision: http://reviews.llvm.org/D3419
llvm-svn: 217790
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
According to the gcc docs, -include uses the current working directory
for the lookup instead of the main source file.
This patch gets rid of NormalizeIncludePath (which relied on an
implementation detail of FileManager / FileEntry for the include path
logic to work), and instead hands the correct lookup information down to
LookupFile.
This will allow us to change the FileEntry's behavior regarding its Name
caching.
llvm-svn: 215433
These macros are used as markers for Interface Builder and need to be defined
to empty strings since they have no impact on the code.
Patch by Ted Kremenek.
llvm-svn: 215259
constants. Comparing int against a constant of the given type like
UINT8_MAX will otherwise force a promotion to unsigned int, which is
typically not expected.
llvm-svn: 213301
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
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
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
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
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
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
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
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
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
We translate these into #define directives; to preserve gcc-compatible
semantics (where the expanded macro includes the backslash), we add
an extra "\\\n" to the end of the synthesized "#define".
<rdar://problem/14810220>
llvm-svn: 189511
Add __has_feature and __has_extension checks for C++1y features (based on the provisional names from
the C++ features study group), and update documentation to match.
llvm-svn: 181342
since only one of them is allowed in command-line, process them separately.
Otherwise, if more than one is specified in the command-line, one is processed normally
and the others are going to be treated and included as header files.
Related to radar://13140508
llvm-svn: 174385
Anastasia Stulova