[4/5] Refactor tst-strtod-round.c

  On 05/16/2016 05:49 PM, Joseph Myers wrote:
> On Mon, 16 May 2016, Paul E. Murphy wrote:
> 
>> +   gcc -std=gnu11 -O2 -Wall -Wextra gen-tst-strtod-round.c -lmpfr
>> +     -o gen-tst-strtod-round
>> +
>> +   (use of current MPC and MPFR versions recommended) and run it as:
> 
> The reference to MPC can't be correct.  This program does not use MPC.

Indeed, unnecessary.  I forgot to remove that bit after grabbing it
from gen-auto-tst-libm-tests.c.

> 
> So far this message has reached the libc-alpha list twice (you don't see 
> it twice in the archives because it has the same message-id each time).  
> I've seen this issue before with large messages coming to libc-alpha from 
> IBM (many duplicate copies of them arrive on the list), as if there is 
> some problem with IBM's mail server timing out before sourceware accepts 
> the message, or something like that.  Please try to get that mail system 
> problem fixed.

Ugh.  Thanks for pointing that out.  That is annoying.  I'll try.
 
> A further refactoring will be needed for testing new types with existing 
> formats: constant suffixes will need to be added when the header is used, 
> rather than being included when it is generated, so that the generated 
> constants for binary128 can be used with either "L" or "f128" (well, "q" 
> absent GCC support for "f128") suffixes depending on the type 
> corresponding to that format.  Do you intend to do that in a separate 
> patch?

Yes, I intentionally have avoided float128 specific changes.  I was
planning on just adding another entry to the formats table of
gen-tst-strtod-round.c and regenerating.  But, on second thought, with
a few small changes to the generator, it is possible to make the
generated output fully type generic.  I've attached the change which
applies atop patch 5.
  

On Tue, 17 May 2016, Paul E. Murphy wrote:

> > So far this message has reached the libc-alpha list twice (you don't see 
> > it twice in the archives because it has the same message-id each time).  
> > I've seen this issue before with large messages coming to libc-alpha from 
> > IBM (many duplicate copies of them arrive on the list), as if there is 
> > some problem with IBM's mail server timing out before sourceware accepts 
> > the message, or something like that.  Please try to get that mail system 
> > problem fixed.
> 
> Ugh.  Thanks for pointing that out.  That is annoying.  I'll try.

It's *also* a good idea to omit large generated file changes from patch 
postings, unless they are important for the review.  (When constant 
suffixes are eliminated from auto-libm-test-out - desirable for the same 
reasons as for the present patch - that will rewrite the whole file - a > 
60MB diff - and you certainly don't want to send that to the list.)
  

On 05/17/2016 11:14 AM, Joseph Myers wrote:
> On Tue, 17 May 2016, Paul E. Murphy wrote:
> 
>>> So far this message has reached the libc-alpha list twice (you don't see 
>>> it twice in the archives because it has the same message-id each time).  
>>> I've seen this issue before with large messages coming to libc-alpha from 
>>> IBM (many duplicate copies of them arrive on the list), as if there is 
>>> some problem with IBM's mail server timing out before sourceware accepts 
>>> the message, or something like that.  Please try to get that mail system 
>>> problem fixed.
>>
>> Ugh.  Thanks for pointing that out.  That is annoying.  I'll try.
> 
> It's *also* a good idea to omit large generated file changes from patch 
> postings, unless they are important for the review.  (When constant 
> suffixes are eliminated from auto-libm-test-out - desirable for the same 
> reasons as for the present patch - that will rewrite the whole file - a > 
> 60MB diff - and you certainly don't want to send that to the list.)

Admittedly, my cutoff for "too big" was still too big.  Lesson learned.

Anyhow, for those tests, we do have the opportunity to post-process
the content as part of building the tests.  In that (yet to be submitted
to libc-alpha) patchset, I updated gen-libm-test.pl to strip C99 literal
suffixes, then wrap them with a new macro named LIT() to apply the
appropriate suffix depending on the type under test. With the exception
of nexttoward and its long double second argument.
  

On Tue, 17 May 2016, Paul E. Murphy wrote:

> Anyhow, for those tests, we do have the opportunity to post-process
> the content as part of building the tests.  In that (yet to be submitted
> to libc-alpha) patchset, I updated gen-libm-test.pl to strip C99 literal
> suffixes, then wrap them with a new macro named LIT() to apply the
> appropriate suffix depending on the type under test. With the exception
> of nexttoward and its long double second argument.

That seems reasonable (as in: eventually the logical format of 
auto-libm-test-out would be not to include the suffixes, but by removing 
the suffixes in gen-libm-test-pl you avoid the need for the large change 
until there's another reason for such a large change, e.g. for splitting 
up auto-libm-test-out into per-function files, which is something I want 
to do anyway both to reduce its size and to allow gen-auto-libm-tests to 
be used for complex functions for which MPC is extremely slow).  Of course 
all the constants in libm-test.inc and auto-libm-test-out for integer 
arguments and results should also be exceptions to getting suffixes added.

Presumably you deal with how some constants in libm-test.inc for 
floating-point arguments and results are integer constants that can't 
simply have a suffix added without adding "." as well to turn them into 
floating-point constants.  And all conditionals such as

#if defined TEST_LDOUBLE && LDBL_MAX_EXP >= 16384

need to be rewritten to check properties of the format, not macros such as 
TEST_LDOUBLE which say which type it is (in this case, testing MAX_EXP 
would suffice, but for tests of MANT_DIG, right now the MANT_DIG macro is 
confusingly *_MANT_DIG-1, so a simple substitution does not suffice 
without fixing MANT_DIG and its existing uses first to be less confusing).