[Fortran,committed] Add libquadmath testcase gfortran.dg/quad_2.f90

Motivated by the report at  
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/6373a2dfe64f0b83

There is currently no run-test check that libquadmath actually works. 
The attached and committed (Rev. 181015) adds one which tests for 
libquadmath that I/O read/write works. Additionally, it checks that the 
result for sqrt(2.0) is OK.

The test uses the largest available floating-point number - be it 8, 10 
or 16 - and tests for that. The checks should be thus OK for any system.

Regarding the issue mentioned in the linked report: Kai could reproduce 
the issue - he also gets "0.0" under MinGW64 with the current trunk. 
(The report was for MinGW32 4.7.0 and allegedly it worked for 4.6.2.)

Tobias

> The test uses the largest available floating-point number - be it 8, 10
> or 16 - and tests for that. The checks should be thus OK for any system.

It fails with a link failure on SPARC Solaris 8 and 9:

FAIL: gfortran.dg/quad_2.f90  -O0  (test for excess errors)
Excess errors:
Undefined                       first referenced
 symbol                             in file
sqrtl                               /var/tmp//ccU7N9qc.o
ld: fatal: Symbol referencing errors. No output written to ./quad_2.exe

On Mon, Nov 07, 2011 at 09:55:48PM +0100, Eric Botcazou wrote:
> > The test uses the largest available floating-point number - be it 8, 10
> > or 16 - and tests for that. The checks should be thus OK for any system.
> 
> It fails with a link failure on SPARC Solaris 8 and 9:
> 
> FAIL: gfortran.dg/quad_2.f90  -O0  (test for excess errors)
> Excess errors:
> Undefined                       first referenced
>  symbol                             in file
> sqrtl                               /var/tmp//ccU7N9qc.o
> ld: fatal: Symbol referencing errors. No output written to ./quad_2.exe

I suppose the obvious question is 'does libm on sparc solaris 8/9
contain a long double sqrtl() function?'  If the answer is no,
then xfail the testcase.

Steve Kargl <sgk@troutmask.apl.washington.edu> writes:

> On Mon, Nov 07, 2011 at 09:55:48PM +0100, Eric Botcazou wrote:
>> > The test uses the largest available floating-point number - be it 8, 10
>> > or 16 - and tests for that. The checks should be thus OK for any system.
>> 
>> It fails with a link failure on SPARC Solaris 8 and 9:
>> 
>> FAIL: gfortran.dg/quad_2.f90  -O0  (test for excess errors)
>> Excess errors:
>> Undefined                       first referenced
>>  symbol                             in file
>> sqrtl                               /var/tmp//ccU7N9qc.o
>> ld: fatal: Symbol referencing errors. No output written to ./quad_2.exe
>
> I suppose the obvious question is 'does libm on sparc solaris 8/9
> contain a long double sqrtl() function?'  If the answer is no,
> then xfail the testcase.

Please no: sqrtl is a C99 addition, and we don't want lists of non-C99
targets in tests that require them.

	Rainer

On Tue, Nov 08, 2011 at 11:14:52AM +0100, Rainer Orth wrote:
> Steve Kargl <sgk@troutmask.apl.washington.edu> writes:
> 
> > On Mon, Nov 07, 2011 at 09:55:48PM +0100, Eric Botcazou wrote:
> >> > The test uses the largest available floating-point number - be it 8, 10
> >> > or 16 - and tests for that. The checks should be thus OK for any system.
> >> 
> >> It fails with a link failure on SPARC Solaris 8 and 9:
> >> 
> >> FAIL: gfortran.dg/quad_2.f90  -O0  (test for excess errors)
> >> Excess errors:
> >> Undefined                       first referenced
> >>  symbol                             in file
> >> sqrtl                               /var/tmp//ccU7N9qc.o
> >> ld: fatal: Symbol referencing errors. No output written to ./quad_2.exe
> >
> > I suppose the obvious question is 'does libm on sparc solaris 8/9
> > contain a long double sqrtl() function?'  If the answer is no,
> > then xfail the testcase.
> 
> Please no: sqrtl is a C99 addition, and we don't want lists of non-C99
> targets in tests that require them.
> 

OK, so, then we simply accept that running a regression test
on these targets will always FAIL?  If the answer is 'yes',
then please close this PR because I doubt anyone will implement
sqrtl().

