base gcc and _GLIBCXX_USE_C99

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

base gcc and _GLIBCXX_USE_C99

Andriy Gapon

Guys,

I wonder why the following is the case for the base gcc.
/usr/include/c++/4.2/bits/c++config.h:

/* Define if C99 functions or macros from <wchar.h>, <math.h>, <complex.h>,
   <stdio.h>, and <stdlib.h> can be used or exposed. */
/* #undef _GLIBCXX_USE_C99 */

Because of this undef there is no e.g. std::strtoll().
Ditto for other things in stdlib.h.

--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: base gcc and _GLIBCXX_USE_C99

Andriy Gapon

[ping]

on 28/01/2013 17:11 Andriy Gapon said the following:

>
> Guys,
>
> I wonder why the following is the case for the base gcc.
> /usr/include/c++/4.2/bits/c++config.h:
>
> /* Define if C99 functions or macros from <wchar.h>, <math.h>, <complex.h>,
>    <stdio.h>, and <stdlib.h> can be used or exposed. */
> /* #undef _GLIBCXX_USE_C99 */
>
> Because of this undef there is no e.g. std::strtoll().
> Ditto for other things in stdlib.h.
>


--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: base gcc and _GLIBCXX_USE_C99

Dimitry Andric-4
On 2013-02-01 14:01, Andriy Gapon wrote:

> on 28/01/2013 17:11 Andriy Gapon said the following:
>> I wonder why the following is the case for the base gcc.
>> /usr/include/c++/4.2/bits/c++config.h:
>>
>> /* Define if C99 functions or macros from <wchar.h>, <math.h>, <complex.h>,
>>     <stdio.h>, and <stdlib.h> can be used or exposed. */
>> /* #undef _GLIBCXX_USE_C99 */
>>
>> Because of this undef there is no e.g. std::strtoll().
>> Ditto for other things in stdlib.h.

Maybe this support can't be enabled, because we don't expose all the
required functions yet?  Or maybe it is just something that was
committed years ago, and then forgotten.

If we are sure that all the C99 functions libstdc++ requires are now
available and working, I see no problem in turning on _GLIBCXX_USE_C99.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: base gcc and _GLIBCXX_USE_C99

Andriy Gapon
on 01/02/2013 15:08 Dimitry Andric said the following:

> On 2013-02-01 14:01, Andriy Gapon wrote:
>> on 28/01/2013 17:11 Andriy Gapon said the following:
>>> I wonder why the following is the case for the base gcc.
>>> /usr/include/c++/4.2/bits/c++config.h:
>>>
>>> /* Define if C99 functions or macros from <wchar.h>, <math.h>, <complex.h>,
>>>     <stdio.h>, and <stdlib.h> can be used or exposed. */
>>> /* #undef _GLIBCXX_USE_C99 */
>>>
>>> Because of this undef there is no e.g. std::strtoll().
>>> Ditto for other things in stdlib.h.
>
> Maybe this support can't be enabled, because we don't expose all the
> required functions yet?  Or maybe it is just something that was
> committed years ago, and then forgotten.
>
> If we are sure that all the C99 functions libstdc++ requires are now
> available and working, I see no problem in turning on _GLIBCXX_USE_C99.

Having looked into the source code of a recent GCC I get an impression that this
is a silliness on GCC's part (plus incompleteness of FreeBSD C99 support, it seems).

cstdlib would provide e.g. std::strtoull only when _GLIBCXX_USE_C99 is defined.

Now looking at libstdc++-v3/acinclude.m4 we can see that there is a dedicated
check "for ISO C99 support in <stdlib.h>".  That check sets variable
glibcxx_cv_c99_stdlib.

But, _GLIBCXX_USE_C99 is set only if all of glibcxx_cv_c99_math,
glibcxx_cv_c99_complex, glibcxx_cv_c99_stdio, glibcxx_cv_c99_stdlib and
glibcxx_cv_c99_wchar are set.

So if glibcxx_cv_c99_stdlib is yes, but something like glibcxx_cv_c99_complex is
no, then no std::strtoull for me.

Not sure why GCC couldn't have a dedicated macro "_GLIBCXX_USE_C99_STDLIB" like
e.g. _GLIBCXX_USE_C99_MATH that it does have.

--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: base gcc and _GLIBCXX_USE_C99

David Chisnall-2
On 1 Feb 2013, at 13:31, Andriy Gapon wrote:

> cstdlib would provide e.g. std::strtoull only when _GLIBCXX_USE_C99 is defined.

This is entirely consistent with the standard.  strtoull() should only be visible when compiling in C++11 mode, it is not part of C++98 / C++03.

David


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: base gcc and _GLIBCXX_USE_C99

Pedro Giffuni-4
In reply to this post by Andriy Gapon
Hello;

On 02/01/2013 08:01, Andriy Gapon wrote:

> [ping]
>
> on 28/01/2013 17:11 Andriy Gapon said the following:
>> Guys,
>>
>> I wonder why the following is the case for the base gcc.
>> /usr/include/c++/4.2/bits/c++config.h:
>>
>> /* Define if C99 functions or macros from <wchar.h>, <math.h>, <complex.h>,
>>     <stdio.h>, and <stdlib.h> can be used or exposed. */
>> /* #undef _GLIBCXX_USE_C99 */
>>
>> Because of this undef there is no e.g. std::strtoll().
>> Ditto for other things in stdlib.h.
>>
>
I looked at this very briefly and it looks like it would fix a nasty
issue we have been working around in OpenOffice.

