| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
It is possible that a variable template specialization might not have a
VisibilityAttr attached to it while the template that it specializes
does, in fact, have one.
We should consider the template in such cases.
This fixes PR19597.
llvm-svn: 207498
|
| |
|
|
|
|
|
| |
Reference temporaries inherited many properties from the variable that
they correspond to but visibility wasn't one of them.
llvm-svn: 207496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A reference temporary should inherit the linkage of the variable it
initializes. Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3515
llvm-svn: 207451
|
| |
|
|
|
|
| |
still in review.
llvm-svn: 207296
|
| |
|
|
|
|
|
|
|
|
|
| |
Prior to this patch, CGRecordLower assumed that virtual bases could not
be placed before the nvsize of an object. This isn't true in Itanium
mode, virtual bases are placed at dsize rather than vnsize and in the
case of zero sized non-virtual bases nvsize can be larger than dsize.
This patch fixes CGRecordLowering to avoid an assert and to clip
bitfields properly in this case. A test case is included.
llvm-svn: 207280
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
after we've already instantiated a definition for the function, pass it to the
ASTConsumer again so that it knows the specialization kind has changed and can
update the function's linkage.
This only matters if we instantiate the definition of the function before we
reach the end of the TU; this can happen in at least three different ways:
C++11 constexpr functions, C++14 deduced return types, and functions
instantiated within modules.
llvm-svn: 207152
|
| |
|
|
| |
llvm-svn: 207117
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Correct size_t to be unsigned int and ptrdiff_t to be signed long. The types were the correct size before this change but
the exact type matters for name mangling and exception handling in C++.
Reviewers: atanasyan
Reviewed By: atanasyan
Differential Revision: http://reviews.llvm.org/D3470
llvm-svn: 207093
|
| |
|
|
|
|
|
|
|
|
| |
We were using the same guard variable and failing to initialize the
second global.
Clang is still not MS ABI compatible in this area. Fixing that is
PR16959, which will require LLVM changes to @llvm.global_ctors.
llvm-svn: 207008
|
| |
|
|
| |
llvm-svn: 206974
|
| |
|
|
|
|
|
|
| |
Mangle ref-qualifiers like the Nov 2013 CTP.
This fixes PR19361.
llvm-svn: 206946
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We previously treated ARM separately from the generic Itanium ABI for
initializing guard variables. This code duplication led to things like
the ARM path missing the memory barrier for threadsafe handling, and a
highly misleading comment about how we were (mis)using the generic ABI
for ARM64 when really it went through the ARM codepath.
This unifies the two code paths. Functionally, this changes the ARM
and ARM64 codepath to use one byte loads instead of 4 and 8,
respectively, and adds the missing atomic acquire to these loads.
Other architectures are unchanged.
llvm-svn: 206937
|
| |
|
|
|
|
|
|
| |
overrider is present in both a vbase and nvbase
Reviewed at http://reviews.llvm.org/D3449
llvm-svn: 206908
|
| |
|
|
|
|
| |
Intentionally duplicate base class definitions per test, so it's easier to copy tests while debugging failures.
llvm-svn: 206782
|
| |
|
|
|
|
| |
Also, intentionally duplicate base class definitions per test, so it's easier to copy tests while debugging failures
llvm-svn: 206614
|
| |
|
|
|
|
|
| |
This was probably a benign bug, since nobody would look at the vbtable
slots that we were filling in.
llvm-svn: 206508
|
| |
|
|
|
|
|
|
| |
inheritance cases
Reviewed at http://reviews.llvm.org/D3410
llvm-svn: 206504
|
| |
|
|
|
|
|
|
| |
Also fix a few other vtordisp-related bugs.
Reviewed at http://reviews.llvm.org/D3400
llvm-svn: 206457
|
| |
|
|
|
|
|
|
| |
Itanium ABI in 2.9.2 Place of Emission.
Differential Revision: http://reviews.llvm.org/D2750
llvm-svn: 206439
|
| |
|
|
|
|
|
|
|
|
|
|
| |
specializations collect all arguments and not just the ones from the
class template partial specialization from which this class template
specialization was instantiated. The debug info does not represent the
partial specialization otherwise and so specialized parameters would
go missing.
rdar://problem/16636569.
llvm-svn: 206430
|
| |
|
|
|
|
| |
pass -target-feature +neon.
llvm-svn: 206394
|
| |
|
|
|
|
| |
The Ts/Tu/Te manglings should occur before the nested-name's N.
llvm-svn: 206247
|
| |
|
|
|
|
| |
DeclContext is (lexically) within a C language linkage specification.
llvm-svn: 206204
|
| |
|
|
|
|
|
|
|
| |
for CXXGlobalInit/Dtor helper functions.
This makes _GLOBAL__I_a regain its DW_AT_high/low_pc in the debug info.
Thanks to echristo for catching this!
llvm-svn: 206088
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are not associated with any source lines.
Previously, if the Location of a Decl was empty, EmitFunctionStart would
just keep using CurLoc, which would sometimes be correct (e.g., thunks)
but in other cases would just point to a hilariously random location.
This patch fixes this by completely eliminating all uses of CurLoc from
EmitFunctionStart and rather have clients explicitly pass in a
SourceLocation for the function header and the function body.
rdar://problem/14985269
llvm-svn: 205999
|
| |
|
|
|
|
|
| |
This ensures that the overall struct size will be a multiple of 4, as
required by the ABI.
llvm-svn: 205981
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sure that a debugger can find them when stepping through code,
for example from the included testcase:
12 int test_it() {
13 c = 1;
14 d = 2;
-> 15 a = 4;
16 return (c == 1);
17 }
18
(lldb) p a
(int) $0 = 2
(lldb) p c
(int) $1 = 2
(lldb) p d
(int) $2 = 2
and a, c, d are all part of the file static anonymous union:
static union {
int c;
int d;
union {
int a;
};
struct {
int b;
};
};
Fixes PR19221.
llvm-svn: 205952
|
| |
|
|
|
|
|
|
| |
If we crash, we raise a crash handler dialog, and that's really
annoying. Even though we can't emit correct IR until we have musttail,
don't crash.
llvm-svn: 205948
|
| |
|
|
|
|
|
|
|
| |
cxx-abi-dev came up with a way to disambiguate between different
keywords used in elaborated type specifiers.
This resolves certain collisions during mangling.
llvm-svn: 205943
|
| |
|
|
| |
llvm-svn: 205781
|
| |
|
|
|
|
|
|
|
|
|
| |
It is very similar to GCC's __PRETTY_FUNCTION__, except it prints the
calling convention.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D3311
llvm-svn: 205780
|
| |
|
|
|
|
|
|
| |
This can actually be non-zero if you override a function from a virtual
base and you have forced the most_general pointer to member
representation.
llvm-svn: 205727
|
| |
|
|
|
|
|
|
| |
We already got the type alias correct (though I've included a test case
here) since Clang represents that like any other typedef - but type
alias templates weren't being handled.
llvm-svn: 205691
|
| |
|
|
|
|
|
|
| |
named imported entities
Apparently that's how DWARF4 suggests they be emitted. So let's do that.
llvm-svn: 205686
|
| |
|
|
|
|
|
| |
This was reverted in 205664 and seems to be fixed by 205668... though
that may be more by accident than anything well founded.
llvm-svn: 205669
|
| |
|
|
|
|
|
|
| |
While the folding set would deduplicate the nodes themselves and LLVM
would handle not emitting the same global twice, it still meant creating
a long/redundant list of global variables.
llvm-svn: 205668
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r205655.
Breaks the compiler-rt build with an assertion failure in LLVM...
reverting while I investigate.
llvm-svn: 205664
|
| |
|
|
|
|
|
| |
We also don't need to duplicate the name in the LinkageName field. Just
leave it empty.
llvm-svn: 205655
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
See the comment for CodeGenFunction::tryEmitAsConstant that describes
how in some contexts (lambdas) we must not emit references to the
variable, but instead use the constant directly - because of this we end
up emitting a constant for the variable, as well as emitting the
variable itself.
Should we just skip putting the variable on the stack at all and omit
the debug info for the constant? It's not clear to me - what if the
address of the local is taken?
llvm-svn: 205651
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
By ignoring this pragma with a warning, we're essentially miscompiling
the user's program. WebKit / Blink use this pragma to disable dynamic
initialization and finalization of some static data, and running the
dtors crashes the program.
Error out for now, so that /fallback compiles the TU correctly with
MSVC. This pragma should be implemented some time this month, and we
can remove this hack.
llvm-svn: 205554
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MSVC always emits inline functions marked with the extern storage class
specifier. The result is something similar to the opposite of
__attribute__((gnu_inline)).
This extension is also available in C.
This fixes PR19264.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3207
llvm-svn: 205485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was committed 4 years ago in 108916 with insufficient testing to
explain why the "getTypeAsWritten" case was appropriate. Experience says
that it isn't - the presence or absence of an explicit instantiation
declaration was causing this code to generate either i<int> or i<int,
int>.
That didn't seem to be a useful distinction, and omitting the template
arguments was destructive to debuggers being able to associate the two
types across translation units or across compilers (GCC, reasonably,
never omitted the arguments).
llvm-svn: 205447
|
| |
|
|
|
|
|
|
|
|
|
|
| |
at ... )')
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
|
| |
|
|
|
|
|
|
| |
Augment the test case from r205217 to catch this related bug.
Fixes the Windows self-host which was failing on VariantValue.cpp.
llvm-svn: 205378
|
| |
|
|
| |
llvm-svn: 205370
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We don't want to encourage the code to emit a lexical block for
a function that needs one in order for the line table to change,
we need to grab the line information from the body of the pattern
that we were instantiated from, this code should do that.
Modify the test case to ensure that we're still looking in the
right place for all of the scopes and also that we haven't
created a lexical block where we didn't need one.
llvm-svn: 205368
|
| |
|
|
|
|
|
| |
previously not handled at all.
rdar://problem/16348575
llvm-svn: 205331
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS ABI forces us into catch-22 when it comes to functions which
return types which are local:
- A function is mangled with it's return type.
- A type is mangled with it's surrounding context.
Avoid this by mangling auto and decltype(autp) directly into the
function's return type. Using this mangling has the double advantage of
being compatible with the C++ standard without crashing the compiler.
N.B. For the curious, the MSVC mangling leads to collisions amongst
template functions and either crashes when faced with local types or is
otherwise incapable of returning them.
llvm-svn: 205282
|
| |
|
|
|
|
|
| |
The Decl field in a DIImportedEntity is now a DIRef.
Paired commit with LLVM.
llvm-svn: 205278
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang implements the part of the ARM ABI saying that certain functions
(e.g., constructors and destructors) return "this", but Apple's version of
gcc and llvm-gcc did not. The libstdc++ dylib on iOS 5 was built with
llvm-gcc, which means that clang cannot safely assume that code from the C++
runtime will correctly follow the ABI. It is also possible to run into this
problem when linking with other libraries built with gcc or llvm-gcc. Even
though there is no way to reliably detect that situation, it is most likely
to come up when targeting older versions of iOS. Disabling the optimization
for any code targeting iOS 5 solves the libstdc++ problem and has a reasonably
good chance of fixing the issue for other older libraries as well.
<rdar://problem/16377159>
llvm-svn: 205272
|