Steve Kargl <sgk@troutmask.apl.washington.edu> writes:

>> Please no: sqrtl is a C99 addition, and we don't want lists of non-C99
>> targets in tests that require them.
>> 
>
> OK, so, then we simply accept that running a regression test
> on these targets will always FAIL?  If the answer is 'yes',
> then please close this PR because I doubt anyone will implement
> sqrtl().

No.  AFAICS so far C99 functions have been implemented in
intrinsics/c99_functions.c for the benefit of platforms that aren't
C99.  Has this policy changed recently?  

I don't think it's a good idea for libgfortran to contain references to
nonexistant functions (or for gfortran to emit references to C99
functions on non-C99 platforms, if that's the case).  At least that's
not what any other GCC language frontend does.

	Rainer

On Tue, Nov 8, 2011 at 17:41, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> Steve Kargl <sgk@troutmask.apl.washington.edu> writes:
>
>>> Please no: sqrtl is a C99 addition, and we don't want lists of non-C99
>>> targets in tests that require them.
>>>
>>
>> OK, so, then we simply accept that running a regression test
>> on these targets will always FAIL?  If the answer is 'yes',
>> then please close this PR because I doubt anyone will implement
>> sqrtl().
>
> No.  AFAICS so far C99 functions have been implemented in
> intrinsics/c99_functions.c for the benefit of platforms that aren't
> C99.  Has this policy changed recently?

I don't think there has ever been a such a hard policy. Yes,
c99_functions.c provides _some_ C99 functions when they can be
implemented in terms of other available functions. E.g. sqrtf() is
provided by

#ifndef HAVE_SQRTF
#define HAVE_SQRTF 1
float sqrtf (float x);

float
sqrtf (float x)
{
  return (float) sqrt (x);
}
#endif

Obviously, sqrtl() could be provided in the same way using the C89
sqrt(), but I'm sure we all agree that would be a pretty crappy
implementation. I think it's better to leave it out than to give users
a false impression that they have a functioning sqrtl.

> I don't think it's a good idea for libgfortran to contain references to
> nonexistant functions (or for gfortran to emit references to C99
> functions on non-C99 platforms, if that's the case).  At least that's
> not what any other GCC language frontend does.

So what would be a good solution then, assuming Santa doesn't suddenly
provide us with a target-independent C99 math library? One solution, I
suppose, would be to not support real(kind=10) (C long double) on
non-C99 targets. Do we have some mechanism for determining this when
building the frontend?

On Tue, Nov 08, 2011 at 04:41:32PM +0100, Rainer Orth wrote:
> Steve Kargl <sgk@troutmask.apl.washington.edu> writes:
> 
> >> Please no: sqrtl is a C99 addition, and we don't want lists of non-C99
> >> targets in tests that require them.
> >> 
> >
> > OK, so, then we simply accept that running a regression test
> > on these targets will always FAIL?  If the answer is 'yes',
> > then please close this PR because I doubt anyone will implement
> > sqrtl().
> 
> No.  AFAICS so far C99 functions have been implemented in
> intrinsics/c99_functions.c for the benefit of platforms that aren't
> C99.  Has this policy changed recently?  

The policy has not changed.  However, it took me >3 years to
get an implementation of sqrtl() into FreeBSD's libm.  On the
surface, sqrtl() looks almost trivial to implement, but the
IEEE 754 requirement of correct rounding in all rounding modes
can be a nightmare to get right.  Adopting FreeBSD sqrtl() has
some issues.

> I don't think it's a good idea for libgfortran to contain references to
> nonexistant functions (or for gfortran to emit references to C99
> functions on non-C99 platforms, if that's the case).  At least that's
> not what any other GCC language frontend does.

AFAIK, gfortran has always assumed that it is being built/run on
a system with C99 functions.  If one does not care about correct
rounding, then one can do

#include <math.h>

long double
sqrtl(long double x)
{

  if (x == 0) return x;

  if (x < 0) return ((x - x) / (x - x));

  if (isfinite(x)) 
    {
       reduce x to 2*f*2**n.
       check if x is subnormal and adjust f and n.
       if (n is odd)
         {
            f = 2*f;
			n--;
         }
       use Newtow's iteration to compute sqrtl(f) with a
       starting value of xn = sqrt(f)

       now combine everything return (xn*2**(n/2))
    }
  else
    return (x * x + x);
 
}