…54605)

Fix #41613.

Co-authored-by: FX Coudert <[email protected]>
(cherry picked from commit e5549c2)

This avoids a: `error: non-private labels cannot appear between
.cfi_startproc / .cfi_endproc pairs` error.
That error was introduced in https://reviews.llvm.org/D155245#4657075
see also llvm/llvm-project#72802

(cherry picked from commit a4e793e)

We may use aggressive constprop in `trevc!` to eliminate branches, which
makes the return type of `eigvec(::UpperTriangular)` concretely
inferred.
```julia
julia> @inferred eigvecs(UpperTriangular([1 0; 0 1]))
2×2 Matrix{Float32}:
 1.0  -0.0
 0.0   1.0
```

(cherry picked from commit ea8b4af)

This may introduce a correctness issue in the work-stealing termination
loop if we're using interactive threads and GC threads simultaneously.

Indeed, if we forget to add `nthreadsi` to `nthreads`, then we're
checking in the mark-loop termination protocol a range `[gc_first_tid,
gc_first_tid + jl_n_markthreads)` of threads which is "shifted to the
left" compared to what it should be.

This implies that we will not be checking whether the GC threads with
higher TID actually have terminated the mark-loop.

(cherry picked from commit c52eee2)

…#54671)

The race here is that svec might be replaced and a new binding
introduced into the keyset while we hold a reference to the old svec,
which led to a OOB access on the svec with the index a binding
introduced at the same time. This now introduces a bounds check which
will force taking the lock if we fail the lookup i.e we had a data race.

Fixes #54285

---------

Co-authored-by: Jameson Nash <[email protected]>
(cherry picked from commit 20f03dd)

…54672)

If the LLVM library was built without symbol versioning, previously this
would return the `nm` output in its entirety, instead of correctly
reporting "" as the LLVM symbol version.

(cherry picked from commit debaa73)

