The struct directly represents the properties of a pair of parentheses,
without forcing the human reader to decode any bitset. This makes it
easier to find the remaining bugs in the heuristic for determining the
kind of parentheses.
No functional change outside debug mode.
This fixes the Clang build, which failed with:
usr.bin/script/script.c:255:1: error:
function 'dooutput' could be declared with attribute 'noreturn'
[-Werror,-Wmissing-noreturn]
The solution is not elegant since it adds a small state machine inside
the parser state, but at least these states only depend on the sequence
of token types and not on any other part of the parser state.
Reported in PR#55453.
It is, and always has been, the caller's responsibility to ensure the
lock is initialized before it can be used -- otherwise the memory
could hold garbage; it is nonsensical to even attempt locking
operations on it before initialization.
So there's no need to issue explicit barriers here. The barrier
seems to have been introduced in sys/arch/alpha/alpha/lock_machdep.c
rev. 1.1 (since moved to inline asm in alpha/include/lock.h) and then
copied & pasted into several other architectures.
This doesn't mean you should use it! Mostly it's to document the
semantics to help understand existing uses, which should not
proliferate, and audit definitions.
- Eradicate last vestiges of mb_* barriers.
- In __cpu_simple_lock_init, omit needless barrier. It is the
caller's responsibility to ensure __cpu_simple_lock_init happens
before other operations on it anyway, so there was never any need
for a barrier here.
- In __cpu_simple_lock_try, leave comments about memory ordering
guarantees of the kernel's _atomic_cas_uint, which are inexplicably
different from the non-underscored atomic_cas_uint.
- In __cpu_simple_unlock, use membar_exit instead of mb_memory, and do
it unconditionally.
This ensures that in __cpu_simple_lock/.../__cpu_simple_unlock, all
memory operations in the ellipsis happen before the store that
releases the lock.
- On Octeon, the barrier was omitted altogether, which is a bug --
it needs to be there or else there is no happens-before relation
and whoever takes the lock next might see stale values stored or
even stomp over the unlocking CPU's delayed loads.
- On non-Octeon, the mb_memory was sync. Using membar_exit
preserves this.
XXX On Octeon, membar_exit only issues syncw -- this seems wrong,
only store-before-store and not load/store-before-store, unless the
CNMIPS architecture guarantees it is sufficient here like
SPARCv8/v9 PSO (`Partial Store Order').
- Leave an essay with citations about why we have an apparently
pointless syncw _after_ releasing a lock, to work around a design
bug^W^Wquirk in cnmips which sometimes buffers stores for hundreds
of thousands of cycles for fun unless you issue syncw.
via kn_selnext:
- klist_init()
- klist_fini()
- klist_insert()
- klist_remove()
These provide some API insulation from the implementation details of these
lists (but not completely; see vn_knote_attach() and vn_knote_detach()).
Currently just a wrapper around SLIST(9).
This will make it significantly easier to switch kn_selnext linkage
to a different kind of list.
The member names in struct parser_state are not trustworthy, for example
in_decl does not correspond to the intuitive definition of "inside a
declaration". To cope with this uncertainty, output the full state of
the parser state to the debug log, not only the changes. This helps to
track the inner state for small differences in the input, such as
between 'typedef enum { TA, TB } TT' and 'enum { EA, EB } ET'.
This hopefully helps in fixing PR#55453.
No functional change outside debug mode.
Stuff like libc's namespace.h, or atomic_op_namespace.h, which does
namespacing tricks like `#define atomic_cas_uint _atomic_cas_uint',
has to go at the top of each .c file. If it goes in the middle, it
might be too late to affect the declarations, and result in compile
errors.
I tripped over this by including <sys/atomic.h> in mips
<machine/lock.h>.
(Maybe we should create a new pthread_namespace.h file for the
purpose, but this'll do for now.)
Since job.c 1.83 from 2003-12-20, the command had been echoed even if
the target had the attribute '.SILENT'.
In sh-flags.exp, each removed 'echo' command is below a target name
matching the pattern 'opt-?j????-tgt-??s-cmd-?i?', which means that the
target was marked as silent, either through a global '.SILENT'
declaration or the command line option '-s' or the attribute '.SILENT'
on the target.
Reported by Alan Barrett in PR#45356.
dv_private belongs to the device itself, i.e., the child here.
This overwrote the child's softc pointer, causing all kinds of havoc;
if this worked it was by an amazing accident.
It is always initialized by config_devalloc before config_devlink
makes it visible to device iteration. No need to reach into private
autoconf internals.
At least on NetBSD, make cannot be fooled with an environment variable
having an empty name. When running '/usr/bin/env =undefined make', the
argument is parsed as a variable assignment, but putenv(3) refuses to
process an empty variable name. Calling execve(2) directly got a step
further, the kernel didn't filter '=undefined' from the environment
variables. But getenv(3) always returns NULL when querying the
environment variable with the empty name.
On other operating systems, things may be different. Trying to set an
environment variable with an empty name may cause errors in env(1),
putenv(3), execve(2), getenv(3) or other places, so don't add an
automatic test for now.
1. After loading self->pt_rwlocked, membar_enter() must not be
conditional on PTHREAD__ATOMIC_IS_MEMBAR because there is no
atomic r/m/w operation here which could imply the acquire barrier.
(This should maybe just be a load-acquire operation, but we don't
have atomic_load_acquire in userland at the moment -- TBD.)
2. Before storing thread->pt_rwlocked, must issue membar_exit() so
that this is a store-release operation -- except if we had just
done an atomic r/m/w and PTHREAD__ATOMIC_IS_MEMBAR is set, in
which case it can be elided.
The second membar_exit() added here might be safely hoisted out of
the loop but I'm not sure -- needs more analysis to prove that
would be safe.
rillig