Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers

[Paul Eggert <eggert@cs.ucla.edu>]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

Bruno Haible wrote:

> +   If you want the use of this macro to improve, not deteriorate,
> +   performance, R should not contain function calls except to functions
> +   that are declared 'inline __attribute__((__always_inline__))'.  */

A reader of that might incorrectly conclude that using such functions will 
always improve performance, compared to using functions not declared that way. 
And I'm leery of putting such GCC-specific info into the documentation of a 
generic macro.

Also, given Pip Cet's misunderstanding it'd be helpful to add a word or two 
about the intent of 'assume (R)'.

How about the attached patch?

 > -   evaluated.  Behavior is undefined if R is false.  */
 > +   evaluated.  The behavior is undefined if R is false.

This is a nit, but to my ears the shorter version is better, and has a 
more-accurate connotation as "the behavior" connotes "the behavior of 'assume 
(R)'", whereas behavior is also undefined for code before or after a call to an 
incorrect 'assume (R)'.

[-- Attachment #2: verify.diff --]
[-- Type: text/x-patch, Size: 800 bytes --]

diff --git a/lib/verify.h b/lib/verify.h
index f8e4eff02..168a7afdb 100644
--- a/lib/verify.h
+++ b/lib/verify.h
@@ -259,9 +259,11 @@ template <int w>
 # define __has_builtin(x) 0
 #endif
 
-/* Assume that R always holds.  This lets the compiler optimize
-   accordingly.  R should not have side-effects; it may or may not be
-   evaluated.  Behavior is undefined if R is false.  */
+/* Assume that R always holds.  Behavior is undefined if R is false.
+   R should lack side effects, as it may be evaluated only partially.
+   Although 'assume (R)' is typically intended to help performance,
+   performance may degrade if R uses hard-to-optimize features
+   such as calls to non-inlined functions.  */
 
 #if (__has_builtin (__builtin_unreachable) \
      || 4 < __GNUC__ + (5 <= __GNUC_MINOR__))