| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Responding to Richard Smith's review of r205037.
llvm-svn: 206008
|
|
|
|
|
|
|
|
| |
No functionality change.
<rdar://problem/16435801>
llvm-svn: 206002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes a bug where unsigned numbers are read using strtol and strtoll.
I don't have a testcase because this bug is effectively unobservable
right now. To expose the problem in the hash, we would need a function
with greater than INT64_MAX counters, which we don't handle anyway. To
expose the problem in the function count, we'd need a function with
greater than INT32_MAX counters; this is theoretically observable, but
it isn't a practical testcase to check in.
An upcoming commit changes the hash to be non-trivial, so we'll get some
coverage eventually.
<rdar://problem/16435801>
llvm-svn: 206001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch by Alex Crichton!
llvm-svn: 205998
|
|
|
|
|
|
|
| |
This ensures that the overall struct size will be a multiple of 4, as
required by the ABI.
llvm-svn: 205981
|
|
|
|
|
|
|
|
| |
Emitting the PGO initialization in EmitGlobalFunctionDefinition is
inefficient, since this only has an effect once per module. We move
this to Release() with the rest of the once-per-module logic.
llvm-svn: 205977
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 205972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This allows 'half' to be printed as 'half' and not as '__fp16'.
Patch by Fraser Cormack!
llvm-svn: 205624
|
|
|
|
|
|
|
|
|
|
|
| |
If all of our weights are zero when calculating branch weights, it
means we haven't profiled the code in question. Avoid creating a
metadata node that says all branches are equally likely in this case.
The test also checks constructs that hit the other createBranchWeights
overload. These were already working.
llvm-svn: 205606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 205303
|
|
|
|
| |
llvm-svn: 205296
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
on a function.
llvm-svn: 205255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The definition of a type later in a translation unit may change it's
type from {}* to (%struct.foo*)*. Earlier function definitions may use
the former while more recent definitions might use the later. This is
fine until they interact with one another (like one calling the other).
In these cases, a bitcast is needed because the inalloca must match the
function call but the store to the lvalue which initializes the argument
slot has to match the rvalue's type.
This technique is along the same lines with what the other,
non-inalloca, codepaths perform.
This fixes PR19287.
Reviewers: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3224
llvm-svn: 205217
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the various NEON intrinsics used by
aarch64-neon-intrinsics.c (originally written for AArch64) and enables the
test.
My implementations are designed to be semantically correct, the actual code
quality looks like its a wash between the two backends, and is frequently
different (hence the large number of CHECK changes).
llvm-svn: 205210
|
|
|
|
| |
llvm-svn: 205169
|
|
|
|
| |
llvm-svn: 205167
|
|
|
|
|
|
|
| |
This also brings the code into closer conformance with usual LLVM
coding style and other surrounding conventions.
llvm-svn: 205158
|
|
|
|
| |
llvm-svn: 205104
|
|
|
|
|
|
|
|
| |
Some ABIs and C++ libraries may make different trade-offs in how RTTI
is emitted (currently with respect to visibility and so on). This
implements one scheme, as used by ARM64.
llvm-svn: 205101
|
|
|
|
|
|
|
|
|
|
|
| |
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
|
|
|
|
|
|
|
|
|
|
|
|
| |
The peculiarities of C99 create scenario where an LLVM IR function
declaration may need to be replaced with a definition baring a different
type because the prototype and definition are not required to agree.
However, we were not properly deferring this when it occurred.
This fixes PR19280.
llvm-svn: 205099
|
|
|
|
|
|
|
| |
This is part of the ARM64 patch, but can only be tested properly when
the full codegen gets committed.
llvm-svn: 205098
|
|
|
|
|
|
|
| |
This was originally part of the ARM64 patch, but seems semantically
separate.
llvm-svn: 205097
|
|
|
|
|
|
| |
Responding to Justin's review of r205025.
llvm-svn: 205037
|
|
|
|
| |
llvm-svn: 205025
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-u behaviour is apparently not portable between linkers (see cfe-commits
discussions for r204379 and r205012). I've moved the logic to IRGen,
where it should have been in the first place.
I don't have a Linux system to test this on, so it's possible this logic
*still* doesn't pull in the instrumented profiling runtime on Linux.
I'm in the process of getting tests going on the compiler-rt side
(llvm-commits "[PATCH] InstrProf: Add initial compiler-rt test"). Once
we have tests for the full flow there, the runtime logic should get a
whole lot less brittle.
<rdar://problem/16458307>
llvm-svn: 205023
|
|
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D3096
llvm-svn: 205008
|
|
|
|
|
|
|
|
|
| |
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
|
|
|
|
|
|
| |
Also, while I'm here, support -nocompress-debug-sections too.
llvm-svn: 204959
|
|
|
|
|
|
| |
for a subprogram DIE.
llvm-svn: 204949
|
|
|
|
|
|
|
| |
This produces valid IR now that llvm rejects aliases to weak aliases and warns
the user that the resolution is not changed if the weak alias is overridden.
llvm-svn: 204935
|
|
|
|
|
|
|
|
| |
while I investigate as it seems to be causing issues with the gdb bot.
This reverts commit r204874.
llvm-svn: 204896
|