This should remove the dynamic dispatch flagged by JET, e.g. in
```julia
julia> using JET

julia> @report_opt reinterpret(Float64, [1.0im;;])
[ Info: tracking Base
┌ Warning: skipping (::Base.var"#thrownonint#375")(S::Type, T::Type, dim) @ Base reinterpretarray.jl:68 to avoid parsing too much code
└ @ Revise ~/.julia/packages/Revise/bAgL0/src/packagedef.jl:1092
┌ Warning: skipping (::Base.var"#show_bound#661")(io::IO, b) @ Base show.jl:2777 to avoid parsing too much code
└ @ Revise ~/.julia/packages/Revise/bAgL0/src/packagedef.jl:1092
┌ Warning: skipping (::Base.var"#show_bound#661")(io::IO, b) @ Base show.jl:2777 to avoid parsing too much code
└ @ Revise ~/.julia/packages/Revise/bAgL0/src/packagedef.jl:1092
═════ 32 possible errors found ═════
┌ reinterpret(::Type{Float64}, a::Matrix{ComplexF64}) @ Base ./reinterpretarray.jl:88
│┌ (::Base.var"#thrownonint#375")(S::Type{ComplexF64}, T::Type{Float64}, dim::Int64) @ Base ./reinterpretarray.jl:70
││┌ string(::String, ::Type{ComplexF64}, ::String, ::Type{Float64}, ::String, ::Int64, ::String) @ Base ./strings/io.jl:189
│││┌ print_to_string(::String, ::Type{ComplexF64}, ::String, ::Type{Float64}, ::String, ::Int64, ::String) @ Base ./strings/io.jl:148
││││┌ print(io::IOBuffer, x::DataType) @ Base ./strings/io.jl:35
│││││┌ show(io::IOBuffer, x::DataType) @ Base ./show.jl:970
││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:975
│││││││┌ show_typealias(io::IOBuffer, x::Type) @ Base ./show.jl:810
││││││││┌ make_typealias(x::Type) @ Base ./show.jl:620
│││││││││┌ modulesof!(s::Set{Module}, x::Type) @ Base ./show.jl:595
││││││││││ runtime dispatch detected: Base.modulesof!(s::Set{Module}, %20::Any)::Any
│││││││││└────────────────────
│││││││││┌ modulesof!(s::Set{Module}, x::Type) @ Base ./show.jl:596
││││││││││ runtime dispatch detected: Base.modulesof!(s::Set{Module}, %34::Any)::Any
│││││││││└────────────────────
│││││││││┌ modulesof!(s::Set{Module}, x::TypeVar) @ Base ./show.jl:589
││││││││││ runtime dispatch detected: Base.modulesof!(s::Set{Module}, %1::Any)::Set{Module}
│││││││││└────────────────────
│││││││┌ show_typealias(io::IOBuffer, x::Type) @ Base ./show.jl:813
││││││││┌ show_typealias(io::IOBuffer, name::GlobalRef, x::Type, env::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:760
│││││││││┌ show_typeparams(io::IOContext{IOBuffer}, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:724
││││││││││┌ show(io::IOContext{IOBuffer}, tv::TypeVar) @ Base ./show.jl:2788
│││││││││││┌ (::Base.var"#show_bound#661")(io::IOContext{IOBuffer}, b::Any) @ Base ./show.jl:2780
││││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, b::Any)::Any
│││││││││││└────────────────────
│││││││││┌ show_typeparams(io::IOContext{IOBuffer}, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:719
││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %252::Any)::Any
│││││││││└────────────────────
│││││││││┌ show_typeparams(io::IOContext{IOBuffer}, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:722
││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %313::Any)::Any
│││││││││└────────────────────
│││││││││┌ show_typeparams(io::IOContext{IOBuffer}, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:727
││││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %191::Any)::Any
│││││││││└────────────────────
││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:978
│││││││┌ show_datatype(io::IOBuffer, x::DataType) @ Base ./show.jl:1094
││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1097
│││││││││┌ maybe_kws_nt(x::DataType) @ Base ./show.jl:1085
││││││││││ runtime dispatch detected: eltype(%76::DataType)::Any
│││││││││└────────────────────
││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1186
│││││││││┌ show_typeparams(io::IOBuffer, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:724
││││││││││┌ show(io::IOBuffer, tv::TypeVar) @ Base ./show.jl:2788
│││││││││││┌ (::Base.var"#show_bound#661")(io::IOBuffer, b::Any) @ Base ./show.jl:2780
││││││││││││ runtime dispatch detected: show(io::IOBuffer, b::Any)::Any
│││││││││││└────────────────────
│││││││││┌ show_typeparams(io::IOBuffer, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:719
││││││││││ runtime dispatch detected: show(io::IOBuffer, %250::Any)::Any
│││││││││└────────────────────
│││││││││┌ show_typeparams(io::IOBuffer, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:722
││││││││││ runtime dispatch detected: show(io::IOBuffer, %310::Any)::Any
│││││││││└────────────────────
│││││││││┌ show_typeparams(io::IOBuffer, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar}) @ Base ./show.jl:727
││││││││││ runtime dispatch detected: show(io::IOBuffer, %190::Any)::Any
│││││││││└────────────────────
││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1157
│││││││││ runtime dispatch detected: show(io::IOBuffer, %224::Any)::Any
││││││││└────────────────────
││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1162
│││││││││ runtime dispatch detected: show(io::IOBuffer, %54::Any)::Any
││││││││└────────────────────
││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1148
│││││││││ runtime dispatch detected: show(io::IOBuffer, %57::Any)::Any
││││││││└────────────────────
││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1150
│││││││││ runtime dispatch detected: show(io::IOBuffer, %54::Any)::Any
││││││││└────────────────────
││││││││┌ show_datatype(io::IOBuffer, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1172
│││││││││ runtime dispatch detected: Base.show_at_namedtuple(io::IOBuffer, %329::Tuple, %328::DataType)::Any
││││││││└────────────────────
││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:981
│││││││┌ show_unionaliases(io::IOBuffer, x::Union) @ Base ./show.jl:901
││││││││┌ make_typealiases(x::Union) @ Base ./show.jl:822
│││││││││┌ modulesof!(s::Set{Module}, x::Union) @ Base ./show.jl:595
││││││││││ runtime dispatch detected: Base.modulesof!(s::Set{Module}, %3::Any)::Any
│││││││││└────────────────────
│││││││││┌ modulesof!(s::Set{Module}, x::Union) @ Base ./show.jl:596
││││││││││ runtime dispatch detected: Base.modulesof!(s::Set{Module}, %17::Any)::Any
│││││││││└────────────────────
│││││││┌ show_unionaliases(io::IOBuffer, x::Union) @ Base ./show.jl:914
││││││││ runtime dispatch detected: show(io::IOBuffer, %89::Any)::Any
│││││││└────────────────────
│││││││┌ show_unionaliases(io::IOBuffer, x::Union) @ Base ./show.jl:920
││││││││ runtime dispatch detected: Base.show_typealias(io::IOBuffer, %206::Any, x::Union, %204::Core.SimpleVector, %205::Vector{TypeVar})::Any
│││││││└────────────────────
│││││││┌ show_unionaliases(io::IOBuffer, x::Union) @ Base ./show.jl:928
││││││││ runtime dispatch detected: Base.show_typealias(io::IOBuffer, %269::Any, x::Union, %267::Core.SimpleVector, %268::Vector{TypeVar})::Any
│││││││└────────────────────
││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:985
│││││││┌ show_delim_array(io::IOBuffer, itr::Vector{Any}, op::Char, delim::Char, cl::Char, delim_one::Bool) @ Base ./show.jl:1392
││││││││┌ show_delim_array(io::IOBuffer, itr::Vector{Any}, op::Char, delim::Char, cl::Char, delim_one::Bool, i1::Int64, l::Int64) @ Base ./show.jl:1403
│││││││││ runtime dispatch detected: show(%3::IOContext{IOBuffer}, %52::Any)::Any
││││││││└────────────────────
││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:1012
│││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1185
││││││││┌ show_type_name(io::IOContext{IOBuffer}, tn::Core.TypeName) @ Base ./show.jl:1059
│││││││││ runtime dispatch detected: Base.isvisible(%29::Symbol, %86::Module, %80::Any)::Bool
││││││││└────────────────────
│││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1157
││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %227::Any)::Any
│││││││└────────────────────
│││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1162
││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %55::Any)::Any
│││││││└────────────────────
│││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1148
││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %58::Any)::Any
│││││││└────────────────────
│││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1150
││││││││ runtime dispatch detected: show(io::IOContext{IOBuffer}, %55::Any)::Any
│││││││└────────────────────
│││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1172
││││││││ runtime dispatch detected: Base.show_at_namedtuple(io::IOContext{IOBuffer}, %338::Tuple, %337::DataType)::Any
│││││││└────────────────────
│││││││┌ show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar}) @ Base ./show.jl:1180
││││││││ runtime dispatch detected: Base.show_at_namedtuple(io::IOContext{IOBuffer}, %387::Tuple, %391::DataType)::Any
│││││││└────────────────────
││││││┌ _show_type(io::IOBuffer, x::Type) @ Base ./show.jl:1014
│││││││ runtime dispatch detected: show(%98::IOContext{IOBuffer}, %99::Any)::Any
││││││└────────────────────
│││││┌ show(io::IOBuffer, x::DataType) @ Base ./show.jl:970
││││││ runtime dispatch detected: Base._show_type(io::IOBuffer, %1::Any)::Nothing
│││││└────────────────────
```

