21 int main() {
22 A a;
For example, here user would expect to stop at line 22, even if A's constructor leads to a call through CXXDefaultArgExpr.
This fixes ostream-defined.exp regression from gdb testsuite.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127164 91177308-0d34-0410-b5e6-96231b3b80d8
without defining them. This should be an error, but I'm paranoid about
"uses" that end up not actually requiring a definition. I'll revisit later.
Also, teach IR generation to not set internal linkage on variable
declarations, just for safety's sake. Doing so produces an invalid module
if the variable is not ultimately defined.
Also, fix several places in the test suite where we were using internal
functions without definitions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126016 91177308-0d34-0410-b5e6-96231b3b80d8
- Have CGM precompute a number of commonly-used types
- Have CGF copy that during initialization instead of recomputing them
- Use TBAA info when initializing a parameter variable
- Refactor the scalar ++/-- code
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125562 91177308-0d34-0410-b5e6-96231b3b80d8
and we later find the definition, make sure that we add the definition
(not the declaration) to the list of deferred definitions to
emit. Fixes PR8864.
Thanks to Nick Lewycky for testing this patch out
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125157 91177308-0d34-0410-b5e6-96231b3b80d8
Block{Function,Module} base class. Minor other refactorings.
Fixed a few address-space bugs while I was there.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125085 91177308-0d34-0410-b5e6-96231b3b80d8
is not defined in the current translation unit. Doing so lead to compile errors
such as PR9114.
Instead, when CodeGen is building the vtable, don't try to emit a definition
for functions that aren't marked used in the current translation unit.
Fixes PR9114.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124768 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm-link would complains about mismatched visibility
* If we produce a relocation with an available_externally, it is good to know that
it is hidden.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124633 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124565 91177308-0d34-0410-b5e6-96231b3b80d8
__builtin___CFStringMakeConstantString
This fixes PR8993. A darwin expert might want to check that this is safe.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123658 91177308-0d34-0410-b5e6-96231b3b80d8
process, perform a number of refactorings:
- Move MiscNameMangler member functions to MangleContext
- Remove GlobalDecl dependency from MangleContext
- Make MangleContext abstract and move Itanium/Microsoft functionality
to their own classes/files
- Implement ASTContext::createMangleContext and have CodeGen use it
No (intended) functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123386 91177308-0d34-0410-b5e6-96231b3b80d8
static const char foo[] = "foo";
static const char *bar = "bar";
the global created to hold "bar" will have it, but foo will not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123192 91177308-0d34-0410-b5e6-96231b3b80d8
within the class. Teach IR gen to look for function definitions in record
lexical contexts when deciding whether to emit a function whose address
was taken. Fixes PR8789.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121833 91177308-0d34-0410-b5e6-96231b3b80d8
data members by delaying the emission of the initializer until after
linkage and visibility have been set on the global. Also, don't
emit a guard unless the variable actually ends up with vague linkage,
and don't use thread-safe statics in any case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118336 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117781 91177308-0d34-0410-b5e6-96231b3b80d8
for namespace-scope variable declarations.
Apply visibility in IR gen to variables that are merely declared
and never defined. We were previously emitting these with default
visibility unless they were declared with private_extern.
Ignore global visibility settings when computing visibility for
a declaration's context, and key several conditions on whether a
visibility attribute exists anywhere in the hierarchy as opposed
to whether it exists at the current level.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117729 91177308-0d34-0410-b5e6-96231b3b80d8
and never defined. We were previously emitting these with default
visibility unless they were declared with private_extern.
Ignore global visibility settings when computing visibility for
a declaration's context, and key several conditions on whether a
visibility attribute exists anywhere in the hierarchy as opposed
to whether it exists at the current level.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117644 91177308-0d34-0410-b5e6-96231b3b80d8
on if its linkage is weak. Currently this is the
case but may change in the future. (part of radar
8562966).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117452 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117147 91177308-0d34-0410-b5e6-96231b3b80d8