of segments for I/O - this was supposed to allow MAXPHYS-size I/O even
with page offset, but actually ended up letting through I/O up to
MAXPHYS+PAGE_SIZE
the KASSERT(bcount < MAXPHYS) is kept as-is, since at that place the number
of segments should already be validated, so it's kernel bug if the size
is still too big there
fixes PR port-xen/56328 by Greg Oster
not needed for correctness.
Add the correct memory barriers to the gcc legacy __sync built-in
functions for atomic memory access. From the gcc documentation:
In most cases, these built-in functions are considered a full barrier.
That is, no memory operand is moved across the operation, either forward
or backward. Further, instructions are issued as necessary to prevent the
processor from speculating loads across the operation and from queuing
stores after the operation.
type __sync_lock_test_and_set (type *ptr, type value, ...)
This built-in function is not a full barrier, but rather an acquire
barrier. This means that references after the operation cannot move to
(or be speculated to) before the operation, but previous memory stores
may not be globally visible yet, and previous memory loads may not yet
be satisfied.
void __sync_lock_release (type *ptr, ...)
This built-in function is not a full barrier, but rather a release
barrier. This means that all previous memory stores are globally
visible, and all previous memory loads have been satisfied, but
following memory reads are not prevented from being speculated to
before the barrier.
Since cgram.y 1.325 from 2021-07-15, conditional expressions did not
accept a comma-expression in the then-branch anymore. In practice, this
is an edge case though since comma expressions are rare.
The grammar rule for assignment_expression is quite different from those
of the other expressions, for 2 reasons: first, its precedence is
right-to-left. Second, its left-hand side must be an lvalue, which
rules out all binary operators. K&R C even had a grammar rule named
'lvalue' for this purpose. Later C standards made the kinds of
expressions more fine-grained and used 'unary_expression' in this place.
Since cgram.y 1.325 from 2021-07-15, these are not needed anymore.
Strangely, neither yacc nor Bison warned about this redundancy.
No functional change, the grammar rules are the same as before.
This reduces the number of string comparisons for function names that
start with 'is' or 'to'.
The tests now cover function names that start with 'is' or 'to' but are
not one of the well-known functions from ctype.h. This removes the '*'
in the output from gcov.
No functional change.
The 9 shift/reduce conflicts were all internal to the grammar rule
begin_type_specifier_qualifier_list. Previously, there were two
possible ways to parse '__attribute__(()) const int':
1. '__attribute__(())' 'const int'
2. '__attribute__(()) const' 'int'
Both ways would produce the same result since __attribute__ has almost
no observable effects on the resulting type.
No functional change.
The __attribute__ after the enumerators will be fixed in a follow-up
commit since lint exits after the 5th syntax error in a translation
unit, which up to now shadowed the error messages about the enumerators.
jhigh