Update.

	* elf/dl-load.c: Fix typo in comment.  Add a few more __builtin_expect.

1 files changed, 20 insertions, 20 deletions

diff --git a/manual/lang.texi b/manual/lang.texi
index 9f5c540735..96f6d9df55 100644
--- a/manual/lang.texi
+++ b/manual/lang.texi
@@ -93,7 +93,7 @@ The @code{assert_perror} macro makes this easy.
 @deftypefn Macro void assert_perror (int @var{errnum})
 Similar to @code{assert}, but verifies that @var{errnum} is zero.
 
-If @code{NDEBUG} is defined, @code{assert_perror} tests the value of
+If @code{NDEBUG} is not defined, @code{assert_perror} tests the value of
 @var{errnum}.  If it is nonzero, @code{assert_perror} aborts the program
 after printing a message of the form:
 
@@ -121,12 +121,12 @@ reporting invalid input or improper usage by the @emph{user} of the
 program.
 
 The information in the diagnostic messages printed by the @code{assert}
-and @code{assert_perror} macro is intended to help you, the programmer, 
-track down the cause of a bug, but is not really useful for telling a user 
-of your program why his or her input was invalid or why a command could not 
-be carried out.  What's more, your program should not abort when given 
-invalid input, as @code{assert} would do---it should exit with nonzero 
-status (@pxref{Exit Status}) after printing its error messages, or perhaps 
+and @code{assert_perror} macro is intended to help you, the programmer,
+track down the cause of a bug, but is not really useful for telling a user
+of your program why his or her input was invalid or why a command could not
+be carried out.  What's more, your program should not abort when given
+invalid input, as @code{assert} would do---it should exit with nonzero
+status (@pxref{Exit Status}) after printing its error messages, or perhaps
 read another command or move on to the next input file.
 
 @xref{Error Messages}, for information on printing error messages for
@@ -253,8 +253,8 @@ func (const char *a, int b, @dots{})
 @end smallexample
 
 @noindent
-defines a function @code{func} which returns an @code{int} and takes two 
-required arguments, a @code{const char *} and an @code{int}.  These are 
+defines a function @code{func} which returns an @code{int} and takes two
+required arguments, a @code{const char *} and an @code{int}.  These are
 followed by any number of anonymous arguments.
 
 @strong{Portability note:} For some C compilers, the last required
@@ -299,9 +299,9 @@ values if you try to access too many arguments.
 You indicate that you are finished with the argument pointer variable by
 calling @code{va_end}.
 
-(In practice, with most C compilers, calling @code{va_end} does nothing.  
-This is always true in the GNU C compiler.  But you might as well call 
-@code{va_end} just in case your program is someday compiled with a peculiar 
+(In practice, with most C compilers, calling @code{va_end} does nothing.
+This is always true in the GNU C compiler.  But you might as well call
+@code{va_end} just in case your program is someday compiled with a peculiar
 compiler.)
 @end enumerate
 
@@ -338,8 +338,8 @@ regardless.
 
 There is no general way for a function to determine the number and type
 of the optional arguments it was called with.  So whoever designs the
-function typically designs a convention for the caller to specify the number 
-and type of arguments.  It is up to you to define an appropriate calling 
+function typically designs a convention for the caller to specify the number
+and type of arguments.  It is up to you to define an appropriate calling
 convention for each variadic function, and write all calls accordingly.
 
 One kind of calling convention is to pass the number of optional
@@ -463,7 +463,7 @@ Sometimes it is necessary to parse the list of parameters more than once
 or one wants to remember a certain position in the parameter list.  To
 do this, one will have to make a copy of the current value of the
 argument.  But @code{va_list} is an opaque type and one cannot necessarily
-assign the value of one variable of type @code{va_list} to another variable 
+assign the value of one variable of type @code{va_list} to another variable
 of the same type.
 
 @comment stdarg.h
@@ -479,7 +479,7 @@ the next update of the ISO C standard.
 @end deftypefn
 
 If you want to use @code{__va_copy} you should always be prepared for the
-possibility that this macro will not be available.  On architectures where a 
+possibility that this macro will not be available.  On architectures where a
 simple assignment is invalid, hopefully @code{__va_copy} @emph{will} be available,
 so one should always write something like this:
 
@@ -952,10 +952,10 @@ low-level aspects of the representation.
 @end itemize
 
 The mantissa of a floating point number represents an implicit fraction
-whose denominator is the base raised to the power of the precision.  Since 
-the largest representable mantissa is one less than this denominator, the 
-value of the fraction is always strictly less than @code{1}.  The 
-mathematical value of a floating point number is then the product of this 
+whose denominator is the base raised to the power of the precision.  Since
+the largest representable mantissa is one less than this denominator, the
+value of the fraction is always strictly less than @code{1}.  The
+mathematical value of a floating point number is then the product of this
 fraction, the sign, and the base raised to the exponent.
 
 @cindex normalized floating point number