|
Revision tags: release/13.4.0-p5, release/13.5.0-p1, release/14.2.0-p3, release/13.5.0, release/14.2.0-p2, release/14.1.0-p8, release/13.4.0-p4, release/14.1.0-p7, release/14.2.0-p1, release/13.4.0-p3, release/14.2.0, release/13.4.0, release/14.1.0, release/13.3.0 |
|
| #
cdc20ff6 |
| 09-Jan-2024 |
Dimitry Andric <[email protected]> |
Merge llvm-project main llvmorg-18-init-16595-g7c00a5be5cde
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-18-init-16595-g7c00a5be5cde.
Merge llvm-project main llvmorg-18-init-16595-g7c00a5be5cde
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-18-init-16595-g7c00a5be5cde.
PR: 276104 MFC after: 1 month
(cherry picked from commit 1db9f3b21e39176dd5b67cf8ac378633b172463e)
show more ...
|
| #
c9157d92 |
| 18-Dec-2023 |
Dimitry Andric <[email protected]> |
Merge llvm-project main llvmorg-18-init-15088-gd14ee76181fb
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-18-init-15088-gd14ee76181fb.
Merge llvm-project main llvmorg-18-init-15088-gd14ee76181fb
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-18-init-15088-gd14ee76181fb.
PR: 276104 MFC after: 1 month
(cherry picked from commit 5f757f3ff9144b609b3c433dfd370cc6bdc191ad)
show more ...
|
|
Revision tags: release/14.0.0 |
|
| #
271697da |
| 11-Sep-2023 |
Dimitry Andric <[email protected]> |
Merge llvm-project release/17.x llvmorg-17.0.0-rc4-10-g0176e8729ea4
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-17.0.0-rc4-10-g0176e8729ea4.
PR: 27375
Merge llvm-project release/17.x llvmorg-17.0.0-rc4-10-g0176e8729ea4
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-17.0.0-rc4-10-g0176e8729ea4.
PR: 273753 MFC after: 1 month
(cherry picked from commit 8a4dda33d67586ca2624f2a38417baa03a533a7f)
show more ...
|
| #
fe013be4 |
| 02-Sep-2023 |
Dimitry Andric <[email protected]> |
Merge llvm-project main llvmorg-17-init-19304-gd0b54bb50e51
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-17-init-19304-gd0b54bb50e51, t
Merge llvm-project main llvmorg-17-init-19304-gd0b54bb50e51
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-17-init-19304-gd0b54bb50e51, the last commit before the upstream release/17.x branch was created.
PR: 273753 MFC after: 1 month
(cherry picked from commit 06c3fb2749bda94cb5201f81ffdb8fa6c3161b2e)
show more ...
|
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0 |
|
| #
e63539f3 |
| 26-Jan-2021 |
Dimitry Andric <[email protected]> |
Fix clang assertion when compiling the devel/onetbb port
Merge commit 740a164de from llvm git (by Richard Smith):
PR46377: Fix dependence calculation for function types and typedef types.
We
Fix clang assertion when compiling the devel/onetbb port
Merge commit 740a164de from llvm git (by Richard Smith):
PR46377: Fix dependence calculation for function types and typedef types.
We previously did not treat a function type as dependent if it had a parameter pack with a non-dependent type -- such a function type depends on the arity of the pack so is dependent even though none of the parameter types is dependent. In order to properly handle this, we now treat pack expansion types as always being dependent types (depending on at least the pack arity), and always canonically being pack expansion types, even in the unusual case when the pattern is not a dependent type. This does mean that we can have canonical types that are pack expansions that contain no unexpanded packs, which is unfortunate but not inaccurate.
We also previously did not treat a typedef type as instantiation-dependent if its canonical type was not instantiation-dependent. That's wrong because instantiation-dependence is a property of the type sugar, not of the type; an instantiation-dependent type can have a non-instantiation-dependent canonical type.
Merge commit 9cf98d26e from llvm git (by Richard Smith):
PR46637: Fix handling of placeholder types in trailing-return-types.
Only permit a placeholder type in a trailing-return-type if it would also have been permitted in the decl-specifier sequence of a corresponding declaration with no trailing-return-type. The standard doesn't actually say this, but this is the only thing that makes sense.
Also fix handling of an 'auto' in a trailing-return-type in a parameter of a generic lambda. We used to crash if we saw such a thing.
Merge commit 234f51a65 from llvm git (by Richard Smith):
Don't crash if we deserialize a pack expansion type whose pattern contains no packs.
Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.
PR: 252892 Reported by: thierry MFC after: 3 days
show more ...
|
|
Revision tags: release/12.2.0, release/11.4.0 |
|
| #
c3ca3130 |
| 12-Apr-2020 |
Dimitry Andric <[email protected]> |
Merge commit 30588a739 from llvm git (by Erich Keane):
Make target features check work with ctor and dtor-
The problem was reported in PR45468, applying target features to an always_inline co
Merge commit 30588a739 from llvm git (by Erich Keane):
Make target features check work with ctor and dtor-
The problem was reported in PR45468, applying target features to an always_inline constructor/destructor runs afoul of GlobalDecl construction assert when checking for target-feature compatibility.
The core problem is fixed by using the version of the check that takes a FunctionDecl rather than the GlobalDecl. However, while writing the test, I discovered that source locations weren't properly set for this check on ctors/dtors. This patch also fixes constructors and CALLED destructors.
Unfortunately, it doesn't seem too possible to get a meaningful source location for a 'cleanup' destructor, so those are still 'frontend' level errors unfortunately. A fixme was added to the test to cover that situation.
This should fix 'Assertion failed: (!isa<CXXConstructorDecl>(D) && "Use other ctor with ctor decls!"), function Init, file /usr/src/contrib/llvm-project/clang/include/clang/AST/GlobalDecl.h, line 45' when compiling the security/botan2 port.
PR: 245550 MFC after: 6 weeks X-MFC-With: 358851
show more ...
|
| #
fc7efa1b |
| 06-Mar-2020 |
Dimitry Andric <[email protected]> |
Merge commit f75939599 from llvm git (by Erich Keane):
Reland r374450 with Richard Smith's comments and test fixed.
The behavior from the original patch has changed, since we're no longer all
Merge commit f75939599 from llvm git (by Erich Keane):
Reland r374450 with Richard Smith's comments and test fixed.
The behavior from the original patch has changed, since we're no longer allowing LLVM to just ignore the alignment. Instead, we're just assuming the maximum possible alignment.
Differential Revision: https://reviews.llvm.org/D68824
llvm-svn: 374562
This fixes 'Assertion failed: (Alignment != 0 && "Invalid Alignment"), function CreateAlignmentAssumption', when building recent versions of v8, which invoke __builtin_assume_aligned() with its alignment argument set to 4GiB or more.
Clang will now report a warning, and show the maximum possible alignment instead, e.g.:
huge-align.cpp:1:27: warning: requested alignment must be 536870912 bytes or smaller; maximum alignment assumed [-Wbuiltin-assume-aligned-alignment] void *f(void *g) { return __builtin_assume_aligned(g, 4294967296); } ^ ~~~~~~~~~~
Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=43839 Reported by: cem MFC after: 3 days
show more ...
|
| #
0b57cec5 |
| 20-Dec-2019 |
Dimitry Andric <[email protected]> |
Move all sources from the llvm project into contrib/llvm-project.
This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That i
Move all sources from the llvm project into contrib/llvm-project.
This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together.
Updating the vendor area to match this layout is next.
show more ...
|