(cherry picked from commit b54c688)

Apparently on some distributions `nm --with-symbol-versions` does not
report symbol versions, despite the flag.

`readelf` should be a more reliable alternative which is also part of
binutils.

See spack/spack#44534 (comment)
for more information

(cherry picked from commit d0f165f)

…#54781)

When testing a new version of `libblastrampoline` that may have flags
and values that we don't know about, raise a nice warning rather than a
hard error.

(cherry picked from commit 5044506)

The fact that `@async` causes the task that it was scheduled from to
also become sticky is well documented in the warning in [`@async`
docs](https://docs.julialang.org/en/v1/base/parallel/#Base.@async), but
it's not clear that creating a task and scheduling it also has the same
effect, by default.

(cherry picked from commit a9b4869)

…ions (#54837)

Enzyme.jl hit an issue where, in a dynamically typed allocation of size
`GC_MAX_SZCLASS`, because we mistakenly added they type tag size to the
allocation, the runtime disagreed if this was a pool allocation or a big
allocation. Causing a crash in the GC

(cherry picked from commit ded0b28)

…ac1fc (#55114)

…#55143)

After investigating JuliaLang/julia#54090, I found that the issue was
not caused by the effects of `checksquare`, but by the use of the
`@simd` macro within `tr(::Matrix)`:

https://github.com/JuliaLang/julia/blob/0945b9d7740855c82a09fed42fbf6bc561e02c77/stdlib/LinearAlgebra/src/dense.jl#L373-L380

While simply removing the `@simd` macro was considered, the strict
left-to-right summation without `@simd` otherwise is not necessarily
more accurate, so I concluded that the problem lies in the test code,
which tests the (strict) equality of two different `tr` execution
results. I have modified the test code to use `≈` instead of `==`.

- fixes #54090

This reduces dynamic dispatch and makes JET happier.
Testing on v1.11:
```julia
julia> import LinearAlgebra: checksquare

julia> using JET

julia> @report_opt checksquare(rand(2,2), rand(2,2))
═════ 4 possible errors found ═════
┌ checksquare(::Matrix{Float64}, ::Matrix{Float64}) @ LinearAlgebra /cache/build/builder-amdci4-1/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/LinearAlgebra.jl:307
│┌ string(::String, ::Tuple{Int64, Int64}) @ Base ./strings/io.jl:189
││┌ print_to_string(::String, ::Tuple{Int64, Int64}) @ Base ./strings/io.jl:150
│││┌ _unsafe_take!(io::IOBuffer) @ Base ./iobuffer.jl:494
││││┌ wrap(::Type{Array}, m::MemoryRef{UInt8}, l::Int64) @ Base ./array.jl:3101
│││││ failed to optimize due to recursion: wrap(::Type{Array}, ::MemoryRef{UInt8}, ::Int64)
││││└────────────────────
│││┌ print_to_string(::String, ::Vararg{Any}) @ Base ./strings/io.jl:143
││││ runtime dispatch detected: Base._str_sizehint(%17::Any)::Int64
│││└────────────────────
│││┌ print_to_string(::String, ::Vararg{Any}) @ Base ./strings/io.jl:148
││││ runtime dispatch detected: print(%59::IOBuffer, %97::Any)::Any
│││└────────────────────
│││┌ string(::String, ::Int64, ::String, ::Tuple{Int64}, ::String, ::Int64, ::String, ::Int64, ::String) @ Base ./strings/io.jl:189
││││ failed to optimize due to recursion: string(::String, ::Int64, ::String, ::Tuple{Int64}, ::String, ::Int64, ::String, ::Int64, ::String)
│││└────────────────────

julia> function checksquare(A...) # This PR
                  sizes = Int[]
                  for a in A
                      size(a,1)==size(a,2) || throw(DimensionMismatch(lazy"matrix is not square: dimensions are $(size(a))"))
                      push!(sizes, size(a,1))
                  end
                  return sizes
              end
checksquare (generic function with 2 methods)

julia> @report_opt checksquare(rand(2,2), rand(2,2))
No errors detected

```

As discussed in
https://discourse.julialang.org/t/pinv-not-type-stable/103885/14, the
`tol` variable is captured which leads to it being boxed, as suggested
can be fixed by having two separate variables.

(cherry picked from commit 8e21b21)

![Screenshot 2023-12-30 at 7 24
10 PM](https://github.com/JuliaLang/julia/assets/1694067/a7c78943-5e4a-475c-864c-3b0005305471)

(cherry picked from commit 0f62824)

(cherry picked from commit 8945914)

#55141)

The devdocs here reflect a time when aarch64 was much less well
supported, it also reference Cudadrv which has been archived for years

(cherry picked from commit 2efcfd9)

This macro was added in v1.10 but was missing a compat notice.

(cherry picked from commit 3290904)

`a[begin]` indexing was added by #35779 in Julia 1.6, so this feature
needs a compat notice in the docstring.

(cherry picked from commit 43df7fb)

Correction to #55197: `a[begin]` indexing was added in Julia 1.4
(#33946), not in Julia 1.6 (which just changed the implementation in
#35779). My bad.

(cherry picked from commit 06467eb)

Introduced in #43305

(cherry picked from commit 6b08e80)

This avoids returning false positives where only the indices are shared.
As the indices are not mutated by array assignments (and are explicitly
warned against mutation in general), we can ignore the case where _only_
the indices are aliasing.

Fix #54621

(cherry picked from commit 97bf148)

…54690)

AllocOpt probably needs to handle that in other places more smartly but
this seems to at least stop it crashing. Fixes issue found in
#54604 (comment) by
@topolarity.

(cherry picked from commit 5cb1107)

closes #55083

Shouldu this also check for `\r`?

---------

Co-authored-by: Alex Arslan <[email protected]>
(cherry picked from commit e732706)

…55070)

(cherry picked from commit ec013f1)

(cherry picked from commit 3f8e1bd)

This release fixes issues with complex valued returns from functions
such as `cdotc` on Windows x64. See this discussion [0] for initial
diagnosis, and this PR [1] for the relevant fixes.

[0] JuliaLinearAlgebra/BLISBLAS.jl#15
[1] JuliaLinearAlgebra/libblastrampoline#129

(cherry picked from commit 3054c00)

… now using opaque pointers

Per
JuliaCI/julia-buildkite#224 (comment),
the path needs to be updated so that `llvm-size` can find `libLLVM.dll`.

(cherry picked from commit 657ce04)

…dir (#52820)

Fix #51740

Since we are providing libssp.dll on Windows and we want to dynamically
link to it, exposing libssp.dll.a is necessary. The inconsistency is
that libjulia-codegen.so looks in build_libdir and build_private_libdir
while standard library precompilation looks in build_shlibdir and
build_private_dir.

(cherry picked from commit c3836e1)

)

Backport of #54871 onto 1.10

We don't have the luxury of modifying the C-API. This pass surfaces LLVM
missed transformation warnings,
which is surprising to users. It can be very helpful, but it can also
add unactionable noise to the output
of Julia programs.

This PR simply removes it from the pipeline.

LLVM generates calls to math intrinsics like `trunc` and `rint` (at
least in my local i686 mingw) build, so linking to openlibm is required.
We already have this on the sysimg link line in `Base.link_image`, so
this aligns those options.

---------

Co-authored-by: Elliot Saba <[email protected]>
(cherry picked from commit 320366b)

…647d8 (#55385)

After #55180 we implicitly require an LLVM built with Zlib support, but
compiling Julia with `make USE_BINARYBUILDER_LLVM=0` builds an LLVM
without Zlib support, despite the fact we attempt to request it at

https://github.com/JuliaLang/julia/blob/996351f5f6651d1508aef3c35c7d37eb22a0fb1e/deps/llvm.mk#L97
This was first identified in #55337.

`ZLIB_LIBRARY` must be the path to the zlib library, but we currently
set it to the libdir where the library is installed (introduced in

https://github.com/JuliaLang/julia/blob/996351f5f6651d1508aef3c35c7d37eb22a0fb1e/deps/llvm.mk#L97
which is wrong. However, CMake is actually able to find Zlib correctly,
but then the check at
https://github.com/llvm/llvm-project/blob/46425b8d0fac3c529aa4a716d19abd7032e452f3/llvm/cmake/config-ix.cmake#L139-L141
uses the value of `ZLIB_LIBRARY` to list the Zlib to link for the test,
but being `ZLIB_LIBRARY` a directory, CMake doesn't see any valid Zlib
and thus tries to run the test without linking any Zlib, and the test
silently fails (they're silent only when `LLVM_ENABLE_ZLIB=ON`),
resulting in no usable Zlib available, even if found.

`ZLIB_ROOT` is the only [hint recommended by the CMake module
`FindZLIB`](https://cmake.org/cmake/help/latest/module/FindZLIB.html#hints).
This PR replaces a broken `ZLIB_LIBRARY` with an appropriate
`ZLIB_ROOT`. Also, we set `LLVM_ENABLE_ZLIB=FORCE_ON` which is the only
way to make CMake fail loudly if no usable Zlib is available, and avoid
going on with a non-usable build.

I confirm this fixes #55337 for me, it should likely address
JuliaCI/julia-buildkite#373 as well.

Also, options `COMPILER_RT_ENABLE_IOS`, `COMPILER_RT_ENABLE_WATCHOS`,
`COMPILER_RT_ENABLE_TVOS`, and `HAVE_HISTEDIT_H` don't exist anymore,
and they are removed.

…data (#55306) (#55397)

…data (#55306)

Co-authored-by: Valentin Churavy <[email protected]>
Co-authored-by: Mosè Giordano <[email protected]>
Co-authored-by: Gabriel Baraldi <[email protected]>

The docstring of `LinearAlgebra.reflectorApply!` is incorrect. It says
the function is applying `(I - τ*[1; x] * [1; x]')*A`, but in reality it
is applying `(I - conj(τ)*[1; x[2:end]]*[1; x[2:end]]')*A`. You can
check that by looking at the code, or running for example
```julia
using LinearAlgebra
T=ComplexF64;d=5;
τ=randn(T);x=randn(T,d);A=randn(T,d,d);
(I - conj(τ)*[1; x[2:end]]*[1; x[2:end]]')*A
LinearAlgebra.reflectorApply!(x,τ,A)
```

(cherry picked from commit 1ece299)

`stack` does not require that the inner iterator defines `axes`, but the
code to assemble an error message assumed this.

Found here:
https://discourse.julialang.org/t/reduce-hcat-is-type-unstable/112800/3

(cherry picked from commit ae483c3)

It can be very helpful, when struggling with LBT forwarding, to see what
functions were actually forwarded to a new library. This utility
function makes it easy to query which functions are forwarded to that
library.

(cherry picked from commit e0f2e29)

In 1.10 we have

```jl
julia> isleapyear(Year(1992))
false
```

which is semantically incorrect because `Year(1992)` is a duration (1992
years), not an instant. This PR restricts the currently unrestricted
argument to integers.

(cherry picked from commit fdecc59)

(cherry picked from commit b759fe2)

This includes support to properly forward MKL v2024's ILP64 CBLAS
symbols, which fixes this [Enzyme
issue](EnzymeAD/Enzyme.jl#1683)

(cherry picked from commit 602b582)

This ensures that `tr` for a block `SymTridiagonal` symmetrizes the
diagonal elements.

(cherry picked from commit a163483)

Part of fixing JuliaLang/Pkg.jl#3984

…1a6e8 (#55437)

Stdlib: Pkg
URL: https://github.com/JuliaLang/Pkg.jl.git
Stdlib branch: release-1.10
Julia branch: backports-release-1.10
Old commit: 9cb6d35f8
New commit: 45521a6e8
Julia version: 1.10.4
Pkg version: 1.10.0(Does not match)
Bump invoked by: @IanButterworth
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaLang/Pkg.jl@9cb6d35...45521a6

```
$ git log --oneline 9cb6d35f8..45521a6e8
45521a6e8 backport extension dependency modeling from Base 1.11 to Pkg 1.10 (#3986)
1810b1123 don't swallow internal errors (#3987)
```

Co-authored-by: Dilum Aluthge <[email protected]>

…6cff6 (#55463)

Stdlib: Pkg
URL: https://github.com/JuliaLang/Pkg.jl.git
Stdlib branch: release-1.10
Julia branch: backports-release-1.10
Old commit: 45521a6e8
New commit: a4f26cff6
Julia version: 1.10.4
Pkg version: 1.10.0(Does not match)
Bump invoked by: @IanButterworth
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaLang/Pkg.jl@45521a6...a4f26cf

```
$ git log --oneline 45521a6e8..a4f26cff6
a4f26cff6 [release-1.10] Pkg.precompile: Handle when the terminal is very short (#3988)
```

Co-authored-by: Dilum Aluthge <[email protected]>