Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backports release 1.10.5 #54851

Merged
merged 52 commits into from
Aug 13, 2024
Merged

Backports release 1.10.5 #54851

merged 52 commits into from
Aug 13, 2024

Conversation

KristofferC
Copy link
Member

@KristofferC KristofferC commented Jun 19, 2024

Backported PRs:

Need manual backport:

Contains multiple commits, manual intervention needed:

Non-merged PRs with backport label:

ViralBShah and others added 10 commits June 19, 2024 14:01
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)
@KristofferC KristofferC added the release Release management and versioning. label Jun 19, 2024
…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)
@wsmoses
Copy link
Contributor

wsmoses commented Jul 10, 2024

@KristofferC any ETA on a release? We've gotten a bunch of issues recently that seem to be related to the GC fix here

aviatesk and others added 2 commits July 17, 2024 17:41
…#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

```
Zentrik and others added 10 commits July 24, 2024 11:41
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)
#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)
@KristofferC
Copy link
Member Author

Now

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./codegen.o: in function `add_named_global':
C:/workdir/src/codegen.cpp:507:(.text+0x271f7): undefined reference to `__imp___stack_chk_guard'

…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)
@giordano
Copy link
Contributor

giordano commented Aug 4, 2024

Last error on x86_64 Windows is

 g++ -m64  -shared  -L/c/workdir/usr/lib/julia -L/c/workdir/usr/lib -L/c/workdir/usr/bin -o /c/workdir/usr/lib/julia/sys.dll -Wl,--whole-archive /c/workdir/usr/lib/julia/sys-o.a -Wl,--no-whole-archive -ljulia-internal -ljulia $([ WINNT = WINNT ] && echo '' -lssp --disable-auto-import --disable-runtime-pseudo-reloc)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/workdir/usr/lib/julia/sys-o.a(text#1.o): in function `round':
