«

[Joining comp.lang.c now... For context, see the failure stats of
Numeric-LL_Array-0.04 on
http://www.cpantesters.org/distro/N/...rray.html#0.04
(I remember seeing a color-coded version of the matrix given below; where?),
or one report on
http://www.nntp.perl.org/group/perl....sg3725590.html
]

On 2009-06-17, Keith Thompson <kst-> wrote:
> I haven't tried all possible combinations of options. With the
> following trivial program:
>
> #include <stdio.h>
> #include <math.h>
> int main(void)
> {
> printf("%Lf\n", sinl(1.0L));
> return 0;
> }

I found a BSD machine on the department network; it gives

blue2:/tmp/iz/Numeric-LL_Array-0.04->gcc -std=c99 -Wall -o c c.c -lm
aa.c: In function 'main':
aa.c:5: warning: implicit declaration of function 'sinl'
aa.c:5: warning: incompatible implicit declaration of built-in function 'sinl'
/var/tmp//ccXLekMc.o(.text+0x2c): In function `main': : undefined reference to `sinl'
Exit 1

(of course, without -std=c99 one gets the same result)... So, does
not BSD's gcc look completely broken?

$ uname -a
FreeBSD blue2.math.berkeley.edu 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Thu Feb 5 08:39:48 PST 2009 :/math/blue4/FreeBSD/obj/math/blue4/FreeBSD/FreeBSD-7.1/src/sys/NETATALK i386
$ gcc -v
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]

================================================== =====

Perusing `-E -dD', I see that /usr/include/math.h is used; it has a
lot of `#if 0':

/*
* long double versions of ISO/POSIX math functions
*/
#if __ISO_C_VISIBLE >= 1999
#if 0
long double acoshl(long double);
long double acosl(long double);
long double asinhl(long double);
long double asinl(long double);
long double atan2l(long double, long double);
long double atanhl(long double);
long double atanl(long double);
long double cbrtl(long double);
#endif
long double ceill(long double);
long double copysignl(long double, long double) __pure2;
...

Do not know whether they explain anything, or not...

Thanks,
Ilya

On 2009-06-17, Ilya Zakharevich <nospam-> wrote:
> [Joining comp.lang.c now... For context, see the failure stats of
> Numeric-LL_Array-0.04 on
> http://www.cpantesters.org/distro/N/...rray.html#0.04
> (I remember seeing a color-coded version of the matrix given below; where?),
> or one report on
> http://www.nntp.perl.org/group/perl....sg3725590.html
> ]

Aha, the colored matrix is on

http://matrix.cpantesters.org/?dist=...-LL_Array+0.04

It makes the problem more clear...

Ilya

Ilya Zakharevich <nospam-> writes:
> [Joining comp.lang.c now... For context, see the failure stats of
> Numeric-LL_Array-0.04 on
> http://www.cpantesters.org/distro/N/...rray.html#0.04
> (I remember seeing a color-coded version of the matrix given below; where?),
> or one report on
> http://www.nntp.perl.org/group/perl....sg3725590.html
> ]
>
> On 2009-06-17, Keith Thompson <kst-> wrote:
>> I haven't tried all possible combinations of options. With the
>> following trivial program:
>>
>> #include <stdio.h>
>> #include <math.h>
>> int main(void)
>> {
>> printf("%Lf\n", sinl(1.0L));
>> return 0;
>> }
>
> I found a BSD machine on the department network; it gives
>
> blue2:/tmp/iz/Numeric-LL_Array-0.04->gcc -std=c99 -Wall -o c c.c -lm
> aa.c: In function 'main':
> aa.c:5: warning: implicit declaration of function 'sinl'
> aa.c:5: warning: incompatible implicit declaration of built-in function 'sinl'
> /var/tmp//ccXLekMc.o(.text+0x2c): In function `main': : undefined reference to `sinl'
> Exit 1
>
> (of course, without -std=c99 one gets the same result)... So, does
> not BSD's gcc look completely broken?

gcc is probably doing exactly what it should be doing. As I mentioned
upthread (but not here in comp.lang.c), sinl() is provided by the
runtime library, not by the compiler. It looks liike FreeBSD's
runtime library doesn't provide sinl().

[...]

