On Tue, Nov 8, 2011 at 17:41, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
> Steve Kargl <s...@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
