This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312794 91177308-0d34-0410-b5e6-96231b3b80d8
The clang-with-lto-ubuntu bot didn't like the new regression
test, revert while I investigate the issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312784 91177308-0d34-0410-b5e6-96231b3b80d8
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312781 91177308-0d34-0410-b5e6-96231b3b80d8
In dependent contexts we end up referencing these, so make sure they
have USRs, and have their declarations indexed. For the most part they
behave like typedefs, but we also need to worry about having multiple
using declarations with the same "name".
rdar://problem/33883650
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311053 91177308-0d34-0410-b5e6-96231b3b80d8
- Ignore decls marked as 'generated_declaration'
- Include the 'defined_in' in the USR for additional namespacing
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300949 91177308-0d34-0410-b5e6-96231b3b80d8
Removed ndrange_t as Clang builtin type and added
as a struct type in the OpenCL header.
Use type name to do the Sema checking in enqueue_kernel
and modify IR generation accordingly.
Review: D28058
Patch by Dmitry Borisenkov!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295311 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise we may end up creating a different USR for the definition of a function, vs its declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295191 91177308-0d34-0410-b5e6-96231b3b80d8
- Infer the right symbol kind.
- Provide a templated USR, similar to how we handle class templates.
rdar://28980398
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286154 91177308-0d34-0410-b5e6-96231b3b80d8
Part of this is to allow creating a USR for the canonical decl of that which is implicit and does
not have a source location.
rdar://28978992
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285868 91177308-0d34-0410-b5e6-96231b3b80d8
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268898 91177308-0d34-0410-b5e6-96231b3b80d8
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
Enable it for USRs and names when indexing.
Forward references can have different template argument names; including them
makes USRs and names unstable, since the name depends on whether we saw a forward reference or not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260866 91177308-0d34-0410-b5e6-96231b3b80d8
After r244870 flush() will only compare two null pointers and return,
doing nothing but wasting run time. The call is not required any more
as the stream and its SmallString are always in sync.
Thanks to David Blaikie for reviewing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244928 91177308-0d34-0410-b5e6-96231b3b80d8
clang::MacroDefinition now models the currently-defined value of a macro. The
previous MacroDefinition type, which represented a record of a macro definition
directive for a detailed preprocessing record, is now called MacroDefinitionRecord.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236400 91177308-0d34-0410-b5e6-96231b3b80d8
'class' and 'struct' can be used interchangebly for forward references.
Use the same encoding otherwise we may get into a weird situation where the USR for the same
declaration is different based on whether the definition of the tag reference is visible or not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223632 91177308-0d34-0410-b5e6-96231b3b80d8
These cases in particular were incurring an extra strlen() when we already knew
the length. They appear to be leftovers from when the interfaces worked with C
strings that have continued to compile due to the implicit StringRef ctor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210403 91177308-0d34-0410-b5e6-96231b3b80d8
- Only include offsets with local (in function scope) symbols, where we don't encode scoping
- Only include the filename with non-system symbols. Presumably the system headers will not provide conflicting definitions.
rdar://15976823
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201990 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
Sam McCall