I suggest to enable it first on a gcc port though (it's tied to a
configure flag, but don't remember which).

Pedro.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: base gcc and _GLIBCXX_USE_C99

Dimitry Andric-4
On 2013-02-01 15:46, Pedro Giffuni wrote:

> On 02/01/2013 08:01, Andriy Gapon wrote:
>> on 28/01/2013 17:11 Andriy Gapon said the following:
>>> I wonder why the following is the case for the base gcc.
>>> /usr/include/c++/4.2/bits/c++config.h:
>>>
>>> /* Define if C99 functions or macros from <wchar.h>, <math.h>, <complex.h>,
>>>      <stdio.h>, and <stdlib.h> can be used or exposed. */
>>> /* #undef _GLIBCXX_USE_C99 */
>>>
>>> Because of this undef there is no e.g. std::strtoll().
>>> Ditto for other things in stdlib.h.
>>>
> I looked at this very briefly and it looks like it would fix a nasty
> issue we have been working around in OpenOffice.
>
> I suggest to enable it first on a gcc port though (it's tied to a
> configure flag, but don't remember which).
I had a bit more in-depth look at our current libstdc++ configuration.

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.

I have attached a diff of the other changes that can be applied on our
current libstdc++ config file, as detected by the configure script.  I
will probably commit that soonish, if there are no objections.

As to the missing complex functions, I am not sure.  Maybe these can be
imported from somewhere else, e.g. NetBSD?  This is probably something
to ask the lib/msun specialists...

-Dimitry

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"

libstdcxx-reconfig-1.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: base gcc and _GLIBCXX_USE_C99

Pedro Giffuni-4
Hello Dimitry;


----- Messaggio originale -----
> Da: Dimitry Andric 

> I had a bit more in-depth look at our current libstdc++ configuration.
>
> 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.
>

Not sure if libstdc++ from gcc42 sets --enable-c99 by default.
  

> 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

Those are surely in this list:
https://wiki.freebsd.org/MissingMathStuff

I think we are using stubs for libc++.

> So until we actually implement and declare those functions, we should
> probably not enable _GLIBCXX_USE_C99_COMPLEX and _GLIBCXX_USE_C99.
>
> I have attached a diff of the other changes that can be applied on our
> current libstdc++ config file, as detected by the configure script.  I
> will probably commit that soonish, if there are no objections.


Thanks, that looks useful. Of course if GLIBCXX_USE_C99 didn't necessarily
imply _GLIBCXX_USE_C99_COMPLEX it would be useful too.

> As to the missing complex functions, I am not sure.  Maybe these can be
> imported from somewhere else, e.g. NetBSD?  This is probably something
> to ask the lib/msun specialists...



There is a freebsd-numerics list for people working on it.

I am using the C++ complex stuff from boost and there were
recent fixes done by Stephen Montgomery-Smith (CC'd)
and it looks like he has a FreeBSD implementation in the works.

I will open a PR as a reminder ;).

cheers,

Pedro.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: base gcc and _GLIBCXX_USE_C99

Pedro Giffuni-4
In reply to this post by Dimitry Andric-4
Hello;

On 02/03/2013 17:33, Dimitry Andric wrote:

> On 2013-02-01 15:46, Pedro Giffuni wrote:
>> On 02/01/2013 08:01, Andriy Gapon wrote:
>>> on 28/01/2013 17:11 Andriy Gapon said the following:
>>>> I wonder why the following is the case for the base gcc.
>>>> /usr/include/c++/4.2/bits/c++config.h:
>>>>
>>>> /* Define if C99 functions or macros from <wchar.h>, <math.h>,
>>>> <complex.h>,
>>>>      <stdio.h>, and <stdlib.h> can be used or exposed. */
>>>> /* #undef _GLIBCXX_USE_C99 */
>>>>
>>>> Because of this undef there is no e.g. std::strtoll().
>>>> Ditto for other things in stdlib.h.
>>>>
>> I looked at this very briefly and it looks like it would fix a nasty
>> issue we have been working around in OpenOffice.
>>
>> I suggest to enable it first on a gcc port though (it's tied to a
>> configure flag, but don't remember which).
>
> I had a bit more in-depth look at our current libstdc++ configuration.
>
> 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.
>
> ...
> I have attached a diff of the other changes that can be applied on our
> current libstdc++ config file, as detected by the configure script.  I
> will probably commit that soonish, if there are no objections.
>

I think this patch is really important, please do commit it to current.

I think it should be in -stable too but with some caution: it appears
that people will have to build world and all C++ applications.

Pedro.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: base gcc and _GLIBCXX_USE_C99

David Chisnall-2
In reply to this post by Pedro Giffuni-4
On 4 Feb 2013, at 03:09, Pedro Giffuni <[hidden email]> wrote:

> Those are surely in this list:
> https://wiki.freebsd.org/MissingMathStuff
>
> I think we are using stubs for libc++.

We are using stubs for libc++, because libc++ is a C++11 standard library, which expects the C99 math functions.  The libstdc++ in base is a C++03 library, and the C++03 standard does not include a long long type, nor any of the related functions.

David

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"