[ASTMatchers][Docs] make dump_ast_matchers.py read classes from sources (#203784)
With this change, `dump_ast_matchers.py` script no longer need to probe
network to search for classes.
This allows the script to run offline which is needed for
https://github.com/llvm/llvm-project/pull/165472.
The script now operates on assumption that all classes in AST/ will be
here: https://llvm.org/doxygen/ (which is true in general unless doxygen
page is down)
Pull up following revision(s) (requested by riastradh in ticket #340):
lib/libbsdmalloc/malloc.c: revision 1.12
ensure the lock is released for all returns in malloc
Pull up following revision(s) (requested by riastradh in ticket #2017):
lib/libpthread/Makefile: revision 1.103
tests/lib/libpthread/dlopen/t_dso_pthread_create.c: revision 1.2
tests/lib/libpthread/dlopen/t_dlopen.c: revision 1.2
tests/lib/libpthread/dlopen/t_dlopen.c: revision 1.3
lib/libpthread/shlib_version: revision 1.24
tests/lib/libpthread: Test unloading libpthread after lazy binding.
If you dlopen libpthread and dlclose it again, the thread stubs like
pthread_mutex_lock need to continue working -- a library might have
calls to it in order to support thread-safety for threaded
applications, but that library needs to continue working even in
non-threaded applications after lazy binding of the libpthread symbol
instead of the libc stub.
PR lib/59784: dlopening and dlclosing libpthread is broken
[29 lines not shown]
Revert "fdp-primer: Mention that .po files are generated nightly"
This reverts commit 64b3126c0db9dcc8cf9a2f003b3a52dbb76a7fd1.
It turns out the information was wrong and the PO files are not created
nightly.
porters-handbook: Use full-length hashes in GH_TAGNAME
Full hashes avoid possible conflicts, at the cost of a small increase in
some path names.
About 1/3 of the existing GH_TAGNAMEs in the ports tree are already full
40-character hashes.
Reviewed by: bcr
Event: Halifax Hackathon 202606
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57901
porters-handbook: Freshen up example dates
Avoid looking like this document is over a decade old.
Reviewed by: jrm, bcr
Event: Halifax Hackathon 202606
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57900
Don't poll for large xfers when reading.
For this to be possible changes were made to mac68k/sbc(4) with respect to
pdma_in.
This results in a 50% performance gain.
Start pdma reading slowly.
This is done for the first 64 bytes. It ensures dse(4) returns available
data should XSCTL_POLL not be set for reading from the device.
There should be no performance penalty with this change.
[llubi] Add support for undef values (#205602)
Although we are planning to deprecate the undef value, it is still
widely used in the intermediate results of the pipeline, which blocks
the pass bisection. This patch uses `freeze poison` as a refinement of
undef.
Note that the undef value evaluates to different values each time the
user is executed. So it cannot be cached like other constants. A
temporary buffer is introduced to take ownership of these values and
avoid breaking the interface (although this is a bit ugly...). This will
also be used by a follow-up patch for ptrtoint/inttoptr.
From my experience, it is enough for test case reduction of middle-end
miscompilation bugs (there are still counterexamples like
https://github.com/dtcxzyw/llvm-autoreduce/issues/61). However, when
processing backend miscompilation bugs, lli typically uses a garbage
value, so that llvm-reduce may produce an invalid result. I think we may
need to introduce two flags to migrate this issue: one for poisoning
[5 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1284):
lib/libpthread/Makefile: revision 1.103
tests/lib/libpthread/dlopen/t_dso_pthread_create.c: revision 1.2
tests/lib/libpthread/dlopen/t_dlopen.c: revision 1.2
tests/lib/libpthread/dlopen/t_dlopen.c: revision 1.3
lib/libpthread/shlib_version: revision 1.24
tests/lib/libpthread: Test unloading libpthread after lazy binding.
If you dlopen libpthread and dlclose it again, the thread stubs like
pthread_mutex_lock need to continue working -- a library might have
calls to it in order to support thread-safety for threaded
applications, but that library needs to continue working even in
non-threaded applications after lazy binding of the libpthread symbol
instead of the libc stub.
PR lib/59784: dlopening and dlclosing libpthread is broken
[29 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #2016):
external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_mutex.h: revision 1.3
Fix StaticSpinMutex::CheckLocked() on sparc32.
The lock gets set with atomic_exchange() -> __sync_lock_test_and_set()
which sets the value to 255 instead of 1. Check for a taken lock
with "!= 0" instead of "== 1". This should work on all architectures.
Ok: Matthew Green
Pull up following revision(s) (requested by riastradh in ticket #2015):
sys/kern/kern_exec.c: revision 1.526
posix_spawn(2): Fix race between parent and child.
This was an embarrassing misuse of condition variables.
PR kern/59175: posix_spawn hang, hanging other process too
PR kern/52634: possible unhandled spurious wakeup in posix_spawn
(This only resolves one of the symptoms wiz had in PR 59175; there is
also another issue involved with p_vmspace and p_psstrp.)
Pull up following revision(s) (requested by riastradh in ticket #1283):
sys/kern/kern_exec.c: revision 1.526
posix_spawn(2): Fix race between parent and child.
This was an embarrassing misuse of condition variables.
PR kern/59175: posix_spawn hang, hanging other process too
PR kern/52634: possible unhandled spurious wakeup in posix_spawn
(This only resolves one of the symptoms wiz had in PR 59175; there is
also another issue involved with p_vmspace and p_psstrp.)
Pull up following revision(s) (requested by riastradh in ticket #1281):
sys/dev/pci/ld_virtio.c: revision 1.48 (patch)
ld at virtio: Guard virtio_dequeue by virtio_vq_is_enqueued.
After triggering the DMA operation, or any previous virtio_dequeue,
virtio_vq_is_enqueued issues the necessary bus_dmamap_sync for
virtio_dequeue to observe any potential (new) result.
Normally this happens inside virtio(4) (in virtio_vq_intr) between
interrupt delivery and calling the virtqueue's done callback. But
polling mode I/O operations (and dump operations) don't take that
path, so it is necessary to call virtio_vq_is_enqueued explicitly.
PR kern/60182: ld at virtio sometimes hangs up