> Perusing `-E -dD', I see that /usr/include/math.h is used; it has a
> lot of `#if 0':
>
> /*
> * long double versions of ISO/POSIX math functions
> */
> #if __ISO_C_VISIBLE >= 1999
> #if 0
> long double acoshl(long double);
> long double acosl(long double);
> long double asinhl(long double);
> long double asinl(long double);
> long double atan2l(long double, long double);
> long double atanhl(long double);
> long double atanl(long double);
> long double cbrtl(long double);
> #endif
> long double ceill(long double);
> long double copysignl(long double, long double) __pure2;
> ...
>
> Do not know whether they explain anything, or not...

Well, the "#if 0" certainly explains why gcc complains about an
implicit declaration of sinl, since the explicit declaration doesn't
exist. I presume the math.h header file and the library are from the
same source and are consistent with each other.

As far as C is concerned, all that can really be said is the
following:

The C90 standard doesn't define the sinl function, but it does reserve
the identifier for future use.

The C99 standard does define the sinl function, so any conforming C99
implementation must provide it. Note that an implementation includes
both the compiler and the runtime library, which may be provided
seaprately. Note also that there are not yet very many conforming C99
implementations. (But gcc is perfectly able to use sinl if the
library provides it.)

I'd say this is a FreeBSD issue, not a C issue. Possibly whatever
code you're working with needs to be configurable so it will work on
systems that don't provide sinl.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Jun 17, 4:46*pm, Keith Thompson <ks...@mib.org> wrote:
> Ilya Zakharevich <nospam-ab...@ilyaz.org> writes:
> > [Joining comp.lang.c now... *For context, see the failure stats of
> > *Numeric-LL_Array-0.04 on
> > *http://www.cpantesters.org/distro/N/...rray.html#0.04
> > *(I remember seeing a color-coded version of the matrix given below; where?),
> > *or one report on
> > *http://www.nntp.perl.org/group/perl....sg3725590.html
> > ]
>
> > On 2009-06-17, Keith Thompson <ks...@mib.org> wrote:
> >> I haven't tried all possible combinations of options. *With the
> >> following trivial program:
>
> >> #include <stdio.h>
> >> #include <math.h>
> >> int main(void)
> >> { *
> >> * * printf("%Lf\n", sinl(1.0L));
> >> * * return 0;
> >> }
>
> > I found a BSD machine on the department network; it gives
>
> > * blue2:/tmp/iz/Numeric-LL_Array-0.04->gcc -std=c99 -Wall -o c c.c -lm
> > * aa.c: In function 'main':
> > * aa.c:5: warning: implicit declaration of function 'sinl'
> > * aa.c:5: warning: incompatible implicit declaration of built-in function 'sinl'
> > * /var/tmp//ccXLekMc.o(.text+0x2c): In function `main': : undefined reference to `sinl'
> > * Exit 1
>
> > (of course, without -std=c99 one gets the same result)... *So, does
> > not BSD's gcc look completely broken?
>
> gcc is probably doing exactly what it should be doing. *As I mentioned
> upthread (but not here in comp.lang.c), sinl() is provided by the
> runtime library, not by the compiler. *It looks liike FreeBSD's
> runtime library doesn't provide sinl().

Aside to the OP:
You can fill out the missing functions with the Cephes library:
http://www.moshier.net/#Cephes
assuming that the long double type is suppored by the compiler as
distinct from double.

If sizeof(long double) == 8 then it won't help. If it's bigger than
that, then it will.
The Cephes library has support for {among other things} 80 and 128 bit
long double.

[snip]

On 2009-06-17, Keith Thompson <kst-> wrote:
>> blue2:/tmp/iz/Numeric-LL_Array-0.04->gcc -std=c99 -Wall -o c c.c -lm
>> aa.c: In function 'main':
>> aa.c:5: warning: implicit declaration of function 'sinl'
>> aa.c:5: warning: incompatible implicit declaration of built-in function 'sinl'
>> /var/tmp//ccXLekMc.o(.text+0x2c): In function `main': : undefined reference to `sinl'
>> Exit 1
>>
>> (of course, without -std=c99 one gets the same result)... So, does
>> not BSD's gcc look completely broken?
>
> gcc is probably doing exactly what it should be doing. As I mentioned
> upthread (but not here in comp.lang.c), sinl() is provided by the
> runtime library, not by the compiler.

