Also for ia64, riscv64, sh3e{bl}, and sparc for sure, but
nothing changed.
XXX
mknative adds something like
-I/usr/src/tools/gdb/obj.machine-arch/.native/include
to include path. This should be dropped...
there's a 1-element long array and a loop conditional that tries to see
if indexes for it are not identical. as these indexes will always both
be 0, the only valid index, the condition is always false. GCC 12
triggers a strange warning on this code that can never run (see below),
so simply assert the array size is 1 and comment the rest.
amdgpu_dc_stream.c:470:55: error: array subscript [0, 0] is outside array bounds of 'struct dc_writeback_info[1]' [-Werror=array-bounds]
470 | stream->writeback_info[j] = stream->writeback_info[i];
earmv5{,eb}:
- No new regression for full ATF.
m68k:
- blake2_prov.c needs -fno-stack-protector.
- No new regression for full ATF on amiga.
sh3el:
- In addition to kernel, userland is completely broken.
- No interesting diff with upstream in gcc/config/sh.
- Probably, we need bisectioning for GCC...
The installimage sizes were bumped in 2022 because of some growth, and
the case for not-xz sets went to 4000 (MiB). That's just over what a
lot of "4 GB" flash drives are, but seems obviously intended to fit.
The actual usage of the filesystem, from a current build from earlier
this year (with non-xz sets) is:
/dev/dk1 3.7G 833M 2.7G 23% /mnt
and similar for netbsd-10 built yesterday, so we can afford to shrink
slightly. Drop to 3800, which is still huge, but will make 4 GB flash
drives work.
this code seems broken. hash_table_del() is called on a ptr that was
either just freed (realloc() case) or will be freed (xfree_impl() case),
but in both cases hash_table_del() will free() the same address. for
the realloc() case, as it's after free(), it's UB. for the xfree_impl()
case, it can be solved by not free()ing here.
When a thread takes a page fault which results in COW resolution,
other threads in the same process can be concurrently accessing that
same mapping on other CPUs. When the faulting thread updates the pmap
entry at the end of COW processing, the resulting TLB invalidations to
other CPUs are not done atomically, so another thread can write to the
new writable page and then a third thread might still read from the
old read-only page, resulting in inconsistent views of the page by the
latter two threads. Fix this by removing the pmap entry entirely for
the original page before we install the new pmap entry for the new
page, so that the new page can only be modified after the old page is
no longer accessible.
This fixes PR 56535 as well as the netbsd versions of problems
described in various bug trackers:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584https://reviews.freebsd.org/D14347https://github.com/golang/go/issues/34988
rin