devel/gradle5: pin to jdk8 or jdk11
Fails on runtime with newer jdk when building its sole dependency misc/elki.
When compiling in poudriere with DEFAULT_VERSIONS+=java=21:
===> Building for elki-0.7.1.1166_1
Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7
at org.codehaus.groovy.vmplugin.VMPluginFactory.<clinit>(VMPluginFactory.java:43)
The gradle documentation also states that you need a newer Gradle version for jdk12+.
https://docs.gradle.org/current/userguide/compatibility.html#java_runtime
PR: 291657
Approved-By: maintainer timeout
math/jacop: fix building in jdk11 and jdk17
Error fixed:
SimpleArrayList.java:187: error: tag not supported in HTML5: tt
[00:01:31] [ERROR] * Returns <tt>true</tt> if this list contains the specified element.
It does not build on jdk21.
Error on jdk21:
[00:00:43] [INFO] Compiling 30 source files to /wrkdirs/usr/ports/math/jacop/work/jacop-4.8.0/target/classes at 1765635688496
[00:00:44] [ERROR] error:
[00:00:44] [INFO] bad constant pool index: 0 at pos: 48454
[00:00:44] [INFO] while compiling: <no file>
[00:00:44] [INFO] during phase: globalPhase=<no phase>, enteringPhase=<some phase>
PR: 291629
Approved-by: maintainer timeout
devel/luajava: pin to openjdk8
Compiliing with jdk21 gives an error in javadoc which is fixed by making the patch-Makefile more generic so all jdk versions use '-Xdoclint:none'.
With the doclint option jdk11 and newer give an error on missing javah executable. I can't quickly fix this, so let's pin the port to openjdk8.
With this patch we can set JAVA_DEFAULT=21 and this port will still use openjdk8 to builld.
PR: 291579
Approved-By: maintainer timeout
[SLP]Exclude non-profitable subtrees.
Initial support for SLP tree throttling. Trims non-profitable subtrees,
trying to maximize perf gains.
Does not support trees with gathered loads yet, since they are not quite
trees, but graphs. Analysis should be added later.
Reviewers: RKSimon
Pull Request: https://github.com/llvm/llvm-project/pull/162018
dpaa2: Setup interface caps on attach
39d4094173f9 ("epair: add support for checksum offloading") revealed
that HW checksum offloading is not enabled when the dpaa2_ni driver
is attached despite being declared and enabled on the dpni interface.
I modified dpaa2_ni_setup_if_caps to take into account both IPv4 and
IPv6 checksum offloading capabilities and added a call to re-configure
interface capabilities on attach to fix it.
Reviewed by: bz
Fixes: 39d4094173f9 ("epair: add support for checksum offloading")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53436
(cherry picked from commit a731cb93a66271713d6ea197946e4a307e5b0837)
dpaa2: Setup interface caps on attach
39d4094173f9 ("epair: add support for checksum offloading") revealed
that HW checksum offloading is not enabled when the dpaa2_ni driver
is attached despite being declared and enabled on the dpni interface.
I modified dpaa2_ni_setup_if_caps to take into account both IPv4 and
IPv6 checksum offloading capabilities and added a call to re-configure
interface capabilities on attach to fix it.
Reviewed by: bz
Fixes: 39d4094173f9 ("epair: add support for checksum offloading")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53436
(cherry picked from commit a731cb93a66271713d6ea197946e4a307e5b0837)
AMDGPU: Avoid crashing on statepoint-like pseudoinstructions (#170657)
At the moment the MIR tests are somewhat redundant. The waitcnt
one is needed to ensure we actually have a load, given we are
currently just emitting an error on ExternalSymbol. The asm printer
one is more redundant for the moment, since it's stressed by the IR
test. However I am planning to change the error path for the IR test,
so it will soon not be redundant.
sysutils/jvmtop: pin to java 8
It misses tools.jar when building with jdk11+.
[ERROR] Failed to execute goal on project jvmtop: Could not resolve dependencies for project com.jvmtop:jvmtop:jar:0.9.0-SNAPSHOT: Could not find artifact com.sun:tools:jar:1.6 at specified path /usr/local/openjdk11/../lib/tools.jar -> [Help 1]
NB: upstream repo is inactive for 9 years. A fork (https://github.com/MOschIT/jvmtop)
claims jdk21 support, but that is outside of the scope of the issue I'm trying to solve.
PR: 291538
Approved-By: maintainer timeout
InstCombine: Introduce nsz flag on minimum/maximum in SimplifyDemandedFPClass
Alive isn't particularly happy with this in the case where
one of the inputs could be zero, but I think
it's wrong: https://alive2.llvm.org/ce/z/dF7V6k
nsz shouldn't permit introducing a -0 result where
there wasn't one in the input here.
stellarium: updated to 25.4
25.4
The major changes of this version:
- Added initial support of narration
- Added new sky cultures
- Many improvements in Sky Culture Maker plugin
- Many improvements in Core
- Many updates in sky cultures
[scudo] Use setenv instead of putenv in ScudoCombinedTest.ZeroOnDeallocEnabledAndFlag (#173423)
This solves a stack-use-after-scope reported by AddressSanitizer within
the unsetenv call at end of the test, due to the "Options" buffer, that
we allocate on the stack, having already gone out of scope.
Unlike putenv, which stores the pointer to the passed string directly in
the environment, setenv creates an internal copy.
