Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266460 91177308-0d34-0410-b5e6-96231b3b80d8
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266186 91177308-0d34-0410-b5e6-96231b3b80d8
Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header".
This fixes the modules build.
Differential revision: http://reviews.llvm.org/D18954
Reviewers: Richard Smith, Vassil Vassilev.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266180 91177308-0d34-0410-b5e6-96231b3b80d8
I. Current implementation of images is not conformant to spec in the following points:
1. It makes no distinction with respect to access qualifiers and therefore allows to use images with different access type interchangeably. The following code would compile just fine:
void write_image(write_only image2d_t img);
kernel void foo(read_only image2d_t img) { write_image(img); } // Accepted code
which is disallowed according to s6.13.14.
2. It discards access qualifier on generated code, which leads to generated code for the above example:
call void @write_image(%opencl.image2d_t* %img);
In OpenCL2.0 however we can have different calls into write_image with read_only and wite_only images.
Also generally following compiler steps have no easy way to take different path depending on the image access: linking to the right implementation of image types, performing IR opts and backend codegen differently.
3. Image types are language keywords and can't be redeclared s6.1.9, which can happen currently as they are just typedef names.
4. Default access qualifier read_only is to be added if not provided explicitly.
II. This patch corrects the above points as follows:
1. All images are encapsulated into a separate .def file that is inserted in different points where image handling is required. This avoid a lot of code repetition as all images are handled the same way in the code with no distinction of their exact type.
2. The Cartesian product of image types and image access qualifiers is added to the builtin types. This simplifies a lot handling of access type mismatch as no operations are allowed by default on distinct Builtin types. Also spec intended access qualifier as special type qualifier that are combined with an image type to form a distinct type (see statement above - images can't be created w/o access qualifiers).
3. Improves testing of images in Clang.
Author: Anastasia Stulova
Reviewers: bader, mgrang.
Subscribers: pxli168, pekka.jaaskelainen, yaxunl.
Differential Revision: http://reviews.llvm.org/D17821
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265783 91177308-0d34-0410-b5e6-96231b3b80d8
Member pointers in the MS ABI are tricky for a variety of reasons.
The size of a member pointer is indeterminate until the program reaches
a point where the representation is required to be known. However,
*pointers* to member pointers may exist without knowing the pointee
type's representation. In these cases, we synthesize an opaque LLVM
type for the pointee type.
However, we can be in a situation where the underlying member pointer's
representation became known mid-way through the program. To account for
this, we attempted to manicure CodeGen's type-cache so that we can
replace the opaque member pointer type with the real deal while leaving
the pointer types unperturbed. This, unfortunately, is a problematic
approach to take as we will violate CodeGen's invariants.
These violations are mostly harmless but let's do the right thing
instead: invalidate the type-cache if a member pointer's LLVM
representation changes.
This fixes PR26313.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258839 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257254 91177308-0d34-0410-b5e6-96231b3b80d8
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254554 91177308-0d34-0410-b5e6-96231b3b80d8
We failed to see that we should have deferred the creation of a type
which references a type currently under construction because of atomic
sugar.
This fixes PR23985.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240989 91177308-0d34-0410-b5e6-96231b3b80d8
Types can be classified as being zero-initializable or
non-zero-initializable. We used to classify array types by giving them
the classification of their base element type. However, incomplete
array types are never initialized directly and thus are always
zero-initializable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238256 91177308-0d34-0410-b5e6-96231b3b80d8
Richard rejected my Sema change to interpret an integer literal zero in
a varargs context as a null pointer, so -Wsentinel sees an integer
literal zero and fires off a warning. Only CodeGen currently knows that
it promotes integer literal zeroes in this context to pointer size on
Windows. I didn't want to teach -Wsentinel about that compatibility
hack. Therefore, I'm migrating to C++11 nullptr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223079 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGen would try to come up with an LLVM IR type for a pointer to
member type on the way to forming an LLVM IR type for a pointer to
pointer to member type.
However, if the pointer to member representation has not been locked in yet,
we would not be able to come up with a pointer to member IR type.
In these cases, make the pointer to member type an incomplete type.
This will make the pointer to pointer to member type a pointer to an
incomplete type. If the class eventually obtains an inheritance model,
we will make the pointer to member type represent the actual inheritance
model.
Differential Revision: http://reviews.llvm.org/D5373
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218084 91177308-0d34-0410-b5e6-96231b3b80d8
ACLE 2.0 allows __fp16 to be used as a function argument or return
type. This enables this for AArch64.
This also fixes an existing bug that causes clang to not allow
homogeneous floating-point aggregates with a base type of __fp16. This
is valid for AAPCS64, but not for AAPCS-VFP.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216558 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC doesn't decide what the inheritance model for a returned member
pointer *until* a call expression returns it.
This fixes PR20017.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215164 91177308-0d34-0410-b5e6-96231b3b80d8
Reverting r208106 to reapply r208065 with a fix for the regression. The
issue was that the enum tried to be built even if the declaration hadn't
been constructed for debug info - presenting problems for enum templates
and typedefs of enums with names for linkage purposes.
Original commit message:
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208114 91177308-0d34-0410-b5e6-96231b3b80d8
This is breaking the compiler-rt build. Reverting while I
investigate/fix.
This reverts commit r208065.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208106 91177308-0d34-0410-b5e6-96231b3b80d8
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208065 91177308-0d34-0410-b5e6-96231b3b80d8
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGenABITypes is a wrapper built on top of CodeGenModule that exposes
some of the functionality of CodeGenTypes (held by CodeGenModule),
specifically methods that determine the LLVM types appropriate for
function argument and return values.
I addition to CodeGenABITypes.h, CGFunctionInfo.h is introduced, and the
definitions of ABIArgInfo, RequiredArgs, and CGFunctionInfo are moved
into this new header from the private headers ABIInfo.h and CGCall.h.
Exposing this functionality is one part of making it possible for LLDB
to determine the actual ABI locations of function arguments and return
values, making it possible for it to determine this for any supported
target without hard-coding ABI knowledge in the LLDB code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193717 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than going through the whole getOrCreateType machinery to
manifest a type, cut straight to the implementation because we know we
have to do work.
While the previous implementation was sufficient for the two cases
(completeness and required completeness) we have already (the general
machinery could inspect the type for those attributes & go down the full
definition path), a pending change (to emit info for types when we emit
their vtables) won't have that luxury & we'll need to force the creation
rather than relying on the general purpose routine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188486 91177308-0d34-0410-b5e6-96231b3b80d8
This just seems a bit tidier/more principled. Based on a patch provided
by Adrian - with the only minor tweak that it needed to use
"getTypeOrNull" rather than "getCompletedTypeOrNull" since we don't
store declarations in the CompletedTypes cache.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184509 91177308-0d34-0410-b5e6-96231b3b80d8
are now two distinct canonical 'AutoType's: one is the undeduced 'auto'
placeholder type, and the other is a deduced-but-dependent type. All
deduced-to-a-non-dependent-type cases are still non-canonical.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180789 91177308-0d34-0410-b5e6-96231b3b80d8
MaxAtomicPromoteWidth. Fix a ton of terrible bugs with
_Atomic types and (non-intrinsic-mediated) loads and stores
thereto.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176658 91177308-0d34-0410-b5e6-96231b3b80d8
operations (as opposed to storage only half/fp16).
Also add some semantic checks for OpenCL half types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173254 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
in the ABI arrangement, and leave a hook behind so that we can easily
tweak CCs on platforms that use different CCs by default for C++
instance methods.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159894 91177308-0d34-0410-b5e6-96231b3b80d8
in general (such an atomic has boolean representation) and
specifically for IR generation of __c11_atomic_init. The latter also
means actually using initialization semantics for this initialization,
rather than just creating a store.
On a related note, make sure we actually put in non-atomic-to-atomic
conversions when performing an implicit conversion sequence. IR
generation is far too kind here, but we still want the ASTs to make
sense.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154612 91177308-0d34-0410-b5e6-96231b3b80d8
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152536 91177308-0d34-0410-b5e6-96231b3b80d8
Nemanja Ivanovic