??? What part of "builtin function" is not clear?

> It looks liike FreeBSD's runtime library doesn't provide sinl().

Not surprising, if it is builtin (which, in turn, is not surprising if
on i386, and long double is 80-bit). But somehow it is not 'activated'...

> exist. I presume the math.h header file and the library are from the
> same source and are consistent with each other.

I know no way to check for this...

Thanks,
Ilya

Keith Thompson <kst-> writes:
> Ilya Zakharevich <nospam-> writes:
>> [Joining comp.lang.c now... For context, see the failure stats of
>> Numeric-LL_Array-0.04 on
>> http://www.cpantesters.org/distro/N/...rray.html#0.04
>> (I remember seeing a color-coded version of the matrix given below; where?),
>> or one report on
>> http://www.nntp.perl.org/group/perl....sg3725590.html
>> ]
>>
>> On 2009-06-17, Keith Thompson <kst-> wrote:
>>> I haven't tried all possible combinations of options. With the
>>> following trivial program:
>>>
>>> #include <stdio.h>
>>> #include <math.h>
>>> int main(void)
>>> {
>>> printf("%Lf\n", sinl(1.0L));
>>> return 0;
>>> }
>>
>> I found a BSD machine on the department network; it gives
>>
>> blue2:/tmp/iz/Numeric-LL_Array-0.04->gcc -std=c99 -Wall -o c c.c -lm
>> aa.c: In function 'main':
>> aa.c:5: warning: implicit declaration of function 'sinl'
>> aa.c:5: warning: incompatible implicit declaration of built-in function 'sinl'
>> /var/tmp//ccXLekMc.o(.text+0x2c): In function `main': : undefined reference to `sinl'
>> Exit 1
>>
>> (of course, without -std=c99 one gets the same result)... So, does
>> not BSD's gcc look completely broken?
>
> gcc is probably doing exactly what it should be doing.

?!??!?!

[...]

> The C99 standard does define the sinl function, so any conforming C99
> implementation must provide it.

So gcc, with the c99 switch, is *not* what doing what it should be
doing then?

Phil
--
Marijuana is indeed a dangerous drug.
It causes governments to wage war against their own people.
-- Dave Seaman (sci.math, 19 Mar 2009)

Phil Carmody wrote:
> Keith Thompson <kst-> writes:
>> Ilya Zakharevich <nospam-> writes:
>>> [Joining comp.lang.c now... For context, see the failure stats of
>>> Numeric-LL_Array-0.04 on
>>> http://www.cpantesters.org/distro/N/...rray.html#0.04
>>> (I remember seeing a color-coded version of the matrix given below; where?),
>>> or one report on
>>> http://www.nntp.perl.org/group/perl....sg3725590.html
>>> ]
>>>
>>> On 2009-06-17, Keith Thompson <kst-> wrote:
>>>> I haven't tried all possible combinations of options. With the
>>>> following trivial program:
>>>>
>>>> #include <stdio.h>
>>>> #include <math.h>
>>>> int main(void)
>>>> {
>>>> printf("%Lf\n", sinl(1.0L));
>>>> return 0;
>>>> }
>>> I found a BSD machine on the department network; it gives
>>>
>>> blue2:/tmp/iz/Numeric-LL_Array-0.04->gcc -std=c99 -Wall -o c c.c -lm
>>> aa.c: In function 'main':
>>> aa.c:5: warning: implicit declaration of function 'sinl'
>>> aa.c:5: warning: incompatible implicit declaration of built-in function 'sinl'
>>> /var/tmp//ccXLekMc.o(.text+0x2c): In function `main': : undefined reference to `sinl'
>>> Exit 1
>>>
>>> (of course, without -std=c99 one gets the same result)... So, does
>>> not BSD's gcc look completely broken?
>> gcc is probably doing exactly what it should be doing.
>
> ?!??!?!
>
> [...]
>
>> The C99 standard does define the sinl function, so any conforming C99
>> implementation must provide it.
>
> So gcc, with the c99 switch, is *not* what doing what it should be
> doing then?
>
> Phil

(1) gcc is always right.
(2) If you find a bug in gcc then goto (1)

