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

[Janne Blomqvist <blomqvist.janne@gmail.com>]

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?


-- 
Janne Blomqvist