| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
ConvertType on InitListExprs as they are being converted. This is
needed for a forthcoming patch, and improves the IR generated anyway
(see additional type names in testcases).
This patch also converts a bunch of std::vector's in CGObjCMac to use
C arrays. There are a ton more that should be converted as well.
llvm-svn: 133413
|
|
|
|
|
|
|
|
|
|
|
| |
bound
member function, i.e. something of the form 'x.f' where 'f' is a non-static
member function. Diagnose this in the general case. Some of the new diagnostics
are probably worse than the old ones, but we now get this right much more
universally, and there's certainly room for improvement in the diagnostics.
llvm-svn: 130239
|
|
|
|
|
|
| |
the base offset. No change in functionality intended.
llvm-svn: 129179
|
|
|
|
|
|
|
| |
Change the return type of CodeGenVTables::getVirtualBaseOffsetOffset() to
CharUnits. No change in functionality intended.
llvm-svn: 129072
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is that you can create a VarDecl with an unknown type, or a
FunctionDecl with an unknown return type, and it will still be valid to
access that object as long as you explicitly cast it at every use. I'm
still going back and forth about how I want to test this effectively, but
I wanted to go ahead and provide a skeletal implementation for the LLDB
folks' benefit and because it also improves some diagnostic goodness for
placeholder expressions.
llvm-svn: 129065
|
|
|
|
| |
llvm-svn: 128842
|
|
|
|
|
|
| |
CharUnits. No change in functionality intended.
llvm-svn: 128776
|
|
|
|
| |
llvm-svn: 127980
|
|
|
|
|
|
| |
This fixes PR 8738, 9060 and 9132.
llvm-svn: 126069
|
|
|
|
| |
llvm-svn: 125360
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
current translation unit as available_externally.
This helps devirtualize the second example in PR3100, comment 18:
struct S { S() {}; virtual void xyzzy(); };
inline void foo(S *s) { s->xyzzy(); }
void bar() { S s; foo(&s); }
This involved four major changes:
1. In DefineUsedVTables, always mark virtual member functions as referenced for
non-template classes and class template specializations.
2. In CodeGenVTables::ShouldEmitVTableInThisTU return true if optimizations are
enabled, even if the key function is not implemented in this translation
unit. We don't ever do this for code compiled with -fapple-kext, because we
don't ever want to devirtualize virtual member function calls in that case.
3. Give the correct linkage for vtables where the key function is not defined.
4. Update the linkage for RTTI structures when necessary.
llvm-svn: 124565
|
|
|
|
| |
llvm-svn: 124554
|
|
|
|
|
|
| |
data based on the explicit visibility of the type.
llvm-svn: 124553
|
|
|
|
|
|
|
|
| |
CreateOrReplaceCXXRuntimeVariable.
Set the visibility for typeinfo names.
llvm-svn: 124548
|
|
|
|
|
|
| |
instead of an "IsForRTTI" flag.
llvm-svn: 124546
|
|
|
|
|
|
| |
first get the address of the VTT, and then pass it to EmitVTTDefinition.
llvm-svn: 124539
|
|
|
|
| |
llvm-svn: 124529
|
|
|
|
|
|
| |
linkonce_odr linkage.
llvm-svn: 124096
|
|
|
|
| |
llvm-svn: 124095
|
|
|
|
|
|
|
|
| |
exception of explicit template instantiations, which have to be weak_odr.
This fixes PR6996.
llvm-svn: 124089
|
|
|
|
| |
llvm-svn: 123293
|
|
|
|
|
|
| |
think it is safe to mark all type infos with unnamed_addr, but I am not sure.
llvm-svn: 123275
|
|
|
|
|
|
|
| |
16-bits in size. Implement this by splitting WChar into two enums, like we have
for char. This fixes a miscompmilation of XULRunner, PR8856.
llvm-svn: 122558
|
|
|
|
|
|
| |
way to do this, but it fixes rdar://problem/8778973
llvm-svn: 122033
|
|
|
|
| |
llvm-svn: 118238
|
|
|
|
|
|
| |
getBaseClassOffset which returns the offset in CharUnits. Do the same thing for getVBaseClassOffset.
llvm-svn: 117881
|
|
|
|
|
|
|
|
|
|
| |
independently of whether they're definitions, then teach IR generation to
ignore non-explicit visibility when emitting declarations. Use this to
make sure that RTTI, vtables, and VTTs get the right visibility.
More of rdar://problem/8613093
llvm-svn: 117781
|
|
|
|
|
|
|
|
| |
more closely parallel the computation of linkage. This gets us to a state
much closer to what gcc emits, modulo bugs, which will undoubtedly arise in
abundance.
llvm-svn: 117147
|
|
|
|
| |
llvm-svn: 117106
|
|
|
|
|
|
| |
key function doesn't have a body.
llvm-svn: 116186
|
|
|
|
|
|
|
|
| |
conflicts
with similarly named classes in anonymous namespaces.
llvm-svn: 116185
|
|
|
|
| |
llvm-svn: 113049
|
|
|
|
|
|
| |
under the ARM ABI.
llvm-svn: 112588
|
|
|
|
| |
llvm-svn: 111768
|
|
|
|
| |
llvm-svn: 111085
|
|
|
|
|
|
|
|
| |
a -cc1 option. The Darwin linker complains about mixed visibility when linking
gcc-built objects with clang-built objects, and the optimization isn't really
that valuable. Platforms with less ornery linkers can feel free to enable this.
llvm-svn: 110979
|
|
|
|
| |
llvm-svn: 110900
|
|
|
|
|
|
| |
in the code after the "FIXME: Needs to be written".
llvm-svn: 110849
|
|
|
|
|
|
|
|
|
|
| |
Apply hidden visibility to most RTTI; libstdc++ does not rely on exact
pointer equality for the type info (just the type info names). Apply
the same optimization to RTTI that we do to vtables.
Fixes PR5962.
llvm-svn: 110192
|
|
|
|
| |
llvm-svn: 107773
|
|
|
|
|
|
| |
unqualified array type and the qualifiers from it.
llvm-svn: 105326
|
|
|
|
|
|
| |
when used by the exceptions routines. Fixes PR 6974.
llvm-svn: 102684
|
|
|
|
| |
llvm-svn: 101666
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__cxxabiv1::__fundamental_type_info in every translation
unit. Previously, we would perform name lookup for
__cxxabiv1::__fundamental_type_info at the end of IRGen for a each
translation unit, to determine whether it was present. If so, we we
produce type information for all of the fundamental types. However,
this name lookup causes PCH deserialization of a significant part of the
translation unit, which has a woeful impact on performance.
With this change, we now look at each record type after we've
generated its vtable to see if it is
__cxxabiv1::__fundamental_type_info. If so, we generate type info for
all of the fundamental types. This works because
__cxxabiv1::__fundamental_type_info should always have a key function
(typically the virtual destructor), that will be defined once in the
support library. The fundamental type information will end up there.
Fixes <rdar://problem/7840011>.
llvm-svn: 100772
|
|
|
|
|
|
|
|
| |
the existing (and already well-tested) linkage computation for types,
with minor tweaks for dynamic classes and (pointers to) incomplete
types. Fixes PR6597.
llvm-svn: 99968
|
|
|
|
|
|
|
|
| |
the typeinfo for the fundamental types.
Fixes PR6685.
llvm-svn: 99701
|
|
|
|
|
|
| |
VTableInfo class.
llvm-svn: 99250
|
|
|
|
|
|
| |
what it actually does.
llvm-svn: 98248
|
|
|
|
|
|
|
|
| |
of a C++ record. Exposed a lot of problems where various routines were
silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order)
when presented with a non-definition. Also cuts down on memory usage.
llvm-svn: 95330
|
|
|
|
|
|
|
|
| |
linkage of vtables. Before this, we were emitting RTTI names for
template instantiations with strong external linkage rather than with
weak ODR linkage.
llvm-svn: 92857
|