Bug 175811 - libstdc++ needs complex support in order use C99
Summary: libstdc++ needs complex support in order use C99
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-numerics (Nobody)
URL:
Keywords:
: 221341 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-02-04 03:20 UTC by Pedro F. Giffuni
Modified: 2018-07-16 19:05 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro F. Giffuni freebsd_committer freebsd_triage 2013-02-04 03:20:00 UTC
From a posting @toolchain by Dimitry Andric:

I took the original gcc 4.2.1 release tarball, modified a few autoconf
related scripts to cope with "freebsd10.0" being the current version,
and did a full three-stage build, though only targeting C and C++.

The libstdc++ configure script in 4.2.1 does detect a few new features
that are not in our shipping config.h, but is does not detect any
different settings regarding C99.

The reason it does not turn on _GLIBCXX_USE_C99, is that not all of the
C99 requirements are met, specifically <complex.h> checks fail:

  checking for ISO C99 support in <math.h>... yes
  checking for ISO C99 support in <complex.h>... no
  checking for ISO C99 support in <stdio.h>... yes
  checking for ISO C99 support in <stdlib.h>... yes
  checking for ISO C99 support in <wchar.h>... yes
  checking for fully enabled ISO C99 support... no

The exact failure testcase goes like this:

  configure:7435: checking for ISO C99 support in <complex.h>
  configure:7492:  /home/dim/obj/gcc-4.2.1/./gcc/xgcc -shared-libgcc -B/home/dim/obj/gcc-4.2.1/./gcc -nostdinc++ -L/home/dim/obj/gcc-4.2.1/i386-unknown-freebsd10.0/libstdc++-v3/src -L/home/dim/obj/gcc-4.2.1/i386-unknown-freebsd10.0/libstdc++-v3/src/.libs -B/home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/bin/ -B/home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/lib/ -isystem /home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/include -isystem /home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/sys-include -c -g -O2  conftest.cc >&5
  conftest.cc: In function 'int main()':
  conftest.cc:41: error: 'clogf' was not declared in this scope
  conftest.cc:47: error: 'cpowf' was not declared in this scope
  conftest.cc:54: error: 'clog' was not declared in this scope
  conftest.cc:60: error: 'cpow' was not declared in this scope
  conftest.cc:64: error: 'ccosl' was not declared in this scope
  conftest.cc:65: error: 'ccoshl' was not declared in this scope
  conftest.cc:66: error: 'cexpl' was not declared in this scope
  conftest.cc:67: error: 'clogl' was not declared in this scope
  conftest.cc:68: error: 'csinl' was not declared in this scope
  conftest.cc:69: error: 'csinhl' was not declared in this scope
  conftest.cc:71: error: 'ctanl' was not declared in this scope
  conftest.cc:72: error: 'ctanhl' was not declared in this scope
  conftest.cc:73: error: 'cpowl' was not declared in this scope
  configure:7498: $? = 1

So until we actually implement and declare those functions, we should
probably not enable _GLIBCXX_USE_C99_COMPLEX and _GLIBCXX_USE_C99.

Fix: 

Just a reminder (I know .. shutup and code).
Comment 1 Pedro F. Giffuni freebsd_committer freebsd_triage 2013-02-04 03:26:48 UTC
Responsible Changed
From-To: freebsd-standards->freebsd-numerics

Re-assign to freebsd-numerics@ 
They are known to be working on it.
Comment 2 Sebastian Schwarz 2017-06-25 14:28:12 UTC
It looks like Dragonfly-, Net- and OpenBSD already have implementations of the missing functions.  Maybe these could be imported.
Comment 3 sgk 2017-06-26 21:02:30 UTC
(In reply to seschwar from comment #2)
>
> It looks like Dragonfly-, Net- and OpenBSD already have
> implementations of the missing functions.  Maybe these
> could be imported.

These would need to be tested for correctness especially near
branch points/cuts and exception values (Inf, NaN, subnormal).
I Haven't checked recently, but I'll offer that these
functions have a number of problems due to the use of I from
complex.h.
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:46:26 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 5 Pedro F. Giffuni freebsd_committer freebsd_triage 2018-07-15 06:32:20 UTC
*** Bug 221341 has been marked as a duplicate of this bug. ***
Comment 6 Pedro F. Giffuni freebsd_committer freebsd_triage 2018-07-15 06:38:54 UTC
It seems like the missing functions have been committed in r333577 (clog(3), clogf(3), and clog(3)) and more recently r336299 (ld80/ld128 powl, cpow, cpowf, cpowl).
The later come from OpenBSD and were not committed in the past as their quality is not ideal, but for now they are probably an acceptable starting point while something better is found.
Comment 7 Pedro F. Giffuni freebsd_committer freebsd_triage 2018-07-16 19:05:16 UTC
r336351 updated the configuration to start using the C99 math functions in legacy gcc-4.2.1. Any new issues should be reported in a new PR.