Empty structs are ignored for parameter passing purposes, but va_arg was
incrementing the pointer anyway which could lead to va_list getting out of
sync.
llvm-svn: 184605
According to the Itanium ABI (3.1.1), types with non-trivial copy constructors
passed by value should be passed indirectly, with the caller creating a
temporary.
We got this mostly correct, but forgot that empty structs can have non-trivial
constructors too and passed them incorrectly. This simply reverses the order of
the check.
llvm-svn: 184603
Itanium destroys them in the caller at the end of the full expression,
but MSVC destroys them in the callee. This is further complicated by
the need to emit EH-only destructor cleanups in the caller.
This should help clang compile MSVC's debug iterators more correctly.
There is still an outstanding issue in PR5064 of a memcpy emitted by the
LLVM backend, which is not correct for C++ records.
Fixes PR16226.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D929
llvm-svn: 184543
This is to make test cases looking for definitions more legible by
making the definition explicit rather than just the absence of '[fwd]'.
This allowed the debug-info-record tests to be rephrased - and in the
interests of reducing the number of individual test cases/invocations we
have, I merged them into one file, separated them with namespaces (&
then moved them to C++ because namespaces are great). If they need to
remain 'C' only tests, they can be moved back. (I didn't group them with
'debug-info-class.cpp' because these tests only apply to
-fno-limit-debug-info)
I removed the pieces of code that would cause these tests to pass under
-flimit-debug-info to ensure the tests remain relevant to their fixes
should we ever improve -flimit-debug-info to catch that kind of code.
This commit is version locked with the corresponding change to
DebugInfo.h in LLVM. Except some transient buildbot fallout.
llvm-svn: 184524
r174939-40 caused us to do this in the canonical terminate lpad,
but when the EH stack has other cleanups on it we use the
terminate handler block, which wasn't doing this.
Fixes the rest of rdar://11904428 given appropriate stdlib support.
llvm-svn: 184475
On Windows, it looks like FlagIndirectVariable is being set in Flags for
DIBuilder::createLocalVariable(), giving us an i32 of 8192 instead of 0,
as on Linux.
Fixes breakage from r184367.
llvm-svn: 184438
This is to fix the location information for such parameters to refer to
the object accessible through the pointer rather than to the pointer
parameter itself.
llvm-svn: 184367
1) Removed useless return value of CGCXXABI::EmitConstructorCall and CGCXXABI::EmitVirtualDestructorCall and implementations
2) Corrected last portion of CodeGenCXX/constructor-destructor-return-this to correctly test for non-'this'-return of virtual destructor calls
llvm-svn: 184330
In Itanium, dynamic classes have one vtable with several different
address points for dynamic base classes that can't share vtables.
In the MS C++ ABI, each vbtable that can't be shared gets its own
symbol, similar to how ctor vtables work in Itanium. However, instead
of mangling the subobject offset into the symbol, the unique portions of
the inheritance path are mangled into the symbol to make it unique.
This patch implements the MSVC 2012 scheme for forming unique vbtable
symbol names. MSVC 2010 use the same mangling with a different subset
of the path. Implementing that mangling and possibly others is TODO.
Each vbtable is an array of i32 offsets from the vbptr that points to it
to another virtual base subobject. The first entry of a vbtable always
points to the base of the current subobject, implying that it is the
same no matter which parent class contains it.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D636
llvm-svn: 184309
The backend will now use the generic 'returned' attribute to form tail calls where possible, as well as avoid save-restores of 'this' in some cases (specifically the cases that matter for the ARM C++ ABI).
This patch also reverts a prior front-end only partial implementation of these optimizations, since it's no longer required.
llvm-svn: 184205
the result of a cast-to-reference-type lifetime-extends the object to which the
reference inside the cast binds.
This requires us to look for subobject adjustments on both the inside and the
outside of the MaterializeTemporaryExpr when looking for a temporary to
lifetime-extend (which we also need for core issue 616, and possibly 1213).
llvm-svn: 184024
Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).
This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.
llvm-svn: 183872
were lacking ExprWithCleanups nodes in some cases where the new approach to
lifetime extension needed them).
Original commit message:
Rework IR emission for lifetime-extended temporaries. Instead of trying to walk
into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.
We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.
llvm-svn: 183859
into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.
We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.
llvm-svn: 183721
Two variables with the same name declared in two if conditions in the same
scope are no longer coalesced into one.
rdar://problem/14024005
llvm-svn: 183597
There seems to have been some erroneous code attempting to describe the
ABI of parameters (non-trivial record parameters are passed by
reference). This would break the type of the function (especially when
it caused a mismatch between the type of a declaration & a definition)
causing PR14763 and PR14645.
llvm-svn: 183329
Also addresses a review comment from John from on r180985 by removing
the "== -1" check, since it's now reusing the correct code which has the
comment.
llvm-svn: 183318
In an effort to make -flimit-debug-info more consistent I over-shot the
mark & made types used via typedefs never produce definitions in the
debug info (even if the type was used in a way that would require a
definition).
The fix for this is to do exactly what I was hoping to do at some point
- plumb the declaration/definition choice through the various layers of
"CreateType" in CGDebugInfo. In this way we can produce declarations
whenever they are sufficient & definitions otherwise - including when
qualifiers are used, for example (discovered in PR14467). This may not
be complete (there may be other types/situations where we need to
propagate the "declaration/definition" choice) but it lays the basic
foundation which we can enhance in future iterations.
llvm-svn: 183296
handle temporaries which have been lifetime-extended to static storage duration
within constant expressions. This correctly handles nested lifetime extension
(through reference members of aggregates in aggregate initializers) but
non-constant-expression emission hasn't yet been updated to do the same.
llvm-svn: 183283
Template functions (and member functions of class templates) present the same
problem as inline functions. They need to be uniqued, so we need to assign
VisibleNoLinkage linkage to types defined in them.
llvm-svn: 183222
which is lifetime-extended by a reference binding. An additional temporary is
created for such a bitfield access (although we have no explicit AST
representation for it).
llvm-svn: 183095
clang would incorrectly not allow the following:
int x = true ? (throw 1) : 2;
The problem exists because we don't see beyond the parens.
This, in turn, causes us to believe that we are choosing between void
and int which we diagnose as an error.
Instead, allow clang to see the 'throw' inside the parens.
llvm-svn: 183085
syntactic form in template instantiation. Previously, this blocked the
reversion and we ended up losing inner CXXBindTemporaryExprs (and thus
forgetting to call destructors!).
llvm-svn: 182969
While we can't yet emit vbtables, this allows us to find virtual bases
of objects constructed in other TUs.
This make iostream hello world work, since basic_ostream virtually
inherits from basic_ios.
Differential Revision: http://llvm-reviews.chandlerc.com/D795
llvm-svn: 182870
MSVC's class data is always comdat, so clang's should always be
linkonce_odr in LLVM IR.
Reviewers: pcc
Differential Revision: http://llvm-reviews.chandlerc.com/D838
llvm-svn: 182865
John noticed that the fix for pr15930 (r181981) didn't handle indirect
uses of local types. For example, a pointer to local struct, or a
function that returns it.
One way to implement this would be to recursively look for local
types. This would look a lot like the linkage computation itself for
types.
To avoid code duplication and utilize the existing linkage cache, this
patch just makes the computation of "type with no linkage but
externally visible because it is from an inline function" part of the
linkage computation itself.
llvm-svn: 182711
Perhaps we should just suppress this, rather than erroring, but since we
have the infrastructure for it I figured I'd use it - if this is
determined to be not the right thing we should probably remove that
infrastructure entirely. I guess it's lying around from the early days
of implementing debug info support.
llvm-svn: 182673
This resolves the last of the PR14606 failures in the GDB 7.5 test
suite. (but there are still unresolved issues in the imported_decl case
- we need to implement optional/lazy decls for functions & variables
like we already do for types)
llvm-svn: 182329
This reverts commit r181947 (git d2990ce56a16050cac0d7937ec9919ff54c6df62 )
This addresses one of the two issues identified in r181947, ensuring
that types imported via using declarations only result in a declaration
being emitted for the type, not a definition. The second issue (emitting
using declarations that are unused) is hopefully an acceptable increase
as the real fix for this would be a bit difficult (probably at best we
could record which using directives were involved in lookups - but may
not have been the result of the lookup).
This also ensures that DW_TAG_imported_declarations (& directives) are
not emitted in line-tables-only mode as well as ensuring that typedefs
only require/emit declarations (rather than definitions) for referenced
types.
llvm-svn: 182231
In the case of inline functions, we have to special case local types
when they are used as template arguments to make sure the template
instantiations are still uniqued in case the function itself is inlined.
llvm-svn: 181981
This reverts commit r181393 (git 3923d6a87fe7b2c91cc4a7dbd90c4ec7e2316bcd).
This seems to be emitting too much extra debug info for two (known)
reasons:
* full class definitions are emitted when only declarations are expected
* unused using declarations still produce DW_TAG_imported_declarations
llvm-svn: 181947
Most of the complexity of this patch is figuring out which types get the
qualifier and which don't. If we implement __ptr32/64, then we should
check the qualifier instead of assuming all pointers are 64-bit.
This fixes PR13792.
Patch by Warren Hunt!
llvm-svn: 181825
We might benefit from API refactoring here (why pass in a value that's
derived from another parameter?) but this is the immediate issue.
llvm-svn: 181747
Generalize some attributes that differ on powerpc64 (i32 vs signext i32). Also
fix some copy-and-pasted code that didn't get updated properly.
llvm-svn: 181707
type returns a lambda defined within itself. The computation of linkage for the
function looked at the linkage of the lambda, and vice versa.
This is solved by not checking whether an 'auto' in a function return type
deduces to a type with unique external linkage. We don't need this check,
because the type deduced for 'auto' doesn't affect whether two
otherwise-identical declarations would name different functions, so we don't
need to give an ostensibly external-linkage function internal linkage for this
reason. (We also don't need unique-external linkage in C++11 onwards at all,
but that's not implemented yet.)
llvm-svn: 181675
We could support the GCC extension DW_TAG_GNU_template_parameter_pack if
we're feeling adventurous, at some point - but I don't think GDB's doing
anything useful with it yet anyway.
llvm-svn: 181644
* Provide DW_TAG_template_value_parameter for pointers, function
pointers, member pointers, and member function pointers (still missing
support for template template parameters which GCC encodes as a
DW_TAG_GNU_template_template_param)
* Provide values for all but the (member & non-member) function pointer case.
Simple constant integer values for member pointers (offset within the
object) and address for the value pointer case. GCC doesn't provide a
value for the member function pointer case so I'm not sure how, if at
all, GDB supports encoding that. & non-member function pointers should
follow shortly in a subsequent patch.
* Null pointer value encodings of all of these types, including
correctly encoding null data member pointers as -1.
llvm-svn: 181634
for C++ constructors.
If the DIType for a class was generated by
CGDebugInfo::createContextChain(), the cache contains only a
limited DIType wihtout any declarations. Since EmitFunctionStart()
needs to find the canonical declaration for each method, we
construct the complete type before emitting any method.
rdar://problem/13116508
llvm-svn: 181561
This fixes several (7 out of 16) cases of PR14492 in the GDB 7.5 test
suite. It seems GDB was bailing out whenever it had even the slightest
problem with the template argument list (& I assume it didn't like
seeing template value parameters that were just simple names - perhaps
assuming that lone names must be types, not values)
llvm-svn: 181556
Both these tests were ultimately fixed by the check for
"isIncompleteType" & neither test case was really reduced to a minimal
form. On doing so it becomes apparent that the problem wasn't specific
to templates at all, so I've moved the test case to a more appropriate
test file and added FileCheck verification to it (to show the forward
declaration of the array element type as well as the array alignment and
size being 0 since it cannot be computed). That's about as far down this
rabbithole as I'm willing to go today, so the rest of the un-FileChecked
tests in test/CodeGenCXX/debug-info.cpp will have to go another day
without actually testing anything other than the fact that they don't
crash.
& improve the actually interesting test case in
test/CodeGenCXX/debug-info-templates.cpp which was my original goal (in
preparation for expanding it/fixing some related bugs in non-type
template parameters)
llvm-svn: 181552
Summary:
This only supports converting along non-virtual inheritance paths by
changing the field offset or the non-virtual base adjustment.
This implements three kinds of conversions:
- codegen for Value conversions
- Constant emission for APValue
- Constant folding for CastExprs
In almost all constant initialization settings
EmitMemberPointer(APValue) is called, except when the expression
contains a reinterpret cast.
reinterpret casts end up being a big corner case because the null value
changes between different kinds of member pointers.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D741
llvm-svn: 181543
EmitCapturedStmt creates a captured struct containing all of the captured
variables, and then emits a call to the outlined function. This is similar in
principle to EmitBlockLiteral.
GenerateCapturedFunction actually produces the outlined function. It is based
on GenerateBlockFunction, but is much simpler. The function type is determined
by the parameters that are in the CapturedDecl.
Some changes have been added to this patch that were reviewed as part of the
serialization patch and moving the parameters to the captured decl.
Differential Revision: http://llvm-reviews.chandlerc.com/D640
llvm-svn: 181536
object x, x's subobjects can be constructed by constexpr constructor even if
they are of non-literal type, and can be read and written even though they're
not members of a constexpr object or temporary.
llvm-svn: 181506
Basic support is implemented here - it still doesn't account for
declared-but-not-defined variables or functions. It cannot handle out of
order (declared, 'using', then defined) cases for variables, but can
handle that for functions (& can handle declared, 'using'd, and not
defined at all cases for types).
llvm-svn: 181393
unnamed bitfields.
Unnamed bitfields won't have an explicit copy operation
in the AST, which breaks the strong form of the invariant.
rdar://13816940
llvm-svn: 181289
Un-break the gdb buildbot.
- Use the debug location of the return expression for the cleanup code
if the return expression is trivially evaluatable, regardless of the
number of stop points in the function.
- Ensure that any EH code in the cleanup still gets the line number of
the closing } of the lexical scope.
- Added a testcase with EH in the cleanup.
rdar://problem/13442648
llvm-svn: 181056
Without any conversion, this is pretty straightforward. Most of the
fields can be zeros. The order is:
- field offset or pointer
- nonvirtual adjustment (for MI functions)
- vbptr offset (for unspecified)
- virtual adjustment offset (for virtual inheritance)
Differential Revision: http://llvm-reviews.chandlerc.com/D699
llvm-svn: 180985
- Use the debug location of the return expression for the cleanup code
if the return expression is trivially evaluatable, regardless of the
number of stop points in the function.
- Ensure that any EH code in the cleanup still gets the line number of
the closing } of the lexical scope.
- Added a testcase with EH in the cleanup.
rdar://problem/13442648
llvm-svn: 180982
After some discussion, it was decided to use the Itanium ABI for thread_local on
Darwin OS X platforms. This involved a couple of changes. First, we use
"_tlv_atexit" instead of "__cxa_thread_atexit". Secondly, the global variables
are marked with 'internal' linkage, because we want all access to be calls to
the Itanium-specific entry point, which has normal linkage.
<rdar://problem/13733006>
llvm-svn: 180941
Original commit message:
Emit the TLS intialization functions into a list.
Add the TLS initialization functions to a list of initialization functions. The
back-end takes this list and places the function pointers into the correct
section. This way they're called before `main().'
<rdar://problem/13733006>
llvm-svn: 180809
Summary:
Like Itanium, comparisons are basically bitwise comparisons of the two
values, with an exception for null member function pointers. If two
function pointers are null, only the function pointer field matters for
comparison purposes. The rest of the bits can be arbitrary. We take
advantage of this in isZeroInitializable(), and it may matter once we
start emitting conversions.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D695
llvm-svn: 180800
Add the TLS initialization functions to a list of initialization functions. The
back-end takes this list and places the function pointers into the correct
section. This way they're called before `main().'
<rdar://problem/13733006>
llvm-svn: 180739
This includes the following fixes:
- Implement 4 subtly different variants of qualifier mangling and use them
in what I believe are the right places.
- Fix handling of array types. Previously we were always decaying them,
which is wrong if the type appears as a template argument, pointee,
referent etc.
Fixes PR13182.
Differential Revision: http://llvm-reviews.chandlerc.com/D709
llvm-svn: 180250
Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in
CXXCtorInitializers and in InitListExprs to represent a default initializer.
There's an additional complication here: because the default initializer can
refer to the initialized object via its 'this' pointer, we need to make sure
that 'this' points to the right thing within the evaluation.
llvm-svn: 179958
Also,
- abstract out the indirect/in memory/in registers decisions into the CGCXXABI
- fix handling of empty struct arguments for '-cxx-abi microsoft'
- add/fix tests
llvm-svn: 179681
non-constant constructors or non-trivial destructors. Plus bugfixes for
thread_local references bound to temporaries (the temporaries themselves are
lifetime-extended to become thread_local), and the corresponding case for
std::initializer_list.
llvm-svn: 179496
Summary:
Handles all inheritance models for both data and function member
pointers.
Also implements isZeroInitializable() and refactors some of the null
member pointer code.
MSVC supports converting member pointers through virtual bases, which
clang does not (yet?) support. Implementing that extension is covered
by http://llvm.org/15713
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D613
llvm-svn: 179305
linkage specification, and is marked as __attribute__((used)), try to also give
it the unmangled name (by emitting an internal linkage alias) if nothing else
within the translation unit would use that name. This allows inline asm in that
translation unit to use the entity via its unmangled name, which people
apparently rely on.
llvm-svn: 178950
This reverts commit r178497 since the backend has been fixed.
Also add a test to ensure that we're emitting template information for unions.
llvm-svn: 178587
when we actually end a lexical block.
* Added new test for line table / block cleanup.
* Follow-up to r177819 / rdar://problem/13115369
llvm-svn: 178490
* Store the .block_descriptor (instead of self) in the alloca so we
can guarantee that all captured variables are available at -O0.
* Add the missing OpDeref for the alloca.
rdar://problem/12767564
llvm-svn: 178361
This reverts commit 5035c483b7fcbf0fa2a7afba24fa35a10995d195.
This schema change wasn't necessary after all. I'm going ith a different
solution that will hopefully use space more conservatively.
llvm-svn: 178213
Summary:
The only vector types a user can pass from MSVC code to clang code are
the ones from *mmintrin.h, so we only have to match the MSVC mangling
for these types. MSVC mangles the __m128 family of types as tag types,
which we match. For other vector types, we emit a unique tag type
mangling that won't match anything produced by MSVC.
Reviewers: rjmccall
CC: chandlerc, timurrrr, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D576
llvm-svn: 178036
Summary:
For non-dynamic classes (no virtual bases), member data pointers are
simple offsets from the base of the record. Dynamic classes use an
aggregate for member data pointers and are therefore currently
unsupported.
Unlike Itanium, the ms ABI uses 0 to represent null for polymorphic
classes. Non-polymorphic classes use -1 like Itanium, since 0 is a
valid field offset.
Reviewers: rjmccall
CC: timurrrr, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D558
llvm-svn: 177753
picking up cleanups from earlier in the statement. Also fix a
crash-on-invalid where a reference to an invalid decl from an
enclosing scope was causing an expression to fail to build, but
only *after* a cleanup was registered from that statement,
causing an assertion downstream.
The crash-on-valid is rdar://13459289.
llvm-svn: 177692
This isn't necessary & with the next change to LLVM the DW_TAG_file_type entry
won't be emitted at all - only the raw filename/directory pair, so match on
that directly instead.
llvm-svn: 177609
The #line directive is mostly for backend testing (keeping these files matching
should simplify maintenance somewhat) though the corresponding backend test
improvement/update doesn't verify the file information directly just yet.
Coming in a later iteration.
llvm-svn: 177559
For constructors/desctructors that return 'this', if there exists a callsite
that returns 'this' and is immediately before the return instruction, make
sure we are using the return value from the callsite.
We don't need to keep 'this' alive through the callsite. It also enables
optimizations in the backend, such as tail call optimization.
Updated from r177211.
rdar://12818789
llvm-svn: 177541
Mostly, try to depend on the annotation comments more so these tests are more
legible, brief, and agnostic to schema changes in the future (sure, they're not
agnostic to changes to the comment annotations but since they're easier to read
they should be easier to update if that happens).
llvm-svn: 177457
Checking for the annotation comment rather than the metadata values makes these
tests resilient to a coming refactor that will pull these fields out into a
separate metadata node.
llvm-svn: 177237
For constructors/desctructors that return 'this', if there exists a callsite
that returns 'this' and is immediately before the return instruction, make
sure we are using the return value from the callsite.
We don't need to keep 'this' alive through the callsite. It also enables
optimizations in the backend, such as tail call optimization.
rdar://12818789
llvm-svn: 177211
the balance between expected behavior and compatibility with the gdb
testsuite.
(GDB gets confused if we break an expression into multiple debug
stmts so we enable this behavior only for inlined functions. For the
full experience people can still use -gcolumn-info.)
llvm-svn: 177164
This fixes a crash in
namespace {
struct X {};
}
extern "C" X test2_b;
X test2_b
before we would assign different linkages to each of the test2_b decls.
llvm-svn: 176869
field to be memcpy'd, rather instead of ASTContext::getTypeAlign(<Field Type>).
For packed structs the alignment of a field may be less than the alignment of
the field's type.
<rdar://problem/13338585>
llvm-svn: 176512
[[noreturn]] function are not required to also be [[noreturn]]. We still emit
calls to virtual __attribute__((noreturn)) functions as noreturn; unlike GCC,
we do require overriders to also be noreturn for that attribute.
llvm-svn: 176476
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
llvm-svn: 176286
Since r175326 an implicitly hidden template argument can cause a template
installation to become hidden, even if the template itself has an explicit
default visibility. This requires that we keep track of "late" additions
of the visibility attribute.
This is hopefully the last followup change. It just removes the caching of
visibilities from types so that we can see new attributes even after a type has
been used.
llvm-svn: 176164
bitfield. CGBitField::StorageAlignment holds the alignment in chars, but
emitMemcpy had been treating it as if it were held in bits, leading to
underaligned memcpys.
Related to PR15348.
Thanks very much to Chandler for the diagnosis.
llvm-svn: 176163
Now that implicitly hidden template arguments can make an instantiation hidden,
it is important to look at more than just the canonical decl of the argument
in order to see if an attribute is available in a more recent decl.
This has the disadvantage of exposing when getExplicitVisibility is called,
but lets us handle cases like
template <typename T>
struct __attribute__((visibility("default"))) barT {
static void zed() {}
};
class foo;
class __attribute__((visibility("default"))) foo;
template struct barT<foo>;
llvm-svn: 176112
GCC applies a pragma weak to a decl if it matches the mangled name. We used
to apply if it matched the plain name.
This patch is a compromise: we apply the pragma only if it matches the name
and the decl has C language linkage.
llvm-svn: 176110
Weather we should give C language linkage to functions and variables with
internal linkage probably depends on how much code assumes it. The standard
says they should have no language linkage, but gcc and msvc assign them
C language linkage.
This commit removes the hack that was preventing the mangling on static
functions declare in extern C contexts. It is an experiment to see if we
can implement the rules in the standard.
If it turns out that many users depend on these functions and variables
having C language linkage, we should change isExternC instead and try
to convince the CWG to change the standard.
llvm-svn: 175937
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.
Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.
The type_visibility work is rdar://11880378
llvm-svn: 175587
We treat this as an alternative to -fvisibility=<?>
which changes the default value visibility to "hidden"
and the default type visibility to "default".
Expose a -cc1 option for changing the default type
visibility, repurposing -fvisibility as the default
value visibility option (also setting type visibility
from it in the absence of a specific option).
rdar://13079314
llvm-svn: 175480
bitfield related issues.
The original commit broke Takumi's builder. The bug was caused by bitfield sizes
being determined by their underlying type, rather than the field info. A similar
issue with bitfield alignments showed up on closer testing. Both have been fixed
in this patch.
llvm-svn: 175389
linkonce_odr. Emit construction vtables as internal in this case, since the ABI
does not guarantee that they will be availble externally.
llvm-svn: 175330
for distinguishing type vs. value visibility.
The changes to the visibility of explicit specializations
are intentional. The change to the "ugly" test case is
a consequence of a sensible implementation, and I am happy
to argue that this is better behavior. Other changes may
or may not be intended; it is quite difficult to divine
intent from some of the code I altered.
I've left behind a comment which I hope explains the
philosophy behind visibility computation.
llvm-svn: 175326
some cases where functions with no language linkage were being treated as having
C language linkage. In particular, don't warn in
extern "C" {
static NonPod foo();
}
Since getLanguageLinkage checks the language linkage, the linkage computation
cannot use the language linkage. Break the loop by checking just the context
in the linkage computation.
llvm-svn: 175117
David Blaikie