./float.jl:396:(.text+0x2e42): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:393:(.text+0x2e6f): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:393:(.text+0x516ea): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:396:(.text+0x52f12): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:396:(.text+0x52f5b): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:393:(.text+0xe1a04): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:393:(.text+0xe1aed): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:396:(.text+0x1227cc): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/workdir/usr/lib/julia/sys-o.a(text#2.o): in function `round':
./float.jl:393:(.text+0x89bb): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:396:(.text+0x77e45): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:393:(.text+0x1424e9): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/workdir/usr/lib/julia/sys-o.a(text#3.o): in function `round':
./float.jl:396:(.text+0x18ecf): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:396:(.text+0x40123): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:396:(.text+0x4016a): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:396:(.text+0x401d1): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:396:(.text+0xba321): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/workdir/usr/lib/julia/sys-o.a(text#3.o):./float.jl:396: more undefined references to `rint' follow
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/workdir/usr/lib/julia/sys-o.a(text#3.o): in function `round':
./float.jl:393:(.text+0xba424): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/workdir/usr/lib/julia/sys-o.a(text#4.o): in function `round':
./float.jl:393:(.text+0x3552d): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:396:(.text+0x14746c): undefined reference to `rint'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/workdir/usr/lib/julia/sys-o.a(text#5.o): in function `round':
./float.jl:393:(.text+0x27a2): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:393:(.text+0x819d): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:393:(.text+0x81e6): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ./float.jl:393:(.text+0x8231): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/workdir/usr/lib/julia/sys-o.a(text#6.o): in function `round':
./float.jl:393:(.text+0x5dd12): undefined reference to `trunc'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/workdir/usr/lib/julia/sys-o.a(text#6.o):./float.jl:393: more undefined references to `trunc' follow
collect2.exe: error: ld returned 1 exit status

which was probably addressed by #53672.

vchuravy and others added 15 commits August 5, 2024 12:06
)

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)
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)
…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]>
@KristofferC
Copy link
Member Author

@nanosoldier runtests()

@nanosoldier
Copy link
Collaborator

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

@KristofferC
Copy link
Member Author

@nanosoldier runtests(["EulerAngles", "JuliaInterpreter", "SubSIt", "AesKeywrapNettle", "Bonobo", "ArnoldiMethodTransformations", "BundledWebResources", "Pyehtim", "Dynesty", "SmallCouplingDynamicCavity", "BaytesOptim", "RiskMeasures", "DECAES", "MeshIntegrals", "OptimizationBase"])

@nanosoldier
Copy link
Collaborator

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

…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]>
@KristofferC
Copy link
Member Author

These look a bit weird:


https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/b4b1646_vs_48d4fd4/ArnoldiMethodTransformations.primary.log

  Got exception outside of a @test
  TypeError: in <:, expected Type, got Vararg
  Stacktrace:
    [1] #s11#5
      @ ~/.julia/packages/StaticArrays/DBECI/src/util.jl:20 [inlined]
    [2] var"#s11#5"(T::Any, ::Any, ::Any)
      @ StaticArrays ./none:0
    [3] (::Core.GeneratedFunctionStub)(::UInt64, ::LineNumberNode, ::Any, ::Vararg{Any})
      @ Core ./boot.jl:602
    [4] macro expansion
      @ ~/.julia/packages/StaticArrays/DBECI/src/SMatrix.jl:35 [inlined]
    [5] SArray
      @ ~/.julia/packages/StaticArrays/DBECI/src/SMatrix.jl:32 [inlined]
    [6] swap12!(R::Matrix{Float64}, i::Int64, Q::Matrix{Float64})
      @ ArnoldiMethod ~/.julia/packages/ArnoldiMethod/5fDBS/src/schursort.jl:403
    [7] swap!
      @ ~/.julia/packages/ArnoldiMethod/5fDBS/src/schursort.jl:479 [inlined]
    [8] rotate_right!(R::Matrix{Float64}, from::Int64, to::Int64, Q::Matrix{Float64})
      @ ArnoldiMethod ~/.julia/packages/ArnoldiMethod/5fDBS/src/schursort.jl:27
    [9] partition_schur_three_way!(R::Matrix{Float64}, Q::Matrix{Float64}, groups::Vector{Int64})
      @ ArnoldiMethod ~/.julia/packages/ArnoldiMethod/5fDBS/src/run.jl:348

https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/b4b1646_vs_48d4fd4/RiskMeasures.primary.log

ERM: Error During Test at /home/pkgeval/.julia/packages/RiskMeasures/WtuMO/test/runtests.jl:14
  Test threw exception
  Expression: isapprox(ERM(x̃, 0.0), ERM(x̃, 1.0e-5); atol = 0.001)
  UndefVarError: `ERM` not defined
  Stacktrace:
   [1] macro expansion
     @ /opt/julia/share/julia/stdlib/v1.10/Test/src/Test.jl:669 [inlined]
   [2] macro expansion
     @ ~/.julia/packages/RiskMeasures/WtuMO/test/runtests.jl:14 [inlined]
   [3] macro expansion
     @ /opt/julia/share/julia/stdlib/v1.10/Test/src/Test.jl:1577 [inlined]
   [4] top-level scope
     @ ~/.julia/packages/RiskMeasures/WtuMO/test/runtests.jl:10

https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/b4b1646_vs_48d4fd4/SmallCouplingDynamicCavity.primary.log

inferenceSIscheme: Error During Test at /home/pkgeval/.julia/packages/SmallCouplingDynamicCavity/IJlmV/test/testSI.jl:80
  Got exception outside of a @test
  MethodError: no method matching run_SCDC(::EpidemicModel{SI, SimpleGraph{Int64}}, ::typeof(obsprob), ::Float64, ::Vector{Int64}, ::Float64, ::Vector{Float64}; μ_cutoff::Float64)
  
  Closest candidates are:
    run_SCDC(::EpidemicModel{TI, TG}, ::Function, ::Float64, !Matched::Int64, ::Float64, !Matched::Float64; μ_cutoff, n_iter_nc, damp_nc, callback) where {TI<:SmallCouplingDynamicCavity.InfectionModel, TG<:(Union{Vector{<:AbstractGraph}, var"#s20"} where var"#s20"<:AbstractGraph)}
     @ SmallCouplingDynamicCavity ~/.julia/packages/SmallCouplingDynamicCavity/7Ac4A/src/message_passing_func.jl:227

https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/b4b1646_vs_48d4fd4/AesKeywrapNettle.primary.log

     Testing AesKeywrapNettle

Testing failed after 1.3s

ERROR: LoadError: expected package `AesKeywrapNettle [d0ff3c94]` to exist at path `/home/pkgeval/.julia/packages/AesKeywrapNettle/iVg1c`
Stacktrace:
  [1] pkgerror(msg::String)
    @ Pkg.Types /opt/julia/share/julia/stdlib/v1.10/Pkg/src/Types.jl:70
  [2] collect_fixed!(env::Pkg.Types.EnvCache, pkgs::Vector{Pkg.Types.PackageSpec}, names::Dict{UUID, String})
    @ Pkg.Operations /opt/julia/share/julia/stdlib/v1.10/Pkg/src/Operations.jl:312
  [3] resolve_versions!(env::Pkg.Types.EnvCache, registries::Vector{Pkg.Registry.RegistryInstance}, pkgs::Vector{Pkg.Types.PackageSpec}, julia_version::VersionNumber, installed_only::Bool)
    @ Pkg.Operations /opt/julia/share/julia/stdlib/v1.10/Pkg/src/Operations.jl:377
  [4] up(ctx::Pkg.Types.Context, pkgs::Vector{Pkg.Types.PackageSpec}, level::Pkg.Types.UpgradeLevel; skip_writing_project::Bool, preserve::Nothing)
    @ Pkg.Operations /opt/julia/share/julia/stdlib/v1.10/Pkg/src/Operations.jl:1537
  [5] up(ctx::Pkg.Types.Context, pkgs::Vector{Pkg.Types.PackageSpec}; level::Pkg.Types.UpgradeLevel, mode::Pkg.Types.PackageMode, preserve::Nothing, update_registry::Bool, skip_writing_project::Bool, kwargs::@Kwargs{io::Base.DevNull})
    @ Pkg.API /opt/julia/share/julia/stdlib/v1.10/Pkg/src/API.jl:351

@KristofferC
Copy link
Member Author

@nanosoldier runtests(["AesKeywrapNettle", "ArnoldiMethodTransformations", "RiskMeasures", "Bonobo", "SmallCouplingDynamicCavity", "JuliaInterpreter", "SubSIt"])

@nanosoldier
Copy link
Collaborator

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

@KristofferC KristofferC merged commit 6f77e2a into release-1.10 Aug 13, 2024
6 checks passed
@KristofferC KristofferC deleted the backports-release-1.10 branch August 13, 2024 14:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release Release management and versioning.
Projects
None yet
Development

Successfully merging this pull request may close these issues.