[PATCH] Improve gen-libm-test.pl LIT() application

[PATCH] Improve gen-libm-test.pl LIT() application

[Paul E. Murphy]

When bootstrapping float128, this exposed a number of areas where
the L suffix is incorrectly applied to simple expressions when it
should be applied to each constant in the expression.

In order to stave off more macros in libm-test.inc, apply_lit is
made slightly more intelligent.  It will now split most basic
expressions and apply LIT() individually to each token.  As noted,
it is not a perfect solution, but compromises correctness,
readability, and simplicity.

The above is problematic when the L real suffix is not the most
expressive modifier, and the compiler complains (i.e ppc64) or
silently truncates a value (i.e ppc64).

	* math/gen-libm-test.pl (apply_lit): Rewrite to apply
	LIT() to individual constants in simple expressions.
	(_apply_lit): Rename replaced version, and use it to
	apply to what appears to be a token.
---
 math/gen-libm-test.pl | 40 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/math/gen-libm-test.pl b/math/gen-libm-test.pl
index aa66e76..cb0a02b 100755
--- a/math/gen-libm-test.pl
+++ b/math/gen-libm-test.pl
@@ -163,7 +163,7 @@ sub show_exceptions {
 
 # Apply the LIT(x) macro to a literal floating point constant
 # and strip any existing suffix.
-sub apply_lit {
+sub _apply_lit {
   my ($lit) = @_;
   my $exp_re = "([+-])?[[:digit:]]+";
   # Don't wrap something that does not look like a:
@@ -180,6 +180,44 @@ sub apply_lit {
   return "LIT (${lit})";
 }
 
+
+# Apply LIT macro to individual tokens within an
+# expression.  This is only meant to work with
+# the very simple expressions encountered like
+# A (op B)*.  It will not split all literals
+# correctly, but suffices for this usage without
+# a substantially more complex tokenizer.
+sub apply_lit {
+  my ($lit) = @_;
+  my @toks = ();
+
+  # There are some constant expressions embedded in the
+  # test cases.  To avoid writing a more complex lexer,
+  # we apply some fixups, and split based on simple
+  # operators, unfixup, then apply LIT as needed.
+
+  # This behaves poorly on inputs like 0x0e+1.0f,
+  # or MAX_EXP+1, but ultimately doesn't break
+  # anything... for now.
+  $lit =~ s/([[:xdigit:]])[pP]\+/$1,/g;
+  $lit =~ s/([[:xdigit:]])[pP]\-/$1#/g;
+  $lit =~ s/([0-9])[eE]\+/$1'/g;
+  $lit =~ s/([0-9])[eE]\-/$1"/g;
+
+  # Split into tokenish looking things
+  @toks = split (/([\*\-\+\/])/, $lit);
+
+  # Remove fixups and apply LIT() if needed.
+  foreach (@toks) {
+    $_ =~ s/,/p+/g;
+    $_ =~ s/#/p-/g;
+    $_ =~ s/'/e+/g;
+    $_ =~ s/"/e-/g;
+    $_ = _apply_lit ($_);
+  }
+  return join ('', @toks);
+}
+
 # Parse the arguments to TEST_x_y
 sub parse_args {
   my ($file, $descr, $args) = @_;
-- 
2.4.11

Re: [PATCH] Improve gen-libm-test.pl LIT() application

[Carlos O'Donell]

On 08/04/2016 11:05 AM, Paul E. Murphy wrote:
> When bootstrapping float128, this exposed a number of areas where
> the L suffix is incorrectly applied to simple expressions when it
> should be applied to each constant in the expression.
> 
> In order to stave off more macros in libm-test.inc, apply_lit is
> made slightly more intelligent.  It will now split most basic
> expressions and apply LIT() individually to each token.  As noted,
> it is not a perfect solution, but compromises correctness,
> readability, and simplicity.
> 
> The above is problematic when the L real suffix is not the most
> expressive modifier, and the compiler complains (i.e ppc64) or
> silently truncates a value (i.e ppc64).
> 
> 	* math/gen-libm-test.pl (apply_lit): Rewrite to apply
> 	LIT() to individual constants in simple expressions.
> 	(_apply_lit): Rename replaced version, and use it to
> 	apply to what appears to be a token.

This looks like a good compromise to me.

Question below.

> ---
>  math/gen-libm-test.pl | 40 +++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/math/gen-libm-test.pl b/math/gen-libm-test.pl
> index aa66e76..cb0a02b 100755
> --- a/math/gen-libm-test.pl
> +++ b/math/gen-libm-test.pl
> @@ -163,7 +163,7 @@ sub show_exceptions {
>  
>  # Apply the LIT(x) macro to a literal floating point constant
>  # and strip any existing suffix.
> -sub apply_lit {
> +sub _apply_lit {
>    my ($lit) = @_;
>    my $exp_re = "([+-])?[[:digit:]]+";
>    # Don't wrap something that does not look like a:
> @@ -180,6 +180,44 @@ sub apply_lit {
>    return "LIT (${lit})";
>  }
>  
> +
> +# Apply LIT macro to individual tokens within an
> +# expression.  This is only meant to work with
> +# the very simple expressions encountered like
> +# A (op B)*.  It will not split all literals
> +# correctly, but suffices for this usage without
> +# a substantially more complex tokenizer.

Is there any chance you can reject literals you won't correctly
split and raise an error?

> +sub apply_lit {
> +  my ($lit) = @_;
> +  my @toks = ();
> +
> +  # There are some constant expressions embedded in the
> +  # test cases.  To avoid writing a more complex lexer,
> +  # we apply some fixups, and split based on simple
> +  # operators, unfixup, then apply LIT as needed.
> +
> +  # This behaves poorly on inputs like 0x0e+1.0f,
> +  # or MAX_EXP+1, but ultimately doesn't break
> +  # anything... for now.

What do you mean by 'behaves poorly'? It looks like your
regexp's below handle it correctly.

> +  $lit =~ s/([[:xdigit:]])[pP]\+/$1,/g;
> +  $lit =~ s/([[:xdigit:]])[pP]\-/$1#/g;
> +  $lit =~ s/([0-9])[eE]\+/$1'/g;
> +  $lit =~ s/([0-9])[eE]\-/$1"/g;
> +
> +  # Split into tokenish looking things
> +  @toks = split (/([\*\-\+\/])/, $lit);
> +
> +  # Remove fixups and apply LIT() if needed.
> +  foreach (@toks) {
> +    $_ =~ s/,/p+/g;
> +    $_ =~ s/#/p-/g;
> +    $_ =~ s/'/e+/g;
> +    $_ =~ s/"/e-/g;
> +    $_ = _apply_lit ($_);
> +  }
> +  return join ('', @toks);
> +}
> +
>  # Parse the arguments to TEST_x_y
>  sub parse_args {
>    my ($file, $descr, $args) = @_;
> 


-- 
Cheers,
Carlos.

Re: [PATCH] Improve gen-libm-test.pl LIT() application

[Paul E. Murphy]

On 08/04/2016 11:02 AM, Carlos O'Donell wrote:
> On 08/04/2016 11:05 AM, Paul E. Murphy wrote:
>> When bootstrapping float128, this exposed a number of areas where
>> the L suffix is incorrectly applied to simple expressions when it
>> should be applied to each constant in the expression.
>>
>> In order to stave off more macros in libm-test.inc, apply_lit is
>> made slightly more intelligent.  It will now split most basic
>> expressions and apply LIT() individually to each token.  As noted,
>> it is not a perfect solution, but compromises correctness,
>> readability, and simplicity.
>>
>> The above is problematic when the L real suffix is not the most
>> expressive modifier, and the compiler complains (i.e ppc64) or
>> silently truncates a value (i.e ppc64).
>>
>> 	* math/gen-libm-test.pl (apply_lit): Rewrite to apply
>> 	LIT() to individual constants in simple expressions.
>> 	(_apply_lit): Rename replaced version, and use it to
>> 	apply to what appears to be a token.
> 
> This looks like a good compromise to me.
> 
> Question below.
> 
>> ---
>>  math/gen-libm-test.pl | 40 +++++++++++++++++++++++++++++++++++++++-
>>  1 file changed, 39 insertions(+), 1 deletion(-)
>>
>> diff --git a/math/gen-libm-test.pl b/math/gen-libm-test.pl
>> index aa66e76..cb0a02b 100755
>> --- a/math/gen-libm-test.pl
>> +++ b/math/gen-libm-test.pl
>> @@ -163,7 +163,7 @@ sub show_exceptions {
>>  
>>  # Apply the LIT(x) macro to a literal floating point constant
>>  # and strip any existing suffix.
>> -sub apply_lit {
>> +sub _apply_lit {
>>    my ($lit) = @_;
>>    my $exp_re = "([+-])?[[:digit:]]+";
>>    # Don't wrap something that does not look like a:
>> @@ -180,6 +180,44 @@ sub apply_lit {
>>    return "LIT (${lit})";
>>  }
>>  
>> +
>> +# Apply LIT macro to individual tokens within an
>> +# expression.  This is only meant to work with
>> +# the very simple expressions encountered like
>> +# A (op B)*.  It will not split all literals
>> +# correctly, but suffices for this usage without
>> +# a substantially more complex tokenizer.
> 
> Is there any chance you can reject literals you won't correctly
> split and raise an error?

As I understand it, the only incorrect splitting occurs for
some inputs of the form:

{integer, identifier} op {integer,real}

Which, will ultimately only apply LIT() to the expressions
containing a real value as the second operand.  But, LIT is
applied to the entire expression.

So you might end up passing things like "MAX_EXP+1", "0xe+1.0f"
to _apply_lit.  The former does happen, the latter is a
constructed example.

If more complicated expressions are used in libm-test.inc, or
this workaround proven insufficient, we should refactor
libm-test.inc to remove the need for this hack.

>> +sub apply_lit {
>> +  my ($lit) = @_;
>> +  my @toks = ();
>> +
>> +  # There are some constant expressions embedded in the
>> +  # test cases.  To avoid writing a more complex lexer,
>> +  # we apply some fixups, and split based on simple
>> +  # operators, unfixup, then apply LIT as needed.
>> +
>> +  # This behaves poorly on inputs like 0x0e+1.0f,
>> +  # or MAX_EXP+1, but ultimately doesn't break
>> +  # anything... for now.
> 
> What do you mean by 'behaves poorly'? It looks like your
> regexp's below handle it correctly.

They are ultimately handled correctly, but you could still
conceivably end up applying LIT to more than necessary.
I.e LIT(0xe+1.0) instead of 0xe+LIT(1.0).  MAX_EXP+1 is
vacuously correct as it never needs modification. 

I've yet to convince myself this solution is foolproof,
but it suffices for the current usage in libm-test.inc.

Re: [PATCH] Improve gen-libm-test.pl LIT() application

[Joseph Myers]

On Thu, 4 Aug 2016, Paul E. Murphy wrote:

> +  # This behaves poorly on inputs like 0x0e+1.0f,

0x0e+1.0f is a pp-number which is not valid to convert from a pp-token to 
a token.  So it should never occur in libm-test.inc in the first place and 
is not a useful example to give here.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] Improve gen-libm-test.pl LIT() application

[Carlos O'Donell]

On 08/04/2016 12:51 PM, Joseph Myers wrote:
> On Thu, 4 Aug 2016, Paul E. Murphy wrote:
> 
>> As I understand it, the only incorrect splitting occurs for
>> some inputs of the form:
>>
>> {integer, identifier} op {integer,real}
>>
>> Which, will ultimately only apply LIT() to the expressions
>> containing a real value as the second operand.  But, LIT is
>> applied to the entire expression.
>>
>> So you might end up passing things like "MAX_EXP+1", "0xe+1.0f"
>> to _apply_lit.  The former does happen, the latter is a
>> constructed example.
>>
>> If more complicated expressions are used in libm-test.inc, or
>> this workaround proven insufficient, we should refactor
>> libm-test.inc to remove the need for this hack.
> 
> How about putting spaces around the operators in libm-test.inc in all 
> cases where you need to split on operators, and then making the code split 
> on spaces rather than needing to do more complicated lexing and 
> substitutions to identify tokens?  Spaces should be present anyway in 
> accordance with the GNU Coding Standards.
 
+1

That's a good suggestion.

-- 
Cheers,
Carlos.

Re: [PATCH] Improve gen-libm-test.pl LIT() application

[Carlos O'Donell]

On 08/04/2016 12:45 PM, Paul E. Murphy wrote:
> 
> 
> On 08/04/2016 11:02 AM, Carlos O'Donell wrote:
>> On 08/04/2016 11:05 AM, Paul E. Murphy wrote:
>>> When bootstrapping float128, this exposed a number of areas where
>>> the L suffix is incorrectly applied to simple expressions when it
>>> should be applied to each constant in the expression.
>>>
>>> In order to stave off more macros in libm-test.inc, apply_lit is
>>> made slightly more intelligent.  It will now split most basic
>>> expressions and apply LIT() individually to each token.  As noted,
>>> it is not a perfect solution, but compromises correctness,
>>> readability, and simplicity.
>>>
>>> The above is problematic when the L real suffix is not the most
>>> expressive modifier, and the compiler complains (i.e ppc64) or
>>> silently truncates a value (i.e ppc64).
>>>
>>> 	* math/gen-libm-test.pl (apply_lit): Rewrite to apply
>>> 	LIT() to individual constants in simple expressions.
>>> 	(_apply_lit): Rename replaced version, and use it to
>>> 	apply to what appears to be a token.
>>
>> This looks like a good compromise to me.
>>
>> Question below.
>>
>>> ---
>>>  math/gen-libm-test.pl | 40 +++++++++++++++++++++++++++++++++++++++-
>>>  1 file changed, 39 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/math/gen-libm-test.pl b/math/gen-libm-test.pl
>>> index aa66e76..cb0a02b 100755
>>> --- a/math/gen-libm-test.pl
>>> +++ b/math/gen-libm-test.pl
>>> @@ -163,7 +163,7 @@ sub show_exceptions {
>>>  
>>>  # Apply the LIT(x) macro to a literal floating point constant
>>>  # and strip any existing suffix.
>>> -sub apply_lit {
>>> +sub _apply_lit {
>>>    my ($lit) = @_;
>>>    my $exp_re = "([+-])?[[:digit:]]+";
>>>    # Don't wrap something that does not look like a:
>>> @@ -180,6 +180,44 @@ sub apply_lit {
>>>    return "LIT (${lit})";
>>>  }
>>>  
>>> +
>>> +# Apply LIT macro to individual tokens within an
>>> +# expression.  This is only meant to work with
>>> +# the very simple expressions encountered like
>>> +# A (op B)*.  It will not split all literals
>>> +# correctly, but suffices for this usage without
>>> +# a substantially more complex tokenizer.
>>
>> Is there any chance you can reject literals you won't correctly
>> split and raise an error?
> 
> As I understand it, the only incorrect splitting occurs for
> some inputs of the form:
> 
> {integer, identifier} op {integer,real}
> 
> Which, will ultimately only apply LIT() to the expressions
> containing a real value as the second operand.  But, LIT is
> applied to the entire expression.
> 
> So you might end up passing things like "MAX_EXP+1", "0xe+1.0f"
> to _apply_lit.  The former does happen, the latter is a
> constructed example.
> 
> If more complicated expressions are used in libm-test.inc, or
> this workaround proven insufficient, we should refactor
> libm-test.inc to remove the need for this hack.

OK, agreed.

>>> +sub apply_lit {
>>> +  my ($lit) = @_;
>>> +  my @toks = ();
>>> +
>>> +  # There are some constant expressions embedded in the
>>> +  # test cases.  To avoid writing a more complex lexer,
>>> +  # we apply some fixups, and split based on simple
>>> +  # operators, unfixup, then apply LIT as needed.
>>> +
>>> +  # This behaves poorly on inputs like 0x0e+1.0f,
>>> +  # or MAX_EXP+1, but ultimately doesn't break
>>> +  # anything... for now.
>>
>> What do you mean by 'behaves poorly'? It looks like your
>> regexp's below handle it correctly.
> 
> They are ultimately handled correctly, but you could still
> conceivably end up applying LIT to more than necessary.
> I.e LIT(0xe+1.0) instead of 0xe+LIT(1.0).  MAX_EXP+1 is
> vacuously correct as it never needs modification. 
> 
> I've yet to convince myself this solution is foolproof,
> but it suffices for the current usage in libm-test.inc.
 
OK, please adjust the comment wording to say that instead
of "behaves poorly"

OK with that change, as long as you tested on x86_64 and
ppc64*.

-- 
Cheers,
Carlos.

Re: [PATCH] Improve gen-libm-test.pl LIT() application

[Joseph Myers]

On Thu, 4 Aug 2016, Paul E. Murphy wrote:

> As I understand it, the only incorrect splitting occurs for
> some inputs of the form:
> 
> {integer, identifier} op {integer,real}
> 
> Which, will ultimately only apply LIT() to the expressions
> containing a real value as the second operand.  But, LIT is
> applied to the entire expression.
> 
> So you might end up passing things like "MAX_EXP+1", "0xe+1.0f"
> to _apply_lit.  The former does happen, the latter is a
> constructed example.
> 
> If more complicated expressions are used in libm-test.inc, or
> this workaround proven insufficient, we should refactor
> libm-test.inc to remove the need for this hack.

How about putting spaces around the operators in libm-test.inc in all 
cases where you need to split on operators, and then making the code split 
on spaces rather than needing to do more complicated lexing and 
substitutions to identify tokens?  Spaces should be present anyway in 
accordance with the GNU Coding Standards.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] Improve gen-libm-test.pl LIT() application

[Paul E. Murphy]

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



On 08/04/2016 11:52 AM, Carlos O'Donell wrote:
> On 08/04/2016 12:51 PM, Joseph Myers wrote:
>> On Thu, 4 Aug 2016, Paul E. Murphy wrote:
>>
>>> As I understand it, the only incorrect splitting occurs for
>>> some inputs of the form:
>>>
>>> {integer, identifier} op {integer,real}
>>>
>>> Which, will ultimately only apply LIT() to the expressions
>>> containing a real value as the second operand.  But, LIT is
>>> applied to the entire expression.
>>>
>>> So you might end up passing things like "MAX_EXP+1", "0xe+1.0f"
>>> to _apply_lit.  The former does happen, the latter is a
>>> constructed example.
>>>
>>> If more complicated expressions are used in libm-test.inc, or
>>> this workaround proven insufficient, we should refactor
>>> libm-test.inc to remove the need for this hack.
>>
>> How about putting spaces around the operators in libm-test.inc in all 
>> cases where you need to split on operators, and then making the code split 
>> on spaces rather than needing to do more complicated lexing and 
>> substitutions to identify tokens?  Spaces should be present anyway in 
>> accordance with the GNU Coding Standards.
> 
> +1
> 
> That's a good suggestion.
> 

That works too.  Attached is an update patch.

I went through libm-test.pl with a regex looking for
[^pPeE ][\+\-\\\*] and fixed them by hand.  Likewise
for missing spaces after a comma. It still builds
and tests when used with the picky float128 support
on ppc64le.

[-- Attachment #2: 0001-Improve-gen-libm-test.pl-LIT-application.patch --]
[-- Type: text/x-patch, Size: 25261 bytes --]

From 2de5c39ecfdf87378744b20c731eea3b59052660 Mon Sep 17 00:00:00 2001
From: "Paul E. Murphy" <murphyp@linux.vnet.ibm.com>
Date: Fri, 15 Jul 2016 10:57:07 -0500
Subject: [PATCH] Improve gen-libm-test.pl LIT() application

When bootstrapping float128, this exposed a number of areas where
the L suffix is incorrectly applied to simple expressions when it
should be applied to each constant in the expression.

In order to stave off more macros in libm-test.inc, apply_lit is
made slightly more intelligent.  It will now split expressions
based on space characters, and attempt to apply LIT() to each
token.

Having done this, there are numerous spacing issues within
libm-test.inc which have been fixed.

The above is problematic when the L real suffix is not the most
expressive modifier, and the compiler complains (i.e ppc64) or
silently truncates a value (i.e ppc64).

	* math/gen-libm-test.pl (apply_lit): Rewrite to apply
	LIT() to individual constants in simple expressions
	after splitting on spaces.
	(_apply_lit): Rename replaced version, and use it to
	apply to what appears to be a token.

	* math/libm-test.inc: Fix many, many issues with
	spacing.
---
 math/gen-libm-test.pl |  17 +++++++-
 math/libm-test.inc    | 110 +++++++++++++++++++++++++-------------------------
 2 files changed, 71 insertions(+), 56 deletions(-)

diff --git a/math/gen-libm-test.pl b/math/gen-libm-test.pl
index aa66e76..577964c 100755
--- a/math/gen-libm-test.pl
+++ b/math/gen-libm-test.pl
@@ -163,7 +163,7 @@ sub show_exceptions {
 
 # Apply the LIT(x) macro to a literal floating point constant
 # and strip any existing suffix.
-sub apply_lit {
+sub _apply_lit {
   my ($lit) = @_;
   my $exp_re = "([+-])?[[:digit:]]+";
   # Don't wrap something that does not look like a:
@@ -180,6 +180,21 @@ sub apply_lit {
   return "LIT (${lit})";
 }
 
+# Apply LIT macro to individual tokens within an expression.
+#
+# This function assumes the C expression follows GNU coding
+# standards.  Specifically, a space separates each lexical
+# token.  Otherwise, this post-processing may apply LIT
+# incorrectly, or around an entire expression.
+sub apply_lit {
+  my ($lit) = @_;
+  my @toks = split (/ /, $lit);
+  foreach (@toks) {
+    $_ = _apply_lit ($_);
+  }
+  return join (' ', @toks);
+}
+
 # Parse the arguments to TEST_x_y
 sub parse_args {
   my ($file, $descr, $args) = @_;
diff --git a/math/libm-test.inc b/math/libm-test.inc
index 117057c..e4fcb5a 100644
--- a/math/libm-test.inc
+++ b/math/libm-test.inc
@@ -7214,7 +7214,7 @@ static const struct test_ff_f_data fdim_test_data[] =
 #endif
     TEST_ff_f (fdim, min_subnorm_value, min_subnorm_value, 0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_ff_f (fdim, -min_subnorm_value, -min_subnorm_value, 0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_ff_f (fdim, min_subnorm_value, -min_subnorm_value, 2*min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_ff_f (fdim, min_subnorm_value, -min_subnorm_value, 2 * min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_ff_f (fdim, min_value, min_value, 0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_ff_f (fdim, -min_value, -min_value, 0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_ff_f (fdim, max_value, max_value, 0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
@@ -7998,12 +7998,12 @@ static const struct test_f_f1_data frexp_test_data[] =
 #endif
 
 #if MANT_DIG >= 106
-    TEST_fI_f1 (frexp, 1.0L-0x1p-106L, 1.0L-0x1p-106L, 0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fI_f1 (frexp, 1.0L - 0x1p-106L, 1.0L - 0x1p-106L, 0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_fI_f1 (frexp, 1.0L, 0.5L, 1, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_fI_f1 (frexp, 1.0L+0x1p-105L, 0.5L+0x1p-106L, 1, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_fI_f1 (frexp, -1.0L+0x1p-106L, -1.0L+0x1p-106L, 0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fI_f1 (frexp, 1.0L + 0x1p-105L, 0.5L + 0x1p-106L, 1, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fI_f1 (frexp, -1.0L + 0x1p-106L, -1.0L + 0x1p-106L, 0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_fI_f1 (frexp, -1.0L, -0.5L, 1, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_fI_f1 (frexp, -1.0L-0x1p-105L, -0.5L-0x1p-106L, 1, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fI_f1 (frexp, -1.0L - 0x1p-105L, -0.5L - 0x1p-106L, 1, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 #endif
   };
 
@@ -8975,7 +8975,7 @@ static const struct test_f_l_data lrint_test_data[] =
 
     /* Test boundary conditions.  */
     /* 0x1FFFFF */
-    TEST_f_l (lrint, 2097151.0,2097151LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_l (lrint, 2097151.0, 2097151LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     /* 0x800000 */
     TEST_f_l (lrint, 8388608.0, 8388608LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     /* 0x1000000 */
@@ -9212,7 +9212,7 @@ static const struct test_f_L_data llrint_test_data[] =
 
     /* Test boundary conditions.  */
     /* 0x1FFFFF */
-    TEST_f_L (llrint, 2097151.0,2097151LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_L (llrint, 2097151.0, 2097151LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     /* 0x800000 */
     TEST_f_L (llrint, 8388608.0, 8388608LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     /* 0x1000000 */
@@ -9713,8 +9713,8 @@ static const struct test_f_l_data lround_test_data[] =
      * numbers between +-(2^52+1 and 2^53-1) are affected since they have the
      * rightmost bit set.  */
     /* +-(2^52+1)  */
-    TEST_f_l (lround, 0x1.0000000000001p+52,4503599627370497LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_f_l (lround, -0x1.0000000000001p+52,-4503599627370497LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_l (lround, 0x1.0000000000001p+52, 4503599627370497LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_l (lround, -0x1.0000000000001p+52, -4503599627370497LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     /* +-(2^53-1): Input is the last (positive and negative) incrementally
      * representable whole-number in the 'double' range that might round
      * erroneously.  */
@@ -9733,8 +9733,8 @@ static const struct test_f_l_data lround_test_data[] =
     /* As above, on PowerPC an exponent of '23' is the largest incrementally
      * representable sequence of whole-numbers in the 'float' range.
      * Likewise, numbers between +-(2^23+1 and 2^24-1) are affected.  */
-    TEST_f_l (lround, 0x1.000002p+23,8388609, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_f_l (lround, -0x1.000002p+23,-8388609, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_l (lround, 0x1.000002p+23, 8388609, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_l (lround, -0x1.000002p+23, -8388609, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_f_l (lround, 0x1.fffffep+23, 16777215, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_f_l (lround, -0x1.fffffep+23, -16777215, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 
@@ -9986,8 +9986,8 @@ static const struct test_f_L_data llround_test_data[] =
      * numbers between +-(2^52+1 and 2^53-1) are affected since they have the
      * rightmost bit set.  */
     /* +-(2^52+1)  */
-    TEST_f_L (llround, 0x1.0000000000001p+52,4503599627370497LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_f_L (llround, -0x1.0000000000001p+52,-4503599627370497LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_L (llround, 0x1.0000000000001p+52, 4503599627370497LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_L (llround, -0x1.0000000000001p+52, -4503599627370497LL, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     /* +-(2^53-1): Input is the last (positive and negative) incrementally
      * representable whole-number in the 'double' range that might round
      * erroneously.  */
@@ -10005,8 +10005,8 @@ static const struct test_f_L_data llround_test_data[] =
     /* As above, on PowerPC an exponent of '23' is the largest incrementally
      * representable sequence of whole-numbers in the 'float' range.
      * Likewise, numbers between +-(2^23+1 and 2^24-1) are affected.  */
-    TEST_f_L (llround, 0x1.000002p+23,8388609, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_f_L (llround, -0x1.000002p+23,-8388609, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_L (llround, 0x1.000002p+23, 8388609, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_L (llround, -0x1.000002p+23, -8388609, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_f_L (llround, 0x1.fffffep+23, 16777215, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_f_L (llround, -0x1.fffffep+23, -16777215, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 
@@ -10372,12 +10372,12 @@ static const struct test_ff_f_data nextafter_test_data[] =
     TEST_ff_f (nextafter, -0x0.fffffffep-16383L, 0.0L, -0x0.fffffffdfffffffep-16383L, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_ERANGE),
 #endif
 #if TEST_COND_ibm128
-    TEST_ff_f (nextafter, 1.0L, -10.0L, 1.0L-0x1p-106L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_ff_f (nextafter, 1.0L, 10.0L, 1.0L+0x1p-105L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_ff_f (nextafter, 1.0L-0x1p-106L, 10.0L, 1.0L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_ff_f (nextafter, -1.0L, -10.0L, -1.0L-0x1p-105L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_ff_f (nextafter, -1.0L, 10.0L, -1.0L+0x1p-106L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_ff_f (nextafter, -1.0L+0x1p-106L, -10.0L, -1.0L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_ff_f (nextafter, 1.0L, -10.0L, 1.0L - 0x1p-106L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_ff_f (nextafter, 1.0L, 10.0L, 1.0L + 0x1p-105L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_ff_f (nextafter, 1.0L - 0x1p-106L, 10.0L, 1.0L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_ff_f (nextafter, -1.0L, -10.0L, -1.0L - 0x1p-105L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_ff_f (nextafter, -1.0L, 10.0L, -1.0L + 0x1p-106L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_ff_f (nextafter, -1.0L + 0x1p-106L, -10.0L, -1.0L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 #endif
 #if TEST_COND_binary128
     TEST_ff_f (nextafter, 1.0L, 10.0L, 0x1.0000000000000000000000000001p0L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
@@ -10427,9 +10427,9 @@ static const struct test_f_f_data nextup_test_data[] =
     TEST_f_f (nextup, -0x0.fffffffep-16383L, -0x0.fffffffdfffffffep-16383L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 #endif
 #if TEST_COND_ibm128
-    TEST_f_f (nextup, 1.0L, 1.0L+0x1p-105L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_f_f (nextup, -1.0L-0x1p-105L, -1.0L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_f_f (nextup, -1.0L, -1.0L+0x1p-106L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_f (nextup, 1.0L, 1.0L + 0x1p-105L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_f (nextup, -1.0L - 0x1p-105L, -1.0L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_f (nextup, -1.0L, -1.0L + 0x1p-106L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 #endif
 #if TEST_COND_binary128
     TEST_f_f (nextup, 1.0L, 0x1.0000000000000000000000000001p0L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
@@ -10474,9 +10474,9 @@ static const struct test_f_f_data nextdown_test_data[] =
     TEST_f_f (nextdown, -0x0.fffffffdfffffffep-16383L, -0x0.fffffffep-16383L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 #endif
 #if TEST_COND_ibm128
-    TEST_f_f (nextdown, -1.0L, -1.0L-0x1p-105L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_f_f (nextdown, 1.0L+0x1p-105L, 1.0L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_f_f (nextdown, 1.0L, 1.0L-0x1p-106L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_f (nextdown, -1.0L, -1.0L - 0x1p-105L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_f (nextdown, 1.0L + 0x1p-105L, 1.0L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_f_f (nextdown, 1.0L, 1.0L - 0x1p-106L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 #endif
 #if TEST_COND_binary128
     TEST_f_f (nextdown, 1.0L, 0x1.ffffffffffffffffffffffffffffp-1L, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
@@ -11748,27 +11748,27 @@ static const struct test_fi_f_data scalbn_test_data[] =
     TEST_fi_f (scalbn, -min_value * 0x0.ffffp0, 0, -min_value * 0x0.ffffp0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_fi_f (scalbn, min_subnorm_value, 0, min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_fi_f (scalbn, -min_subnorm_value, 0, -min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_fi_f (scalbn, min_subnorm_value, MANT_DIG-1, min_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_fi_f (scalbn, -min_subnorm_value, MANT_DIG-1, -min_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fi_f (scalbn, min_subnorm_value, MANT_DIG - 1, min_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fi_f (scalbn, -min_subnorm_value, MANT_DIG - 1, -min_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 
-    TEST_fi_f (scalbn, min_value, -MANT_DIG+1, min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_fi_f (scalbn, -min_value, -MANT_DIG+1, -min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fi_f (scalbn, min_value, -MANT_DIG + 1, min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fi_f (scalbn, -min_value, -MANT_DIG + 1, -min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_fi_f (scalbn, min_value, -MANT_DIG, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
     TEST_fi_f (scalbn, -min_value, -MANT_DIG, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
-    TEST_fi_f (scalbn, min_value, -MANT_DIG-1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
-    TEST_fi_f (scalbn, -min_value, -MANT_DIG-1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
-    TEST_fi_f (scalbn, min_value * 1.5, -MANT_DIG+1, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
-    TEST_fi_f (scalbn, -min_value * 1.5, -MANT_DIG+1, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
+    TEST_fi_f (scalbn, min_value, -MANT_DIG - 1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
+    TEST_fi_f (scalbn, -min_value, -MANT_DIG - 1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
+    TEST_fi_f (scalbn, min_value * 1.5, -MANT_DIG + 1, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
+    TEST_fi_f (scalbn, -min_value * 1.5, -MANT_DIG + 1, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
     TEST_fi_f (scalbn, min_value * 1.5, -MANT_DIG, plus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, plus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
     TEST_fi_f (scalbn, -min_value * 1.5, -MANT_DIG, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, minus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, minus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
-    TEST_fi_f (scalbn, min_value * 1.5, -MANT_DIG-1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
-    TEST_fi_f (scalbn, -min_value * 1.5, -MANT_DIG-1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
-    TEST_fi_f (scalbn, min_value * 1.25, -MANT_DIG+1, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
-    TEST_fi_f (scalbn, -min_value * 1.25, -MANT_DIG+1, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
+    TEST_fi_f (scalbn, min_value * 1.5, -MANT_DIG - 1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
+    TEST_fi_f (scalbn, -min_value * 1.5, -MANT_DIG - 1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
+    TEST_fi_f (scalbn, min_value * 1.25, -MANT_DIG + 1, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
+    TEST_fi_f (scalbn, -min_value * 1.25, -MANT_DIG + 1, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
     TEST_fi_f (scalbn, min_value * 1.25, -MANT_DIG, plus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, plus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
     TEST_fi_f (scalbn, -min_value * 1.25, -MANT_DIG, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, minus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, minus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
-    TEST_fi_f (scalbn, min_value * 1.25, -MANT_DIG-1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
-    TEST_fi_f (scalbn, -min_value * 1.25, -MANT_DIG-1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
+    TEST_fi_f (scalbn, min_value * 1.25, -MANT_DIG - 1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
+    TEST_fi_f (scalbn, -min_value * 1.25, -MANT_DIG - 1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
 
     TEST_fi_f (scalbn, 1, INT_MAX, plus_oflow, INEXACT_EXCEPTION|OVERFLOW_EXCEPTION|ERRNO_PLUS_OFLOW),
     TEST_fi_f (scalbn, 1, INT_MIN, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
@@ -11832,27 +11832,27 @@ static const struct test_fl_f_data scalbln_test_data[] =
     TEST_fl_f (scalbln, -min_value * 0x0.ffffp0, 0, -min_value * 0x0.ffffp0, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_fl_f (scalbln, min_subnorm_value, 0, min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_fl_f (scalbln, -min_subnorm_value, 0, -min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_fl_f (scalbln, min_subnorm_value, MANT_DIG-1, min_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_fl_f (scalbln, -min_subnorm_value, MANT_DIG-1, -min_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fl_f (scalbln, min_subnorm_value, MANT_DIG - 1, min_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fl_f (scalbln, -min_subnorm_value, MANT_DIG - 1, -min_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 
-    TEST_fl_f (scalbln, min_value, -MANT_DIG+1, min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
-    TEST_fl_f (scalbln, -min_value, -MANT_DIG+1, -min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fl_f (scalbln, min_value, -MANT_DIG + 1, min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
+    TEST_fl_f (scalbln, -min_value, -MANT_DIG + 1, -min_subnorm_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
     TEST_fl_f (scalbln, min_value, -MANT_DIG, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
     TEST_fl_f (scalbln, -min_value, -MANT_DIG, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
-    TEST_fl_f (scalbln, min_value, -MANT_DIG-1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
-    TEST_fl_f (scalbln, -min_value, -MANT_DIG-1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
-    TEST_fl_f (scalbln, min_value * 1.5, -MANT_DIG+1, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
-    TEST_fl_f (scalbln, -min_value * 1.5, -MANT_DIG+1, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
+    TEST_fl_f (scalbln, min_value, -MANT_DIG - 1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
+    TEST_fl_f (scalbln, -min_value, -MANT_DIG - 1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
+    TEST_fl_f (scalbln, min_value * 1.5, -MANT_DIG + 1, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
+    TEST_fl_f (scalbln, -min_value * 1.5, -MANT_DIG + 1, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
     TEST_fl_f (scalbln, min_value * 1.5, -MANT_DIG, plus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, plus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
     TEST_fl_f (scalbln, -min_value * 1.5, -MANT_DIG, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, minus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, minus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
-    TEST_fl_f (scalbln, min_value * 1.5, -MANT_DIG-1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
-    TEST_fl_f (scalbln, -min_value * 1.5, -MANT_DIG-1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
-    TEST_fl_f (scalbln, min_value * 1.25, -MANT_DIG+1, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
-    TEST_fl_f (scalbln, -min_value * 1.25, -MANT_DIG+1, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
+    TEST_fl_f (scalbln, min_value * 1.5, -MANT_DIG - 1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
+    TEST_fl_f (scalbln, -min_value * 1.5, -MANT_DIG - 1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
+    TEST_fl_f (scalbln, min_value * 1.25, -MANT_DIG + 1, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
+    TEST_fl_f (scalbln, -min_value * 1.25, -MANT_DIG + 1, -min_subnorm_value * 2, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
     TEST_fl_f (scalbln, min_value * 1.25, -MANT_DIG, plus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, plus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
     TEST_fl_f (scalbln, -min_value * 1.25, -MANT_DIG, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, -min_subnorm_value, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, minus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION, minus_zero, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION),
-    TEST_fl_f (scalbln, min_value * 1.25, -MANT_DIG-1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
-    TEST_fl_f (scalbln, -min_value * 1.25, -MANT_DIG-1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
+    TEST_fl_f (scalbln, min_value * 1.25, -MANT_DIG - 1, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
+    TEST_fl_f (scalbln, -min_value * 1.25, -MANT_DIG - 1, minus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_MINUS_UFLOW),
 
     TEST_fl_f (scalbln, 1, INT_MAX, plus_oflow, INEXACT_EXCEPTION|OVERFLOW_EXCEPTION|ERRNO_PLUS_OFLOW),
     TEST_fl_f (scalbln, 1, INT_MIN, plus_uflow, INEXACT_EXCEPTION|UNDERFLOW_EXCEPTION|ERRNO_PLUS_UFLOW),
-- 
2.4.11

Re: [PATCH] Improve gen-libm-test.pl LIT() application

[Joseph Myers]

On Thu, 4 Aug 2016, Paul E. Murphy wrote:

> That works too.  Attached is an update patch.

This patch is OK.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] Improve gen-libm-test.pl LIT() application

[Paul E. Murphy]

On 08/04/2016 03:55 PM, Joseph Myers wrote:
> On Thu, 4 Aug 2016, Paul E. Murphy wrote:
> 
>> That works too.  Attached is an update patch.
> 
> This patch is OK.
> 

Committed as d4cf133.