www/gitlab: fix regression by de79e0fe79131da57d98504a8871a94f75af43e9
it cause deinstallation of gitlab:
Checking integrity... done (2 conflicting)
- rubygem-anonymous_loader-0.1.3 [gitlab] conflicts with rubygem-anonymous_loader-gitlab-0.1.3 [installed] on /usr/local/lib/ruby/gems/3.4/gems/anonymous_loader-0.1.3/CHANGELOG.md
- rubygem-auth-sanitizer-0.2.3 [gitlab] conflicts with rubygem-auth-sanitizer-gitlab-0.2.3 [installed] on /usr/local/lib/ruby/gems/3.4/gems/auth-sanitizer-0.2.3/CHANGELOG.md
...
Installed packages to be REMOVED:
gitlab-ce: 19.3.0
...
[RISCV] Mark SiFive CLIC epilogue instructions as frame-destroy (#218338)
SiFive CLIC interrupt epilogue instructions were incorrectly marked as
`FrameSetup`. This commit marks the restore sequence and final stack
swap as `FrameDestroy`.
RuntimeLibcalls: Fix wrongly typed x87/fp128 long double libcalls on x86 (#216979)
The x86 and default libcall sets gated the l-suffixed long double libm
functions on OS conditions rather than the long double format. This
incorrectly provided the f80 libcalls on targets whose long double is
not x87 (Windows-MSVC, UEFI, x86_64 Android), double-provided
frexpl/ldexpl on musl, and provided the fp128 sincosl on targets using
double as long double.
Gate the l-suffixed libm math on the long double format, mirroring the
earlier AArch64 fix: x87 targets get the _f80 calls, fp128 targets the _f128
calls, and double targets neither. The compiler-rt f80 helpers (__extendxftf2,
__fixxfti, __powixf2, ...) are keyed to the x86_fp80 IR type, not the long double
format, so they stay unconditional on x86.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[flang][CodeGen] Fix element type of folded insert_on_range initializers
`GlobalOpConversion` folds a full-range `fir.insert_on_range` into a dense
constant. When the inserted value comes from a `fir.convert`, the fold reached
through the conversion and built the dense attribute from the type of the
*source* constant. For a `logical(4)` array initialized to `.true.` this
produced
llvm.mlir.constant(dense<true> : vector<32768xi1>) : !llvm.array<32768 x i32>
where the attribute element type `i1` disagrees with the result element type
`i32`. Translation to LLVM IR ignores the attribute type and uses the result
type, so the emitted global is still correct today, but the IR is malformed and
any consumer that trusts the attribute type sees the wrong element width.
Build the dense attribute from the converted element type instead. A logical
conversion normalizes its operand to a canonical 0/1 (see `ConvertOpConversion`),
so apply the same normalization here; any other mismatching conversion is left
to the regular lowering.
[2 lines not shown]
www/nginx-devel: Update to 1.31.4
*) Feature: the "proxy_protocol" directive in the stream and mail
modules now supports the PROXY protocol version 2.
*) Change: now HTTP/2 and gRPC requests to backends are always sent with
the ":authority" pseudo-header, and HTTP/1.1 requests - with the
"Host" header.
*) Bugfix: a segmentation fault might occur in a worker process if the
"select" method was used.
*) Bugfix: incomplete gRPC responses with a non-zero "Content-Length"
header line are now treated as malformed.
*) Bugfix: in binary compatibility with third-party modules using script
codes; the bug had appeared in 1.31.3.
*) Bugfix: in the ngx_http_perl_module.
[7 lines not shown]
www/nginx-devel: Update to 1.31.4
*) Feature: the "proxy_protocol" directive in the stream and mail
modules now supports the PROXY protocol version 2.
*) Change: now HTTP/2 and gRPC requests to backends are always sent with
the ":authority" pseudo-header, and HTTP/1.1 requests - with the
"Host" header.
*) Bugfix: a segmentation fault might occur in a worker process if the
"select" method was used.
*) Bugfix: incomplete gRPC responses with a non-zero "Content-Length"
header line are now treated as malformed.
*) Bugfix: in binary compatibility with third-party modules using script
codes; the bug had appeared in 1.31.3.
*) Bugfix: in the ngx_http_perl_module.
[7 lines not shown]
[VPlan] Append recipes created via builder to worklist
The previous PR appended the top most created recipe to the worklist, and this PR extends it to any other nested recipes that were created, similar to InstCombine.
This removes the header mask in a good few more places on RISC-V as measured on SPEC CPU 2017, e.g. for the following loop:
```c
long f(const int *p, const int *q, long n) {
long a = 0, b = 0;
for (long i = 0;; i++) {
if (p[i] && q[i]) { a += i; b += i; }
if (i + 1 == n) break;
}
return a + b;
}
```
Before:
[49 lines not shown]
[VPlan] Make simplifyRecipe more like InstCombine
Most combines in simplifyRecipe RAUW a value, but not all of them erase the old recipe.
Unify them and bring it in line with InstCombine by having it return a VPValue, which simplifyRecipes can then call RAUW with, and automatically erase the old recipe.
Similarly to InstCombine, combines that modify a recipe should return the same recipe.
[VPlan] Process simplifyRecipes in a worklist
This brings simplifyRecipes further in line with InstCombine, and asides from unlocking more simplifications it also helps avoid spurious test churn whenever passes are moved around simplifyRecipes.
For now just push the new recipe onto the worklist, not its users.
This uses a post order traversal so we maintain the same simplification order as before.
I've gone through and checked every simplification we do is a canonicalisation that converges, and I checked on llvm-test-suite + SPEC CPU 2017 in various configurations that we don't hit any cycles.
[VPlan] Make simplifyRecipe more like InstCombine
Most combines in simplifyRecipe RAUW a value, but not all of them erase the old recipe.
Unify them and bring it in line with InstCombine by having it return a VPValue, which simplifyRecipes can then call RAUW with, and automatically erase the old recipe.
Similarly to InstCombine, combines that modify a recipe should return the same recipe.
[cmake] Fix DIA SDK detection from VSINSTALLDIR (#218499)
The DIA SDK wasn't automatically detected after #160354, because
`if($Env{VSINSTALLDIR})` would be evaluated as
[`if(<string>)`](https://cmake.org/cmake/help/latest/command/if.html#string)
after expansion. This always evaluates to false unless it's one of the
true constants like `1` or `ON`. In turn the DIA SDK was never
automatically detected.
The current 23.1.0 RC builds are also built without it even though the
SDK should be available (e.g. `llvm-pdbutil diadump <pdb>` fails).
The fix is to use [`if(DEFINED
ENV{<name>})`](https://cmake.org/cmake/help/latest/command/if.html#defined).
(cherry picked from commit 5092c6ed44370d09e29ac43b346a1b430e38e1ff)
[clang-repl] Unlink the withdrawn partial translation unit on Undo (#213235)
`Interpreter::Undo()` cleared name lookup for a withdrawn input but left its `TranslationUnitDecl` in the redeclaration chain, so walking the chain still reached declarations the user had removed. `ASTContext::TUDecl` also still pointed at the withdrawn unit, so the next input chained onto it.
`IncrementalParser::CleanUpPTU` now rebuilds the redeclaration chain without the withdrawn unit and makes its predecessor current again, the way cling's `removeRedeclFromChain` does. This needs no new AST API — `Redeclarable` and `ASTContext` already declare `friend class IncrementalParser`. The declarations stay bump-allocated in the `ASTContext`; they just stop being reachable, which is what the removed `// FIXME: We should de-allocate MostRecentTU` asked for.
`CleanUpPTU` also runs on the parse-failure path, so a failed input no longer leaves its unit in the chain either.
Fixes #213230.
---------
Co-authored-by: Emery Conrad <emery.conrad at chicagotrading.com>
(cherry picked from commit 77229133dabed0b927748f2a5ae1442b0e97f686)
[AMDGPU] Combine redundant ballot intrinsic calls
Suppose there is a loop where there is a call to @llvm.amdgcn.ballot,
which maps to an instruction involving the exec mask as an operand. This
instruction duplicates if the loop is unrolled. With a higher number of
unrolled iterations, the code bloats with such redundant instructions
with $exec as there is no middle-end/backend pass which could combine
such instructions in a uniform CFG.
This patch introduces a transform in AMDGPUUniformIntrinsicCombine to
combine redundant calls to @llvm.amdgcn.ballot, to mitigate this issue.
The approach is to walk over the dominator tree and collect all calls to
@llvm.amdgcn.ballot. Map the result type and condition to the calls, to
avoid combining calls of different kinds. Calls A and B can be combined
into A iff:
- A and B are identical
- A dominates B
- all paths from A to B are uniform and exec-invariant.
[2 lines not shown]
[flang] Fix POSIX.1/XPG checks in intrinsics-library.cpp (#201072)
PR #201063 breaks the `flang` build on Solaris:
```
flang/lib/Evaluate/intrinsics-library.cpp:225:26: error: address of overloaded function 'acos' does not match required type '__float128 (__float128)'
flang/lib/Evaluate/intrinsics-library.cpp:225:26: error: address of overloaded function 'acos' does not match required type '_Complex __float128 (_Complex __float128)'
```
There are two problems here:
- The `__float128` support in `intrinsics-library.cpp` is guarded by the
POSIX.1 >= 2001/XPG >= 6 check, but only depends on `HAVE_QUADMATHLIB`.
- That check is done incorrectly: it tests for `_POSIX_C_SOURCE >=
200112L` or `_XOPEN_SOURCE >= 600`, which are no longer defined on
Solaris after the PR above. This check is due a misunderstanding of
those feature test macros: as detailed in [The Open Group Base
Specifications Issue 8, 2.2.1 POSIX.1
Symbols](https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html),
[17 lines not shown]
editors/emacs: Fix native compilation with canna flavor
isearch-ext.el is a file that comes with the canna patch. Because it is
preloaded, it was native-compiled during the bootstrap stage. This
caused the native-lisp directory to be created, which in turn meant AOT
for all other elisp was silently skipped.
Fix this by adding isearch-ext to native-comp-bootstrap-deny-list, so it
is native-compiled later along with the rest of the elisp.
Sponsored by: The FreeBSD Foundation
editors/emacs: Fix native compilation with canna flavor
isearch-ext.el is a file that comes with the canna patch. Because it is
preloaded, it was native-compiled during the bootstrap stage. This
caused the native-lisp directory to be created, which in turn meant AOT
for all other elisp was silently skipped.
Fix this by adding isearch-ext to native-comp-bootstrap-deny-list, so it
is native-compiled later along with the rest of the elisp.
Sponsored by: The FreeBSD Foundation
