* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
@ 2011-02-24 8:25 ` bkoz at gcc dot gnu.org
2011-02-24 16:04 ` joseph at codesourcery dot com
` (29 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: bkoz at gcc dot gnu.org @ 2011-02-24 8:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Benjamin Kosnik <bkoz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bkoz at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |bkoz at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.6.0
--- Comment #1 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2011-02-24 07:33:56 UTC ---
Mine.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
2011-02-24 8:25 ` [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128 bkoz at gcc dot gnu.org
@ 2011-02-24 16:04 ` joseph at codesourcery dot com
2011-02-24 18:59 ` bkoz at gcc dot gnu.org
` (28 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: joseph at codesourcery dot com @ 2011-02-24 16:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-02-24 15:23:33 UTC ---
This seems related to bug 40855. See also
<http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00652.html> and the rest of
that thread. libstdc++ support for extended integer and floating-point
types covers more than typeinfo; see what I said at
<http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01912.html> and the
followups thereto. There's numeric_limits (see bug 40856), and I/O
support (with the same issues as for libgfortran about avoiding
libquadmath in static links if the functionality isn't used in a
particular program), and mathematical functions, and maybe more -
certainly most of that would not be suitable for 4.6, however.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
2011-02-24 8:25 ` [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128 bkoz at gcc dot gnu.org
2011-02-24 16:04 ` joseph at codesourcery dot com
@ 2011-02-24 18:59 ` bkoz at gcc dot gnu.org
2011-02-24 19:06 ` bkoz at gcc dot gnu.org
` (27 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: bkoz at gcc dot gnu.org @ 2011-02-24 18:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #3 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2011-02-24 18:53:08 UTC ---
Expecting this as exported as fundamental_type_info, see in emit_support_tinfos
via rtti.c:1461:
static tree *const fundamentals[] =
{
&void_type_node,
&boolean_type_node,
&wchar_type_node, &char16_type_node, &char32_type_node,
&char_type_node, &signed_char_type_node, &unsigned_char_type_node,
&short_integer_type_node, &short_unsigned_type_node,
&integer_type_node, &unsigned_type_node,
&long_integer_type_node, &long_unsigned_type_node,
&long_long_integer_type_node, &long_long_unsigned_type_node,
&int128_integer_type_node, &int128_unsigned_type_node,
&float_type_node, &double_type_node, &long_double_type_node,
&dfloat32_type_node, &dfloat64_type_node, &dfloat128_type_node,
&nullptr_type_node,
0
};
Which should take care of this, given the libstdc++ ver patch to export the
symbols. However, none is emitted when building
libsupc++/fundamental_type_info.o.
Ouch.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2011-02-24 18:59 ` bkoz at gcc dot gnu.org
@ 2011-02-24 19:06 ` bkoz at gcc dot gnu.org
2011-02-24 19:28 ` bkoz at gcc dot gnu.org
` (26 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: bkoz at gcc dot gnu.org @ 2011-02-24 19:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #4 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2011-02-24 18:54:06 UTC ---
Created attachment 23457
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23457
typeinfo exports for float128
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2011-02-24 19:06 ` bkoz at gcc dot gnu.org
@ 2011-02-24 19:28 ` bkoz at gcc dot gnu.org
2011-02-24 19:42 ` jakub at gcc dot gnu.org
` (25 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: bkoz at gcc dot gnu.org @ 2011-02-24 19:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #5 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2011-02-24 19:09:33 UTC ---
RE comment 2.
Yes, agreed full support is a ways off. However, typeinfo support is ostensibly
already there, just not emitted. This is a bug, and not something users can
work around. IMHO it should be fixed, and since there are already 4.6.0
typeinfo exports this seems like an opportune time to do it.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2011-02-24 19:28 ` bkoz at gcc dot gnu.org
@ 2011-02-24 19:42 ` jakub at gcc dot gnu.org
2011-02-24 20:14 ` bkoz at gcc dot gnu.org
` (24 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu.org @ 2011-02-24 19:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-24 19:13:16 UTC ---
I guess #c4 patch will break ppc/s390 etc.
config/os/gnu-linux/ldbl-extra.ver already has:
CXXABI_LDBL_1.3 {
_ZT[IS]g;
_ZT[IS]Pg;
_ZT[IS]PKg;
};
So, IMNSHO you don't want to add something like that to gnu.ver, but have
a special *.ver file for those 3 targets (i?86/x86_64/ia64) that have
__float128.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2011-02-24 19:42 ` jakub at gcc dot gnu.org
@ 2011-02-24 20:14 ` bkoz at gcc dot gnu.org
2011-03-25 19:58 ` jakub at gcc dot gnu.org
` (23 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: bkoz at gcc dot gnu.org @ 2011-02-24 20:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #7 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2011-02-24 19:28:02 UTC ---
ack, I mis-read rtti.c, these are the decimal exports, ie decimal128 not
float128.
Jakub you are correct these are exports as LD symbols via ld versioning via
inclusion. I missed that!
%find . -type f | xargs grep _ZTIg
./powerpc-linux-gnu/baseline_symbols.txt:OBJECT:8:_ZTIg@@CXXABI_LDBL_1.3
./sparc-linux-gnu/baseline_symbols.txt:OBJECT:8:_ZTIg@@CXXABI_LDBL_1.3
./powerpc64-linux-gnu/32/baseline_symbols.txt:OBJECT:8:_ZTIg@@CXXABI_LDBL_1.3
./powerpc64-linux-gnu/baseline_symbols.txt:OBJECT:16:_ZTIg@@CXXABI_LDBL_1.3
./s390-linux-gnu/baseline_symbols.txt:OBJECT:8:_ZTIg@@CXXABI_LDBL_1.3
./s390x-linux-gnu/baseline_symbols.txt:OBJECT:16:_ZTIg@@CXXABI_LDBL_1.3
./alpha-linux-gnu/baseline_symbols.txt:OBJECT:16:_ZTIg@@CXXABI_LDBL_1.3
sparc may be questionable in reality as it is inferred on alpha.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2011-02-24 20:14 ` bkoz at gcc dot gnu.org
@ 2011-03-25 19:58 ` jakub at gcc dot gnu.org
2011-04-14 15:56 ` planet36 at gmail dot com
` (22 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu.org @ 2011-03-25 19:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.6.0 |4.6.1
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-25 19:52:22 UTC ---
GCC 4.6.0 is being released, adjusting target milestone.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2011-03-25 19:58 ` jakub at gcc dot gnu.org
@ 2011-04-14 15:56 ` planet36 at gmail dot com
2011-04-28 16:15 ` rguenth at gcc dot gnu.org
` (21 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: planet36 at gmail dot com @ 2011-04-14 15:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #9 from Steve Ward <planet36 at gmail dot com> 2011-04-14 15:56:12 UTC ---
Created attachment 23982
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23982
This test-case shows how typeinfo for non-complex 128-bit types DOES NOT work,
but typeinfo for complex 128-bit types DOES work.
$ g++-4.5 --version
g++-4.5 (Ubuntu/Linaro 4.5.1-7ubuntu2) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ uname --all
Linux dev8 2.6.35-28-generic #50-Ubuntu SMP Fri Mar 18 18:42:20 UTC 2011 x86_64
GNU/Linux
$ g++-4.5 gcc_bug_43622.cpp && ./a.out
complex_int128 = Cn
complex_uint128 = Co
complex_binary128 = Cg
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2011-04-14 15:56 ` planet36 at gmail dot com
@ 2011-04-28 16:15 ` rguenth at gcc dot gnu.org
2011-09-25 15:06 ` paolo.carlini at oracle dot com
` (20 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-04-28 16:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.6.1 |---
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2011-04-28 16:15 ` rguenth at gcc dot gnu.org
@ 2011-09-25 15:06 ` paolo.carlini at oracle dot com
2012-10-21 22:06 ` planet36 at gmail dot com
` (19 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-09-25 15:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |john.salmon at deshaw dot
| |com
--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-09-25 15:04:17 UTC ---
*** Bug 40855 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2011-09-25 15:06 ` paolo.carlini at oracle dot com
@ 2012-10-21 22:06 ` planet36 at gmail dot com
2014-03-02 10:41 ` pbristow at hetp dot u-net.com
` (18 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: planet36 at gmail dot com @ 2012-10-21 22:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #11 from Steve Ward <planet36 at gmail dot com> 2012-10-21 22:05:35 UTC ---
This problem still exists in g++ 4.7.2.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2012-10-21 22:06 ` planet36 at gmail dot com
@ 2014-03-02 10:41 ` pbristow at hetp dot u-net.com
2014-03-02 12:15 ` glisse at gcc dot gnu.org
` (17 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: pbristow at hetp dot u-net.com @ 2014-03-02 10:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Paul A. Bristow <pbristow at hetp dot u-net.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pbristow at hetp dot u-net.com
--- Comment #12 from Paul A. Bristow <pbristow at hetp dot u-net.com> ---
This still exists at 4.8.2 and is a *showstopper* for running the Boost.Math
library at all the available precisions, up to 128-bit precision where
available.
typeid(type).name() fails with:
undefined reference to `typeinfo for __float128'
We can check that the library seems to work OK by ugly hacking of error
handling and a few examples of test code (out of the hundreds of tests), but we
absolutely need this before it can be fully tested at 128-bit precision and
released.
Getting this library to pass is part of a demonstration of the proposed C++ and
C library additions by Christopher Kormanyos and John Maddock
Floating-Point Typedefs Having Specified Widths - N3626
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1703.pdf
Everything is working to provide full C++ 128-bit floating-point - apart from
this :-(
So we are very keen to have a fix.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2014-03-02 10:41 ` pbristow at hetp dot u-net.com
@ 2014-03-02 12:15 ` glisse at gcc dot gnu.org
2014-03-02 16:11 ` [Bug libstdc++/43622] no C++ typeinfo for __float128 glisse at gcc dot gnu.org
` (16 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-03-02 12:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #13 from Marc Glisse <glisse at gcc dot gnu.org> ---
It looks like emit_support_tinfos (rtti.c) should go through
registered_builtin_types (hidden in c-common.c) in addition to the hardcoded
fundamentals list.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2014-03-02 12:15 ` glisse at gcc dot gnu.org
@ 2014-03-02 16:11 ` glisse at gcc dot gnu.org
2014-04-22 16:45 ` glisse at gcc dot gnu.org
` (15 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-03-02 16:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Marc Glisse <glisse at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|no C++ typeinfo for |no C++ typeinfo for
|__float128 and __int128 |__float128
--- Comment #14 from Marc Glisse <glisse at gcc dot gnu.org> ---
Updating the title: it seems to me that typeinfo for __int128 has been
available for a while, it is only __float128 that is missing.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2014-03-02 16:11 ` [Bug libstdc++/43622] no C++ typeinfo for __float128 glisse at gcc dot gnu.org
@ 2014-04-22 16:45 ` glisse at gcc dot gnu.org
2014-04-22 17:06 ` glisse at gcc dot gnu.org
` (14 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-04-22 16:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #15 from Marc Glisse <glisse at gcc dot gnu.org> ---
Author: glisse
Date: Tue Apr 22 16:44:46 2014
New Revision: 209652
URL: http://gcc.gnu.org/viewcvs?rev=209652&root=gcc&view=rev
Log:
2014-04-22 Marc Glisse <marc.glisse@inria.fr>
PR libstdc++/43622
gcc/c-family/
* c-common.c (registered_builtin_types): Make non-static.
* c-common.h (registered_builtin_types): Declare.
gcc/cp/
* rtti.c (emit_support_tinfo_1): New function, extracted from
emit_support_tinfos.
(emit_support_tinfos): Call it and iterate on registered_builtin_types.
libstdc++-v3/
* config/abi/pre/gnu.ver (CXXABI_1.3.9): New version, new symbols.
* config/abi/pre/gnu-versioned-namespace.ver: New symbols.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Likewise.
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/rtti.c
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
trunk/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
trunk/libstdc++-v3/config/abi/pre/gnu.ver
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2014-04-22 16:45 ` glisse at gcc dot gnu.org
@ 2014-04-22 17:06 ` glisse at gcc dot gnu.org
2014-04-22 17:25 ` glisse at gcc dot gnu.org
` (13 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-04-22 17:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Marc Glisse <glisse at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |redi at gcc dot gnu.org
--- Comment #16 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> I guess #c4 patch will break ppc/s390 etc.
> config/os/gnu-linux/ldbl-extra.ver already has:
> CXXABI_LDBL_1.3 {
> _ZT[IS]g;
> _ZT[IS]Pg;
> _ZT[IS]PKg;
> };
>
> So, IMNSHO you don't want to add something like that to gnu.ver, but have
> a special *.ver file for those 3 targets (i?86/x86_64/ia64) that have
> __float128.
Er, oups, I was going to close the bug, but apparently I overlooked this
comment when writing the patch, sorry :-(
Should I revert right away?
It looks like I need to create a file config/?/?/float128.ver and find the
right incantation in configure to add it to port_specific_symbol_files for
those 3 targets?
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (16 preceding siblings ...)
2014-04-22 17:06 ` glisse at gcc dot gnu.org
@ 2014-04-22 17:25 ` glisse at gcc dot gnu.org
2014-04-22 17:55 ` glisse at gcc dot gnu.org
` (12 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-04-22 17:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Marc Glisse <glisse at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |glisse at gcc dot gnu.org
--- Comment #18 from Marc Glisse <glisse at gcc dot gnu.org> ---
The easiest would be to move CXXABI_LDBL_1.3 to gnu.ver and use that for the
new __float128 symbols on x86, but I'm sure that would be considered too hacky.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (17 preceding siblings ...)
2014-04-22 17:25 ` glisse at gcc dot gnu.org
@ 2014-04-22 17:55 ` glisse at gcc dot gnu.org
2014-11-18 20:21 ` glisse at gcc dot gnu.org
` (11 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-04-22 17:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #19 from Marc Glisse <glisse at gcc dot gnu.org> ---
Created attachment 32654
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32654&action=edit
potential export fix
I am currently testing the attached.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (18 preceding siblings ...)
2014-04-22 17:55 ` glisse at gcc dot gnu.org
@ 2014-11-18 20:21 ` glisse at gcc dot gnu.org
2014-11-18 20:42 ` glisse at gcc dot gnu.org
` (10 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-11-18 20:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #21 from Marc Glisse <glisse at gcc dot gnu.org> ---
Author: glisse
Date: Tue Nov 18 20:20:53 2014
New Revision: 217735
URL: https://gcc.gnu.org/viewcvs?rev=217735&root=gcc&view=rev
Log:
2014-11-18 Marc Glisse <marc.glisse@inria.fr>
PR libstdc++/43622
gcc/cp/
* rtti.c (emit_support_tinfos): Handle __float128.
libstdc++-v3/
* config/abi/pre/float128.ver: New file.
* configure.ac: Use float128.ver when relevant.
* configure: Regenerate.
* testsuite/util/testsuite_abi.cc (check_version): Accept new
CXXABI_FLOAT128 version.
Added:
trunk/libstdc++-v3/config/abi/pre/float128.ver
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/rtti.c
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (19 preceding siblings ...)
2014-11-18 20:21 ` glisse at gcc dot gnu.org
@ 2014-11-18 20:42 ` glisse at gcc dot gnu.org
2014-11-18 23:50 ` joseph at codesourcery dot com
` (9 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-11-18 20:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #22 from Marc Glisse <glisse at gcc dot gnu.org> ---
__float128 is still missing a specialization of numeric_limits.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (20 preceding siblings ...)
2014-11-18 20:42 ` glisse at gcc dot gnu.org
@ 2014-11-18 23:50 ` joseph at codesourcery dot com
2014-11-20 17:12 ` john at johnmaddock dot co.uk
` (8 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: joseph at codesourcery dot com @ 2014-11-18 23:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #23 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 18 Nov 2014, glisse at gcc dot gnu.org wrote:
> __float128 is still missing a specialization of numeric_limits.
Fully supporting an extended type (whether floating-point, or one like
__int128 that mostly acts like an integer type) includes (as I noted in
one of the other past bug reports on such issues, bug 50441 (fixed))
typeinfo, numeric_limits (maybe with associated built-in macros), I/O and
mathematical functions in general.
But you may not want libstdc++ to depend on libquadmath, which may limit
what you can support for __float128. (The ideal would be full C support
for the relevant parts of TS 18661 in GCC and glibc, which would give you
library support in libc and libm that could then be used from libstdc++
when used with glibc.)
I think it would be reasonable to define built-in __FLT128_*__ macros for
__float128 similar to those defined for other floating-point types (you'd
then make quadmath.h use those instead of hardcoding the values directly)
- and you could then use those macros in numeric_limits. That naming is
in line with DTS 18661-3 defining e.g. FLT128_MANT_DIG as public names for
macros relating to _Float128.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (21 preceding siblings ...)
2014-11-18 23:50 ` joseph at codesourcery dot com
@ 2014-11-20 17:12 ` john at johnmaddock dot co.uk
2014-11-21 12:18 ` john at johnmaddock dot co.uk
` (7 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: john at johnmaddock dot co.uk @ 2014-11-20 17:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
John Maddock <john at johnmaddock dot co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |john at johnmaddock dot co.uk
--- Comment #24 from John Maddock <john at johnmaddock dot co.uk> ---
(In reply to joseph@codesourcery.com from comment #23)
> On Tue, 18 Nov 2014, glisse at gcc dot gnu.org wrote:
>
> > __float128 is still missing a specialization of numeric_limits.
>
> Fully supporting an extended type (whether floating-point, or one like
> __int128 that mostly acts like an integer type) includes (as I noted in
> one of the other past bug reports on such issues, bug 50441 (fixed))
> typeinfo, numeric_limits (maybe with associated built-in macros), I/O and
> mathematical functions in general.
>
> But you may not want libstdc++ to depend on libquadmath, which may limit
> what you can support for __float128. (The ideal would be full C support
> for the relevant parts of TS 18661 in GCC and glibc, which would give you
> library support in libc and libm that could then be used from libstdc++
> when used with glibc.)
>
> I think it would be reasonable to define built-in __FLT128_*__ macros for
> __float128 similar to those defined for other floating-point types (you'd
> then make quadmath.h use those instead of hardcoding the values directly)
> - and you could then use those macros in numeric_limits. That naming is
> in line with DTS 18661-3 defining e.g. FLT128_MANT_DIG as public names for
> macros relating to _Float128.
+1 on supporting numeric_limits.
IMO while it would be nice to provide full standard lib support, there are
levels of importance here. typeinfo was essential because the user cannot add
that support themselves. numeric_limits and iostream support come next in
importance, and of course std::whatever overloads for the <cmath> functions
would be nice but come lower down I guess.
I understand the desire to limit the dependency on libquadmath - perhaps first
class std lib support should be added to <quadmath.h> rather than <limits>,
<cmath> etc if this is an overarching concern? That said, implementating
numeric_limits for that type is trivial, and this is obviously a built in type,
not a pure library extension so there is a lot to be said for providing this
support without the need to include additional headers.
While we're opening cans of worms.... intmax_t should clearly be __int128...
just saying!
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] no C++ typeinfo for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (22 preceding siblings ...)
2014-11-20 17:12 ` john at johnmaddock dot co.uk
@ 2014-11-21 12:18 ` john at johnmaddock dot co.uk
2015-04-04 13:36 ` [Bug libstdc++/43622] Incomplete C++ library support " glisse at gcc dot gnu.org
` (6 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: john at johnmaddock dot co.uk @ 2014-11-21 12:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #26 from John Maddock <john at johnmaddock dot co.uk> ---
(In reply to joseph@codesourcery.com from comment #25)
> On Thu, 20 Nov 2014, john at johnmaddock dot co.uk wrote:
>
> > While we're opening cans of worms.... intmax_t should clearly be __int128...
> > just saying!
>
> Existing ABIs where intmax_t in libc is 64-bit are why __int128 is what I
> call a sui generis extended type, not an integer type.
So it's an integer that's not an integer? I'm sorry but that's just nonesense.
Of course I realise that ABI issues may trump other concerns, but please call
a spade a spade! In any case this is a glibc issue and we're off topic here...
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] Incomplete C++ library support for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (23 preceding siblings ...)
2014-11-21 12:18 ` john at johnmaddock dot co.uk
@ 2015-04-04 13:36 ` glisse at gcc dot gnu.org
2021-05-04 12:31 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: glisse at gcc dot gnu.org @ 2015-04-04 13:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Marc Glisse <glisse at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-04-04
Summary|no C++ typeinfo for |Incomplete C++ library
|__float128 |support for __float128
Ever confirmed|0 |1
--- Comment #27 from Marc Glisse <glisse at gcc dot gnu.org> ---
Renaming since typeinfo is in gcc-5.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] Incomplete C++ library support for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (24 preceding siblings ...)
2015-04-04 13:36 ` [Bug libstdc++/43622] Incomplete C++ library support " glisse at gcc dot gnu.org
@ 2021-05-04 12:31 ` rguenth at gcc dot gnu.org
2023-05-16 18:19 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-04 12:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] Incomplete C++ library support for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (25 preceding siblings ...)
2021-05-04 12:31 ` rguenth at gcc dot gnu.org
@ 2023-05-16 18:19 ` pinskia at gcc dot gnu.org
2023-05-16 18:47 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-05-16 18:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #28 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect this has now been fixed with the additional of full _Float128 support
in the C++ front-end and the library work.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] Incomplete C++ library support for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (26 preceding siblings ...)
2023-05-16 18:19 ` pinskia at gcc dot gnu.org
@ 2023-05-16 18:47 ` redi at gcc dot gnu.org
2023-05-16 18:49 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
30 siblings, 0 replies; 31+ messages in thread
From: redi at gcc dot gnu.org @ 2023-05-16 18:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #29 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #22)
> __float128 is still missing a specialization of numeric_limits.
We're still missing that, but I created PR libstdc++/104772 for it. I don't
think we need full <cmath> and I/O support for __float128, so let's close this
one.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] Incomplete C++ library support for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (27 preceding siblings ...)
2023-05-16 18:47 ` redi at gcc dot gnu.org
@ 2023-05-16 18:49 ` redi at gcc dot gnu.org
2023-05-16 19:33 ` joseph at codesourcery dot com
2023-05-16 19:43 ` redi at gcc dot gnu.org
30 siblings, 0 replies; 31+ messages in thread
From: redi at gcc dot gnu.org @ 2023-05-16 18:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #30 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to John Maddock from comment #26)
> (In reply to joseph@codesourcery.com from comment #25)
> > On Thu, 20 Nov 2014, john at johnmaddock dot co.uk wrote:
> >
> > > While we're opening cans of worms.... intmax_t should clearly be __int128...
> > > just saying!
> >
> > Existing ABIs where intmax_t in libc is 64-bit are why __int128 is what I
> > call a sui generis extended type, not an integer type.
>
> So it's an integer that's not an integer? I'm sorry but that's just
> nonesense. Of course I realise that ABI issues may trump other concerns,
> but please call a spade a spade! In any case this is a glibc issue and
> we're off topic here...
With changes to the definition of intmax_t in C2x (and C++23) that problem is
gone. __int128 can be an extended integer type, and intmax_t doesn't need to
change, so there's no ABI problem. Order is restored to the galaxy.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] Incomplete C++ library support for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (28 preceding siblings ...)
2023-05-16 18:49 ` redi at gcc dot gnu.org
@ 2023-05-16 19:33 ` joseph at codesourcery dot com
2023-05-16 19:43 ` redi at gcc dot gnu.org
30 siblings, 0 replies; 31+ messages in thread
From: joseph at codesourcery dot com @ 2023-05-16 19:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #31 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
It can be an extended integer type in C2x, but then stdint.h would be
required to have int128_t / uint128_t / int_least128_t / uint_least128_t
typedefs, and integer constant suffixes would be needed for the
corresponding macros INT128_C / UINT128_C (and the other stdint.h macros
for the types would need to be defined as well), and printf/scanf support
would be required as well.
^ permalink raw reply [flat|nested] 31+ messages in thread* [Bug libstdc++/43622] Incomplete C++ library support for __float128
[not found] <bug-43622-4@http.gcc.gnu.org/bugzilla/>
` (29 preceding siblings ...)
2023-05-16 19:33 ` joseph at codesourcery dot com
@ 2023-05-16 19:43 ` redi at gcc dot gnu.org
30 siblings, 0 replies; 31+ messages in thread
From: redi at gcc dot gnu.org @ 2023-05-16 19:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Hmm, yes. Well I think we can at least make std::is_integral<__int128> true,
which will remove once source of surprises for users.
^ permalink raw reply [flat|nested] 31+ messages in thread