-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
[release-0.5] backports for 0.5.2 #21684
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
Conversation
causing duplicate files and including directories it shouldn't be (cherry picked from commit 4521e6b)
from OpenMathLib/OpenBLAS#1098 (cherry picked from commit 26beab3) ref #21091 fix Makefile.system dependency for release-0.5
Fixes #21122 (cherry picked from commit 3d126b8) remove testset for release-0.5
See 30ba746#commitcomment-21430419 for more details (cherry picked from commit 7ce4925) ref #21134
The DirtyCOW exploit mitigation patch in Linux (torvalds/linux@19be0eaff), introduced a kernel bug, that would cause the kernel to hang if an application tries to use /proc/<pid>/mem (or ptrace) to bypass page protections on pages that are backed by transparent huge pages (though only if the write causes a COW resolution). We make use of this feature in our cg memory manager on Linux, but since we can't predict whether or not our mappings will be backed by transparent huge pages, the only safe thing to do is to fall back to dual maps on kernels that potentially have this issue. Since the problematic commit is a fix for a high-profile exploit, it is quite likely that it is included in most stable kernels by now. I have a patch pending at http://marc.info/?l=linux-mm&m=148359462417378&w=2, which I expect will fix this in the kernel for 4.10. However, we'll have to disable the use of /proc/self/mem for all prior kernel versions to avoid locking up the kernel. (cherry picked from commit c8312d3) ref #19887
@jlbuild !nuke
|
Looks like that's not running. More importantly, @staticfloat the centos buildbots are having certificate issues and aren't able to download some of the deps: https://build.julialang.org/builders/package_tarball64/builds/247/steps/make/logs/stdio |
a2aaed6
to
172ff0d
Compare
(cherry picked from commit 9baadbf)
(cherry picked from commit 8d27c72) ref #20480 go back to vec of matrix comprehension for release-0.5 avoids ERROR: LoadError: LoadError: ArgumentError: argument to Flatten must contain at least one iterator in start at .\iterator.jl:599 in grow_to! at .\array.jl:357 in intersect at .\pkg\types.jl:44 in push! at .\pkg\types.jl:182 in requirements at .\pkg\query.jl:34 in resolve at .\pkg\entry.jl:476
Add a pre-pruning step in which requirements are propagated along the dependency graph, keeping a backtrace of the process. This has two benefits: 1. Make things easier for the solver, by simplifying the graph and reducing the number of versions 2. It should detect most common problems with requirements that introduce implicit contradictions, and it provides a useful error message to fix the situation. (cherry picked from commit d054d36) ref #20480
after reverts: @nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels |
@tkelman I was testing this branch out for fun on my new buildbots, and I ran into the problem of |
It may be a difference in buildbot configuration? Can someone with access to arm and power test the binaries linked above, that were built from the older existing buildbots? |
I just tested them, they both work fine. Time to dig into why they don't link against libLTO I guess. |
ugh so gcc 7 bumped the libgfortran somajor from 3 to 4, breaking a lot of assumptions our scripts were making, and the mac nightlies are now missing libgfortran |
can we downgrade the mac buildbot to |
I've installed |
rerun to see whether remaining regressions are noise : @nanosoldier |
@staticfloat is there a link or alias step we can do to have that get used as |
https://gist.github.com/b44bbbac3697bcf715ba1c464298f95b
If the benchmark and buildbots are okay I want to tag this, #21708 can wait, I'd rather not have to go through pkgeval another time |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels |
Since 0.6.0 is just around the proverbial corner, I agree; non-NEON architectures can just wait until 0.6.0 is released, which shouldn't be too far off (knock on wood) |
I might have lost track here, but have the regressions we had attributed to #21319 just occurred again although it was reverted? |
No description provided.