| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch attempts to fix the undefined behavior in __hash_table by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__hash_table` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 2 node types in __hash_table:
* `__hash_node_base` which contains the `__next_` pointer.
* `__hash_node` which contains `__hash_` and `__value_`.
Currently the bucket list, iterators, and `__next_` pointers store pointers to `__hash_node` even though they all need to store `__hash_node_base` pointers.
This patch makes that change by introducing a `__next_pointer` typedef which is a pointer to `__hash_node` in the current ABI and `__hash_node_base` afterwards.
One notable change is to the type of `__bucket_list` which used to be defined as `unique_ptr<__node_pointer[], ...>` and is now `unique_ptr<__next_pointer[], ...>` meaning that we now allocate and deallocate different types using a different allocator. I'm going to give this part of the change more thought since it may introduce compatibility issues.
This change is similar to D20786.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D20787
llvm-svn: 276533
|
| |
|
|
|
|
|
|
| |
that Pygment does not handle "token" or "none" yet, and this caused the documentation bot to go red.
Patch by Gor Nishanov.
llvm-svn: 276532
|
| |
|
|
|
|
| |
build bot (http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/11984/steps/docs-llvm-html/logs/stdio).
llvm-svn: 276531
|
| |
|
|
| |
llvm-svn: 276530
|
| |
|
|
|
|
|
| |
As agreed with Daniel Sanders, I'm taking over as code owner
for the MIPS backend.
llvm-svn: 276529
|
| |
|
|
| |
llvm-svn: 276528
|
| |
|
|
|
|
| |
a broadcast
llvm-svn: 276527
|
| |
|
|
|
|
| |
Demonstrate difference in codegen discussed on PR14760
llvm-svn: 276526
|
| |
|
|
|
|
| |
I don't think this typedef contributes to readability.
llvm-svn: 276525
|
| |
|
|
| |
llvm-svn: 276524
|
| |
|
|
| |
llvm-svn: 276523
|
| |
|
|
|
|
|
| |
should fix the build with GCC 4.9 at least. Not sure if this is the
right name or fix, but I've followed up on the original commit.
llvm-svn: 276522
|
| |
|
|
| |
llvm-svn: 276521
|
| |
|
|
|
|
| |
just to get the IsIntrisic flag, instead get it during the first call and pass it along. NFC
llvm-svn: 276520
|
| |
|
|
| |
llvm-svn: 276519
|
| |
|
|
|
|
| |
This has been dead since r269479
llvm-svn: 276518
|
| |
|
|
|
|
|
|
| |
Patch by Jake VanAdrighem
Differential Revision: http://reviews.llvm.org/D22608
llvm-svn: 276517
|
| |
|
|
|
|
|
|
| |
Patch by Jake VanAdrighem
Differential Revision: http://reviews.llvm.org/D22607
llvm-svn: 276516
|
| |
|
|
|
|
|
|
|
|
| |
This unblocks the new PM part of River's patch in
https://reviews.llvm.org/D22706
Conveniently, this same change was needed for D21921 and so these
changes are just spun out from there.
llvm-svn: 276515
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
literal-type in C++1z
Additionally, for pre-C++1z, instead of forbidding a lambda's closure type from being a literal type through circumlocutorily setting HasNonLiteralTypeFieldsOrBases falsely to true -- handle lambda's more directly in CXXRecordDecl::isLiteral().
One additional small step towards implementing constexpr-lambdas.
Thanks to Richard Smith for his review!
https://reviews.llvm.org/D22662
llvm-svn: 276514
|
| |
|
|
|
|
|
|
|
|
|
| |
This is the first patch in the coroutine series.
It contains the documentation for the coroutine intrinsics and their usage.
Patch by Gor Nishanov!
Differential Revision: https://reviews.llvm.org/D22603
llvm-svn: 276513
|
| |
|
|
| |
llvm-svn: 276512
|
| |
|
|
| |
llvm-svn: 276511
|
| |
|
|
|
|
|
|
|
|
|
|
| |
While we handed loads past the end of an array, we didn't handle loads
_before_ the array.
This fixes PR28062.
N.B. While the bug in the code is obvious, I am struggling to craft a
test case which is reasonable in size.
llvm-svn: 276510
|
| |
|
|
|
|
|
| |
struct a bit bigger under MSVC (this shouldn't be a big deal; we typically
allocate no more than two of these at a time, on the stack).
llvm-svn: 276509
|
| |
|
|
|
|
| |
'module' and 'import' as keywords when the flag is specified.
llvm-svn: 276508
|
| |
|
|
|
|
|
|
| |
There is a bug in Clang 3.6 and earlier that causes compile failures.
I suspect it's due to the usage of member function parameter names in the
attributes.
llvm-svn: 276507
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch uses the __attribute__((enable_if)) hack suggested by @rsmith to diagnose invalid arguments when possible.
In order to diagnose an invalid argument `m` to `f(m)` we provide an additional overload of `f` that is only enabled when `m` is invalid. When that function is enabled it uses __attribute__((unavailable)) to produce a diagnostic message.
Reviewers: mclow.lists, rsmith, jfb, EricWF
Subscribers: bcraig, jfb, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D22557
llvm-svn: 276506
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change lets us prove things like
"{X,+,10} s< 5000" implies "{X+7,+,10} does not sign overflow"
It does this by replacing replacing getConstantDifference by
computeConstantDifference (which is smarter) in
isImpliedCondOperandsViaRanges.
llvm-svn: 276505
|
| |
|
|
|
|
|
|
|
|
|
| |
It's been pointed out that arbitrarily spraying raw profiles into a
build directory is insane. Doing this wastes a tremendous amount of
space and is also very lossy, since the test harness tends to wipe away
temporary sub-directories (which usually contain relevant profile data).
The new default is a `profiles` directory inside of the build dir.
llvm-svn: 276504
|
| |
|
|
|
|
|
| |
This is in preparation of
s/getConstantDifference/computeConstantDifference/ in a later change.
llvm-svn: 276503
|
| |
|
|
| |
llvm-svn: 276502
|
| |
|
|
| |
llvm-svn: 276501
|
| |
|
|
| |
llvm-svn: 276500
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Only around 50% of the intrinsics in this file are documented now. The patches for the rest of the intrisics in this file will be send out later.
The doxygen comments are automatically generated based on Sony's intrinsics docu
ment.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream. This patch was internally reviewed by Paul Robinson.
llvm-svn: 276499
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r276298.
Data stored in .rodata can have a negative offset from .text, but we
don't support negative values in relocations yet.
This caused a regression in one of the amp conformance tests:
5_Data_Cont/5_2_a_v/5_2_3_m/Assignment/Test.02.01
llvm-svn: 276498
|
| |
|
|
|
|
|
| |
This implementation was ported from the AMD builtin library
and has been tested with piglit, OpenCV, and the ocl conformance tests.
llvm-svn: 276497
|
| |
|
|
|
|
|
| |
This implementation was ported from the AMD builtin library
and has been tested with piglit, OpenCV, and the ocl conformance tests.
llvm-svn: 276496
|
| |
|
|
| |
llvm-svn: 276495
|
| |
|
|
| |
llvm-svn: 276494
|
| |
|
|
|
|
| |
To test that online merging is enabled by default.
llvm-svn: 276493
|
| |
|
|
|
|
|
|
|
|
|
| |
decomposition declarations.
There are a couple of things in the wording that seem strange here:
decomposition declarations are permitted at namespace scope (which we partially
support here) and they are permitted as the declaration in a template (which we
reject).
llvm-svn: 276492
|
| |
|
|
| |
llvm-svn: 276491
|
| |
|
|
|
|
|
|
|
|
|
|
| |
memmove/memcpy overlap detection on windows"
This currently fails ~500 tests on Darwin:
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/20456/
This reverts commit 4cfee0dff1facb8fa2827d25c5943bfef96d1a8f and
dbd91205d578cb61ab77be06087e9f65ba8a7ec8.
llvm-svn: 276490
|
| |
|
|
| |
llvm-svn: 276488
|
| |
|
|
| |
llvm-svn: 276487
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teaches FunctionInfo about offsets.
Like the last patch, this one doesn't introduce any visible
functionality change (the core algorithm knows nothing about offsets;
they're just plumbed through). Tests will come when we start acting
differently because of the offsets.
Patch by Jia Chen.
(N.B. I made a tiny change to Jia's patch to avoid warnings by GCC: I
put DenseMapInfo specializations in the `llvm` namespace. Only realized
that those appeared when compiling locally. :) )
Differential Revision: https://reviews.llvm.org/D22634
llvm-svn: 276486
|
| |
|
|
| |
llvm-svn: 276485
|
| |
|
|
|
|
|
| |
This patch enables raw profile merging for this option which is the
new intended behavior.
llvm-svn: 276484
|
| |
|
|
| |
llvm-svn: 276482
|