Bug 221341 - C99 functions cpow, cpowf, cpowl, clog, clogf, clogl are missing
Summary: C99 functions cpow, cpowf, cpowl, clog, clogf, clogl are missing
Status: Closed DUPLICATE of bug 175811
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 11.0-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-standards mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-08 17:57 UTC by Yuri Victorovich
Modified: 2018-07-15 06:32 UTC (History)
6 users (show)

See Also:


Attachments
Patch for 11-RELEASE-p2 (17.92 KB, patch)
2017-11-03 14:32 UTC, Michael Danilov
no flags Details | Diff
Patch for 11-RELEASE-p2 (17.91 KB, patch)
2017-11-03 14:40 UTC, Michael Danilov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer 2017-08-08 17:57:27 UTC
The standard http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf specifies them in the section "7.3.8.2 The cpow functions":
> #include <complex.h>
> double complex cpow(double complex x, double complex y);
> float complex cpowf(float complex x, float complex y);
> long double complex cpowl(long double complex x,
> long double complex y);

Similarly, the section "G.6.3.2 The clog functions" specifies clog.

> double complex clog(double complex z);
> float complex clogf(float complex z);
> long double complex clogl(long double complex z);

They are entirely missing.
Comment 1 Dima Pasechnik 2017-09-19 18:20:12 UTC
What exactly is the status of these missing functions?
I understand that there were candidate implementations, but they were rejected on the basis of insufficient quality. 

Is it acceptable to provide an implementation relying on an extended or an arbitrary precision library? If so, what are the license requirements? Would LGPL be possible?


Our interest is in resurrecting an old FreeBSD port of sagemath:
https://trac.sagemath.org/query?component=porting%3A+BSD

The fact that one needs to rely on a supplementary libm with the missing
implementations does not make it easier...
Comment 2 Michael Danilov 2017-11-03 14:31:53 UTC
I second that. Keeps me from porting this one:
  
https://github.com/NFFT/nfft

Just did a quick search, other BSDs have had them for years!

https://github.com/IIJ-NetBSD/netbsd-src/blob/master/lib/libm/complex
https://github.com/openbsd/src/blob/master/lib/libm/src

So I copied those from OpenBSD. Not sure I did everything right -- could someone with experience please have a look? For example, I'm not sure what Symbol.map does -- and whether the order of that list matters, so I just added those things to the end.

Was able to buildworld & compile NFFT with those, but I can not tell whether it works.

By the way, is there any way to build _just one_ library without having to wait for the whole buildworld? It takes too long even if I run it with ccache and keeping the old /usr/obj.
Comment 3 Michael Danilov 2017-11-03 14:32:19 UTC
Created attachment 187692 [details]
Patch for 11-RELEASE-p2
Comment 4 Michael Danilov 2017-11-03 14:40:43 UTC
Created attachment 187693 [details]
Patch for 11-RELEASE-p2

Ah, geez, think I get it with the Symbols.map.
Comment 5 Dima Pasechnik 2017-11-05 11:38:06 UTC
There are some old discussions of cpow etc on freebsd-numerics, e.g. https://lists.freebsd.org/pipermail/freebsd-numerics/2012-August/000027.html

It looks as if the preferred by the maintainers option was that it's better to have no implementation than a low-precision one.

Perhaps it makes sense to post there a link to this patch, and ask whether it would be accepted.
Comment 6 Michael Danilov 2017-11-06 18:48:31 UTC
(In reply to Dima Pasechnik from comment #1)

Hi, I found out how to get around this: copy over the respective function from either NetBSD or OpenBSD and change the Makefiles to compile it in.

Examples: comms/xnec2c and math/nfft (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223429)
Comment 7 Dima Pasechnik 2017-11-06 18:57:54 UTC
(In reply to Michael Danilov from comment #6)

This is perpetuating the bloat. Surely, one can keep having these functions in patches, but this is ludicrous. 

Why not poking https://wiki.freebsd.org/Numerics people?
Comment 8 Michael Danilov 2017-11-06 19:09:30 UTC
I will. But here and now we just need things to work, and also I was told that it won't make it to older versions, so the workaround will have to be there anyway: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223429#c3
Comment 9 Dima Pasechnik 2017-11-06 19:17:43 UTC
(In reply to Michael Danilov from comment #8)

Is there any reason to care for older versions?
Comment 10 Michael Danilov 2017-11-06 19:25:00 UTC
Long as they are still maintained, I believe. One can always set "BROKEN" for them, ofc.
Comment 11 sgk 2018-05-12 15:30:40 UTC
(In reply to Yuri Victorovich from comment #0)

> Similarly, the section "G.6.3.2 The clog functions" specifies clog.
>
>> double complex clog(double complex z);
>> float complex clogf(float complex z);
>> long double complex clogl(long double complex z);
>
> They are entirely missing.

A patch for the above has been sitting in bugzilla since
2-17-2017.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216863

Don't expect progress on any other math functions.  No
one cares (except me).
Comment 12 Pedro F. Giffuni freebsd_committer 2018-07-15 06:32:20 UTC
It seems like the missing functions have been committed in r333577 and more recently r336299.

*** This bug has been marked as a duplicate of bug 175811 ***