| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Currently clang fires assertions on x86-64 on any atomic operations for long double operands. Patch fixes codegen for such operations.
Differential Revision: http://reviews.llvm.org/D6499
llvm-svn: 224230
|
|
|
|
|
|
|
|
|
| |
Don't inherit the volatile-ness of the input pointer to the volatile
operation for memory allocated on the side.
This fixes PR17306.
llvm-svn: 224110
|
|
|
|
|
|
| |
We (wrongly) discarded the return value of the call.
llvm-svn: 222798
|
|
|
|
|
|
|
|
| |
We were being a little sloppy with our pointer/address space casts.
This fixes PR21643.
llvm-svn: 222615
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We did a great job getting this wrong:
- We messed up which LLVM IR types to use for arguments and return values.
The optimized libcalls use integer types for values.
Clang attempted to use the IR type which corresponds to the value
passed in instead of using an appropriately sized integer type. This
would result in violations of the ABI for, as an example, floating
point types.
- We didn't bother recording the result of the atomic libcall in the
destination memory.
Instead, call the functions with arguments matching the type of the
libcall prototype's parameters.
This fixes PR20780.
Differential Revision: http://reviews.llvm.org/D5098
llvm-svn: 216714
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS ABI has a notion of 'required alignment' for fields; this
alignment supercedes pragma pack directives.
MSVC takes into account alignment attributes on typedefs when
determining whether or not a field has a certain required alignment.
Do the same in clang by tracking whether or not we saw such an attribute
when calculating the type's bitwidth and alignment.
This fixes PR20418.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D4714
llvm-svn: 214274
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most builtins date from before the "cmpxchg weak" was a gleam in the
C++ committee's eye, so fortunately not much needs to change. But a
few of them *do* acknowledge that failure is possible.
For these, we'll emit the usual cartesian product of cmpxchg
operations if we can't statically determine weakness. CodeGen can
sort it out later if the function gets inlined.
The only other non-trivial aspect of this is (I think) that we emit
the scalar expression for "IsWeak" once, at the beginning, and
propagate its value through the successive blocks. There's not much in
it, but it's slightly more consistent with the existing handling of
FailureOrder.
llvm-svn: 210932
|
|
|
|
|
|
|
|
| |
This is a minimal fix for clang. I'll soon add support for generating
weak variants when requested, but that's not really necessary for the
LLVM change in isolation.
llvm-svn: 210907
|
|
|
|
| |
llvm-svn: 209272
|
|
|
|
|
|
|
|
| |
This commit fixes a cast instruction assertion failure
due to the incompatible type cast. This will only happen when
the target requires atomic libcalls.
llvm-svn: 204834
|
|
|
|
|
|
|
| |
It makes the code clearer and less error-prone to use our (already
known) special values for the various memory order cases.
llvm-svn: 203838
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes Clang take advantage of the recent IR addition of a
"failure" memory ordering requirement. As with the "success" ordering,
we try to emit just a single version if the expression is constant,
but fall back to runtime detection (to allow optimisation across
function-call boundaries).
rdar://problem/15996804
llvm-svn: 203837
|
|
|
|
|
|
|
|
|
| |
This is a conservative check, because it's valid for the expression to be
non-constant, and in cases like that we just don't know whether it's valid.
rdar://problem/16242991
llvm-svn: 203561
|
|
|
|
|
|
| |
rdar://problem/15996804
llvm-svn: 203560
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
'Expected' should only be modified if the operation fails.
This fixes PR18899.
Reviewers: chandlerc, rsmith, rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2922
llvm-svn: 203493
|
|
|
|
| |
llvm-svn: 202639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGenABITypes is a wrapper built on top of CodeGenModule that exposes
some of the functionality of CodeGenTypes (held by CodeGenModule),
specifically methods that determine the LLVM types appropriate for
function argument and return values.
I addition to CodeGenABITypes.h, CGFunctionInfo.h is introduced, and the
definitions of ABIArgInfo, RequiredArgs, and CGFunctionInfo are moved
into this new header from the private headers ABIInfo.h and CGCall.h.
Exposing this functionality is one part of making it possible for LLDB
to determine the actual ABI locations of function arguments and return
values, making it possible for it to determine this for any supported
target without hard-coding ABI knowledge in the LLDB code.
llvm-svn: 193717
|
|
|
|
|
|
| |
when scalars are loaded / undergo lvalue-to-rvalue conversion.
llvm-svn: 191808
|
|
|
|
|
|
| |
that had 80-column violations. Remove spurious emacs mode markers on .cpp files.
llvm-svn: 191797
|
|
|
|
|
|
| |
Also fixes a couple minor bugs along the way; see testcases.
llvm-svn: 186049
|
|
|
|
|
|
|
| |
I renamed the function at one point in time, but forgot to fix the
layout of the arguments.
llvm-svn: 183036
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For integer types of sizes 1, 2, 4 and 8, libcompiler-rt (and libgcc)
provide atomic functions that pass parameters by value and return
results directly.
libgcc and libcompiler-rt only provide optimized libcalls for
__atomic_fetch_*, as generic libcalls on non-integer types would make
little sense. This means that we can finally make __atomic_fetch_* work
on architectures for which we don't provide these operations as builtins
(e.g. ARM).
This should fix the dreaded "cannot compile this atomic library call
yet" error that would pop up once every while.
llvm-svn: 183033
|
|
|
|
|
|
| |
Patch by Stephen Lin!
llvm-svn: 179638
|
|
|
|
| |
llvm-svn: 179495
|
|
|
|
|
|
|
|
| |
MaxAtomicPromoteWidth. Fix a ton of terrible bugs with
_Atomic types and (non-intrinsic-mediated) loads and stores
thereto.
llvm-svn: 176658
|
|
llvm-svn: 176657
|