| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declaration (PR20792)
For the following code:
__declspec(dllimport) int f(int x);
int user(int x) {
return f(x);
}
int f(int x) { return 1; }
Clang will drop the dllimport attribute in the AST, but CodeGen would have
already put it on the LLVM::Function, and that would never get updated.
(The same thing happens for global variables.)
This makes Clang check dropped DLL attribute case each time the LLVM object
is referenced.
This isn't perfect, because we will still get it wrong if the function is
never referenced by codegen after the attribute is dropped, but this handles
the common cases and makes us not fail in the verifier.
llvm-svn: 216699
|
| |
|
|
|
|
| |
again, I have to explore runtime ABI requirements with libc++abi.
llvm-svn: 216677
|
| |
|
|
|
|
|
|
| |
linkage related to generation of OBJC_SELECTOR_REFERENCES symbol
needed in generation of call to 'super' in a class method.
// rdar://18150301
llvm-svn: 216676
|
| |
|
|
|
|
| |
constant-expression) passed to operator new[] results in overflow in conformance with [expr.new]p7. Fixes PR11644.
llvm-svn: 216675
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4368
llvm-svn: 216649
|
| |
|
|
| |
llvm-svn: 216638
|
| |
|
|
| |
llvm-svn: 216635
|
| |
|
|
| |
llvm-svn: 216585
|
| |
|
|
|
|
| |
parameters in the IR.
llvm-svn: 216574
|
| |
|
|
|
|
|
|
|
|
|
| |
ACLE 2.0 allows __fp16 to be used as a function argument or return
type. This enables this for AArch64.
This also fixes an existing bug that causes clang to not allow
homogeneous floating-point aggregates with a base type of __fp16. This
is valid for AAPCS64, but not for AAPCS-VFP.
llvm-svn: 216558
|
| |
|
|
|
|
|
|
|
| |
This tidies up some ARM-specific code added by r208417 to move it out
of the target-independent parts of clang into TargetInfo.cpp. This
also has the advantage that we can now flatten struct arguments to
variadic AAPCS functions.
llvm-svn: 216535
|
| |
|
|
|
|
| |
just letting them be implicitly created.
llvm-svn: 216528
|
| |
|
|
| |
llvm-svn: 216527
|
| |
|
|
|
|
|
|
|
| |
This time though, preserve the extension for bool types since that's compatible
with what MSVC expects.
See http://reviews.llvm.org/D4380
llvm-svn: 216507
|
| |
|
|
| |
llvm-svn: 216496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When the main file is created from a membuffer, there is no file entry that can be retrieved. This uses "__GLOBAL_I_a" in that case which is what was always used before r208128.
Reviewers: majnemer, thakis
Reviewed By: thakis
Subscribers: yaron.keren, rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D5043
llvm-svn: 216495
|
| |
|
|
| |
llvm-svn: 216493
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MSVC doesn't extend integer types smaller than 64bit, so to preserve
binary compatibility, clang shouldn't either.
For example, the following C code built with MSVC:
unsigned test(unsigned v);
unsigned foobar(unsigned short);
int main() { return test(0xffffffff) + foobar(28); }
Produces the following:
0000000000000004: B9 FF FF FF FF mov ecx,0FFFFFFFFh
0000000000000009: E8 00 00 00 00 call test
000000000000000E: 89 44 24 20 mov dword ptr [rsp+20h],eax
0000000000000012: 66 B9 1C 00 mov cx,1Ch
0000000000000016: E8 00 00 00 00 call foobar
And as you can see, when setting up the call to foobar, only cx is overwritten.
If foobar is compiled with clang, then the zero extension added by clang means
the rest of the register, which contains garbage, could be used.
For example if foobar is:
unsigned foobar(unsigned short v) {
return v;
}
Compiled with clang -fomit-frame-pointer -O3 gives the following assembly:
foobar:
0000000000000000: 89 C8 mov eax,ecx
0000000000000002: C3 ret
And that function would return garbage because the 16 most significant bits of
ecx still contain garbage from the first call.
With this change, the code for that function is now:
foobar:
0000000000000000: 0F B7 C1 movzx eax,cx
0000000000000003: C3 ret
Reviewers: chapuni, rnk
Reviewed By: rnk
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4380
llvm-svn: 216491
|
| |
|
|
| |
llvm-svn: 216489
|
| |
|
|
| |
llvm-svn: 216479
|
| |
|
|
| |
llvm-svn: 216476
|
| |
|
|
|
|
| |
flag.
llvm-svn: 216472
|
| |
|
|
| |
llvm-svn: 216467
|
| |
|
|
| |
llvm-svn: 216452
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
PR19838
When operator new[] is called and an array cookie is created
we want asan to detect buffer overflow bugs that touch the cookie.
For that we need to
a) poison the shadow for the array cookie (call __asan_poison_cxx_array_cookie).
b) ignore the legal accesses to the cookie generated by clang (add 'nosanitize' metadata)
Reviewers: timurrrr, samsonov, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4774
llvm-svn: 216434
|
| |
|
|
|
|
| |
into EmitSynthesizedCXXCopyCtorCall. No functionality change.
llvm-svn: 216410
|
| |
|
|
|
|
|
|
|
|
|
| |
into EmitCXXMemberOrOperatorCall methods. In the end we want
to make declaration visible in EmitCallArgs() method, that
would allow us to alter CodeGen depending on function/parameter
attributes.
No functionality change.
llvm-svn: 216404
|
| |
|
|
|
|
|
|
|
|
|
| |
PowerPC uses the special PPC_FP128 type for long double on Linux, which is
composed of two 64-bit doubles. The higher-order double (which contains the
overall sign) comes first, and so the __builtin_signbitl implementation
requires special handling to extract the sign bit.
Fixes PR20691.
llvm-svn: 216341
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
statement.
Similar to r215768 (which fixed the same case for while loops). To quote
r215768's commit message:
"A little test case simplification - this could be simplified further,
though there are certainly interesting connections to the if/else
construct so I'm hesitant to remove that entirely though it does appear
somewhat unrelated.
(similar fix to r215766, related to PR19864)"
llvm-svn: 216297
|
| |
|
|
|
|
| |
r216288 (which was for plain-for loop condition variables).
llvm-svn: 216291
|
| |
|
|
|
|
|
|
| |
for loops introduce two scopes - one for the outer loop variable and its
initialization, and another for the body of the loop, including any
variable declared inside the loop condition.
llvm-svn: 216288
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This refactoring introduces ClangToLLVMArgMapping class, which
encapsulates the information about the order in which function arguments listed
in CGFunctionInfo should be passed to actual LLVM IR function, such as:
1) positions of sret, if there is any
2) position of inalloca argument, if there is any
3) position of helper padding argument for each call argument
4) positions of regular argument (there can be many if it's expanded).
Simplify several related methods (ConstructAttributeList, EmitFunctionProlog
and EmitCall): now they don't have to maintain iterators over the list
of LLVM IR function arguments, dealing with all the sret/inalloca/this complexities,
and just use expected positions of LLVM IR arguments stored in ClangToLLVMArgMapping.
This may increase the running time of EmitFunctionProlog, as we have to traverse
expandable arguments twice, but in further refactoring we will be able
to speed up EmitCall by passing already calculated CallArgsToIRArgsMapping to
ConstructAttributeList, thus avoiding traversing expandable argument there.
No functionality change.
Test Plan: regression test suite
Reviewers: majnemer, rnk
Reviewed By: rnk
Subscribers: cfe-commits, rjmccall, timurrrr
Differential Revision: http://reviews.llvm.org/D4938
llvm-svn: 216251
|
| |
|
|
|
|
| |
DILexicalBlock (in favor of DILexicalBlockFile - where a default arg is used to avoid the need for API churn of those callers)
llvm-svn: 216240
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a first small step towards passing generic "Expr" instead of
ArgBeg/ArgEnd pair into EmitCallArgs() family of methods. Having "Expr" will
allow us to get the corresponding FunctionDecl and its ParmVarDecls,
thus allowing us to alter CodeGen depending on the function/parameter
attributes.
No functionality change.
Test Plan: regression test suite
Reviewers: rnk
Reviewed By: rnk
Subscribers: aemerson, cfe-commits
Differential Revision: http://reviews.llvm.org/D4915
llvm-svn: 216214
|
| |
|
|
|
|
|
|
|
|
| |
The profile data format was recently updated and the new indexing api
requires the code coverage tool to know the function's hash as well
as the function's name to get the execution counts for a function.
Differential Revision: http://reviews.llvm.org/D4995
llvm-svn: 216208
|
| |
|
|
| |
llvm-svn: 216198
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 216183
|
| |
|
|
| |
llvm-svn: 216082
|
| |
|
|
| |
llvm-svn: 216081
|
| |
|
|
|
|
|
| |
ext_vector_type's 'hi/lo' components when
used as lvalue. rdar://18031917 pr20697
llvm-svn: 215991
|
| |
|
|
| |
llvm-svn: 215980
|
| |
|
|
| |
llvm-svn: 215968
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
statement.
A little test case simplification - this could be simplified further,
though there are certainly interesting connections to the if/else
construct so I'm hesitant to remove that entirely though it does appear
somewhat unrelated.
(similar fix to r215766, related to PR19864)
llvm-svn: 215768
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loop, to the start of the loop.
This avoids debuggers stepping to strange places (like the last
statement in the loop body, or the first statement in the if).
This is not the whole answer, though - similar bugs no doubt exist in
other loops (patches to follow) and attributing exception handling code
to the correct line is also tricky (based on the previous fix to
PR19864, exception handling is still erroneously attributed to the 'if'
line).
llvm-svn: 215766
|
| |
|
|
| |
llvm-svn: 215764
|
| |
|
|
|
|
| |
They can be compared for identity.
llvm-svn: 215745
|
| |
|
|
| |
llvm-svn: 215738
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It fits better with LLVM's memory model to try to do this in the
backend. Specifically, narrowing wide loads in the backends should be
relatively straightforward and is generally valuable, whereas widening
loads tends to be very constrained.
Discussion here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140811/112581.html
This reverts commit r215614.
llvm-svn: 215648
|
| |
|
|
|
|
| |
auroraux.org is not resolving.
llvm-svn: 215644
|
| |
|
|
|
|
| |
address spaces.
llvm-svn: 215629
|