devel/freebsd-gcc15: External FreeBSD toolchain based on GCC 15
This port provides external GCC toolchains for GCC 15.2.0 for the
aarch64, amd64, armv7, i386, powerpc, powerpc64, powerpc64le, and
riscv64 platforms.
Reviewed by: lwhsu
Differential Revision: https://reviews.freebsd.org/D54834
[AMDGPU] Fix DomTree preservation in SILowerControlFlow when nodes are removed (#176691)
I would think the "applyUpdates" API should also take care of deleting
the nodes from the analyses objects but this does not seem to be the
case. https://godbolt.org/z/38a7rfzjd shows an example where
SILowerControlFlow removes a basic block which is not removed in the
Post dominator tree.
MFC: libfetch: apply timeout to SSL_read()
Currently, fetchTimeout works for non-SSL connections only, so does fetch -T.
Fix it applying specified timeout to SSL_read().
(cherry picked from commit 8f8a7f6fffd7dca09013f7c4bfa075bc3825fb8e)
MFC: libfetch: apply timeout to SSL_read()
Currently, fetchTimeout works for non-SSL connections only, so does fetch -T.
Fix it applying specified timeout to SSL_read().
(cherry picked from commit 8f8a7f6fffd7dca09013f7c4bfa075bc3825fb8e)
MFC: libfetch: apply timeout to SSL_read()
Currently, fetchTimeout works for non-SSL connections only, so does fetch -T.
Fix it applying specified timeout to SSL_read().
(cherry picked from commit 8f8a7f6fffd7dca09013f7c4bfa075bc3825fb8e)
Merge tag 'riscv-for-linus-6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
"The notable changes here are the three RISC-V timer compare register
update sequence patches. These only apply to RV32 systems and are
related to the 64-bit timer compare value being split across two
separate 32-bit registers.
We weren't using the appropriate three-write sequence, documented in
the RISC-V ISA specifications, to avoid spurious timer interrupts
during the update sequence; so, these patches now use the recommended
sequence.
This doesn't affect 64-bit RISC-V systems, since the timer compare
value fits inside a single register and can be updated with a single
write.
- Fix the RISC-V timer compare register update sequence on RV32
systems to use the recommended sequence in the RISC-V ISA manual
[21 lines not shown]
audio/wavpack: Re-enable testing
The tests can take a rather long time to complete, so I thought they
were hanging. Add a pre-test target to explain this, so people with old
hardware like myself know what to expect and for folks who have
WITH_TESTING enabled. Normally, regression tests don't take this long.
This is also a team maintained port, so pitfalls should be highlighted.
I also retract my statement of "test target has been failing for a while"
in the previous commit message. This was based on me testing the previous
version and seeing the same behavior of the wvtest process seemingly
hanging as I observed in the current version before review.
Reported by: diizzy, arrowd
Fixes: f8ba7a9305fc - audio/wavpack: Update to 5.9.0
Mk: Add QA for common directories that are excluded in modern setuptools.
Directories like docs/ should not be installed to site-packages because they
are not useful when installed there and tend to cause conflicts with other
packages. This follows similar guidelines for Debian, Fedora and other major
Linux distributions.
PR: ports/290944
Approved by: portmgr (mat)
Merge tag 'trace-v6.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Fix a crash with passing a stacktrace between synthetic events
A synthetic event is an event that combines two events into a single
event that can display fields from both events as well as the time
delta that took place between the events. It can also pass a
stacktrace from the first event so that it can be displayed by the
synthetic event (this is useful to get a stacktrace of a task
scheduling out when blocked and recording the time it was blocked
for).
A synthetic event can also connect an existing synthetic event to
another event. An issue was found that if the first synthetic event
had a stacktrace as one of its fields, and that stacktrace field was
passed to the new synthetic event to be displayed, it would crash the
kernel. This was due to the stacktrace not being saved as a
[33 lines not shown]