Phil Carmody <> writes:
> Keith Thompson <kst-> writes:
>> Ilya Zakharevich <nospam-> writes:
[...]
>>> (of course, without -std=c99 one gets the same result)... So, does
>>> not BSD's gcc look completely broken?
>>
>> gcc is probably doing exactly what it should be doing.
>
> ?!??!?!
>
> [...]
>
>> The C99 standard does define the sinl function, so any conforming C99
>> implementation must provide it.
>
> So gcc, with the c99 switch, is *not* what doing what it should be
> doing then?

gcc is only part of the implementation. The combination of gcc and
the FreeBSD library apparently is not a conforming C99 implementation,
but given the library's failure to conform, gcc appears to be doing
its job.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Ilya Zakharevich <nospam-> writes:
> On 2009-06-17, Keith Thompson <kst-> wrote:
>>> blue2:/tmp/iz/Numeric-LL_Array-0.04->gcc -std=c99 -Wall -o c c.c -lm
>>> aa.c: In function 'main':
>>> aa.c:5: warning: implicit declaration of function 'sinl'
>>> aa.c:5: warning: incompatible implicit declaration of built-in function 'sinl'
>>> /var/tmp//ccXLekMc.o(.text+0x2c): In function `main': : undefined reference to `sinl'
>>> Exit 1
>>>
>>> (of course, without -std=c99 one gets the same result)... So, does
>>> not BSD's gcc look completely broken?
>>
>> gcc is probably doing exactly what it should be doing. As I mentioned
>> upthread (but not here in comp.lang.c), sinl() is provided by the
>> runtime library, not by the compiler.
>
> ??? What part of "builtin function" is not clear?

That would be the part where I didn't notice that phrase in the error
message.

>> It looks liike FreeBSD's runtime library doesn't provide sinl().
>
> Not surprising, if it is builtin (which, in turn, is not surprising if
> on i386, and long double is 80-bit). But somehow it is not 'activated'...

A little more experimenting with gcc, particularly with the "-S"
option to generate an assembly listing, shows that:

sinl(1.0L) is replaced by a constant value.

sinl(x), where x is a run-time value, generates an actual call to
the sinl() function.

But if I comment out the "#include <math.h>" to hide the declaration
of sinl(), I get the same "incompatible implicit declaration of
built-in function 'sinl'" even if the argument is a run-time value.
I'm not sure what gcc means by "built-in" here, but it's not built
into the compiler for all calls; it does depend on the run-time
library.

>> exist. I presume the math.h header file and the library are from the
>> same source and are consistent with each other.
>
> I know no way to check for this...

If adding your own declaration for sinl:

long double sinl(long double);

corrected the problem, that would indicate that the library provides
the function but <math.h> doesn't declare it. But since you got a
linker error ("undefined reference to `sinl'") as well as the
compile-time error, it appears that <math.h> doesn't declare sinl
*and* the library doesn't define it.

I think you'll either have to do without sinl(), or provide your own
implementation of it.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson <kst-> writes:
> Phil Carmody <> writes:
>> Keith Thompson <kst-> writes:
>>> Ilya Zakharevich <nospam-> writes:
> [...]
>>>> (of course, without -std=c99 one gets the same result)... So, does
>>>> not BSD's gcc look completely broken?
>>>
>>> gcc is probably doing exactly what it should be doing.
>>
>> ?!??!?!
>>
>> [...]
>>
>>> The C99 standard does define the sinl function, so any conforming C99
>>> implementation must provide it.
>>
>> So gcc, with the c99 switch, is *not* what doing what it should be
>> doing then?
>
> gcc is only part of the implementation. The combination of gcc and
> the FreeBSD library apparently is not a conforming C99 implementation,
> but given the library's failure to conform, gcc appears to be doing
> its job.

If you're prepared to draw that distinction, then yes. However,
I don't view math.h to not be part of the compiler just because
it was bundled in a different package from the compiler engine.
Of course, by the time BSD have got their hands and mangled it,
it's no longer GNU's gcc that is to blame, rather BSD's version
in this instance. But I still view BSD's version of the imple-
mentation being broken as the compiler being broken.

Phil
--
Marijuana is indeed a dangerous drug.
It causes governments to wage war against their own people.
-- Dave Seaman (sci.math, 19 Mar 2009)