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
Revert the two changes to thread CodeGenOptions into the TargetInfo allocation
and to fix the layering violation by moving CodeGenOptions into Basic.
Code Generation is arguably not particularly "basic". This addresses Richard's
post-commit review comments. This change purely does the mechanical revert and
will be followed up with an alternate approach to thread the desired information
into TargetInfo.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265806 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
This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This
fixes the layering violation introduced earlier by threading CodeGenOptions into
TargetInfo. It should also fix the modules based self-hosting builds. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265702 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r264281.
This change breaks building Chromium for iOS. We'll upload a reproducer
to the PR soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264333 91177308-0d34-0410-b5e6-96231b3b80d8
Remove an unnecessary workaround introduced in r259975. (NFC)
Now that LLVM r259973 allows replacing a temporary type with another
temporary we can rely on the original implementation.
It is possible for enums to be created as part of
their own declcontext. In this case a FwdDecl will be created
twice. This doesn't cause a problem because both FwdDecls are
entered into the ReplaceMap: finalize() will replace the first
FwdDecl with the second and then replace the second with
complete type.
Thanks to echristo for pointing this out.
# Conflicts:
# lib/CodeGen/CGDebugInfo.cpp
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261673 91177308-0d34-0410-b5e6-96231b3b80d8
Now that LLVM r259973 allows replacing a temporary type with another
temporary we can rely on the original implementation.
It is possible for enums to be created as part of
their own declcontext. In this case a FwdDecl will be created
twice. This doesn't cause a problem because both FwdDecls are
entered into the ReplaceMap: finalize() will replace the first
FwdDecl with the second and then replace the second with
complete type.
Thanks to echristo for pointing this out.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261657 91177308-0d34-0410-b5e6-96231b3b80d8
It is possible for enums to be created as part of their own
declcontext. We need to cache a placeholder to avoid the type being
created twice before hitting the cache.
<rdar://problem/24493203>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259975 91177308-0d34-0410-b5e6-96231b3b80d8
All current properties are instance properties.
This is the second patch in a series of patches to support class properties
in addition to instance properties in objective-c.
rdar://23891898
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258824 91177308-0d34-0410-b5e6-96231b3b80d8
emitted into a precompiled header to mirror the debug info emitted for
object files importing the PCH.
rdar://problem/24290667
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258555 91177308-0d34-0410-b5e6-96231b3b80d8
PCH files don't have a module signature and LLVM uses a nonzero DWO id as
an indicator for skeleton / module CUs. This change pins the DWO id for PCH
files to a known constant value.
The correct long-term solution here is to implement a module signature
that is an actual dterministic hash (at the moment module signatures are
just random nonzero numbers) and then enable this for PCH files as well.
<rdar://problem/24290667>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258507 91177308-0d34-0410-b5e6-96231b3b80d8
can be found in a module.
There are externally visible anonymous types that can be found:
typedef struct { } s; // I can be found via the typedef.
There are anonymous internal types that can be found:
namespace { struct s {}; } // I can be found by name.
rdar://problem/24199640
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258272 91177308-0d34-0410-b5e6-96231b3b80d8
Even if they exist in the module, they can't be matched with the forward
declaration in the object file.
<rdar://problem/24199640>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258251 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
After r251874, properties from class extensions no longer show up in
ObjCInterfaceDecl::properties(). Make debug info emission explicitly
look for properties in class extensions before looking at direct properties.
Also add a test that checks for this. There are three interesting cases:
1. A property is only declared in a class extension, and the @implementation
is in a different file. This used to generated a DIObjcProperty before
r251874 and does again with this fix.
2. A property is declared as readonly in the class itself and redeclared as
readwrite in a class extension. clang before r251874 put the DIObjcProperty
on the first declaration. clang after r251874 didn't emit any DIObjcProperty,
and clang with this fix puts it on the readwrite redeclaration (which is
what lookup finds). This seems like a progression.
3. Like 2, but with an @implementation in the same file. In this case,
the property debug info gets generated a second time through the ivar
from the definition. In this case, lookup and declaration code need
to agree on the line number so that the DIObjcProperty isn't emitted
twice. In this case, clang before r251874 emitted one DIObjcProperty
on the first declaration, clang with r251874 emitted one on the second
declaration, and clang with this patch still does the latter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254750 91177308-0d34-0410-b5e6-96231b3b80d8
In r253186, I changed the DIBuilder API to now take size and align
for reference types as well. This was done in preparation for upcoming
changes to the Verifier that will validate that sizes match between
DI types and IR values that are declared as having those types.
This updates clang to actually pass the information through.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253190 91177308-0d34-0410-b5e6-96231b3b80d8
A 'readonly' Objective-C property declared in the primary class can
effectively be shadowed by a 'readwrite' property declared within an
extension of that class, so long as the types and attributes of the
two property declarations are compatible.
Previously, this functionality was implemented by back-patching the
original 'readonly' property to make it 'readwrite', destroying source
information and causing some hideously redundant, incorrect
code. Simplify the implementation to express how this should actually
be modeled: as a separate property declaration in the extension that
shadows (via the name lookup rules) the declaration in the primary
class. While here, correct some broken Fix-Its, eliminate a pile of
redundant code, clean up the ARC migrator's handling of properties
declared in extensions, and fix debug info's naming of methods that
come from categories.
A wonderous side effect of doing this write is that it eliminates the
"AddedObjCPropertyInClassExtension" method from the AST mutation
listener, which in turn eliminates the last place where we rewrite
entire declarations in a chained PCH file or a module file. This
change (which fixes rdar://problem/18475765) will allow us to
eliminate the rewritten-decls logic from the serialization library,
and fixes a crash (rdar://problem/23247794) illustrated by the
test/PCH/chain-categories.m example.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251874 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for the `-fdebug-prefix-map=` option as in GCC. The syntax is
`-fdebug-prefix-map=OLD=NEW`. When compiling files from a path beginning with
OLD, change the debug info to indicate the path as start with NEW. This is
particularly helpful if you are preprocessing in one path and compiling in
another (e.g. for a build cluster with distcc).
Note that the linearity of the implementation is not as terrible as it may seem.
This is normally done once per file with an expectation that the map will be
small (1-2) entries, making this roughly linear in the number of input paths.
Addresses PR24619.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250094 91177308-0d34-0410-b5e6-96231b3b80d8
Nemanja Ivanovic