[Bug libstdc++/43622] no C++ typeinfo for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #26 from John Maddock john at johnmaddock dot co.uk --- (In reply to jos...@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...
[Bug libstdc++/43622] no C++ typeinfo for __float128
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 jos...@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!
[Bug libstdc++/43622] no C++ typeinfo for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #25 from joseph at codesourcery dot com joseph at codesourcery dot com --- 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.
[Bug libstdc++/43622] no C++ typeinfo for __float128
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=217735root=gccview=rev Log: 2014-11-18 Marc Glisse marc.gli...@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
[Bug libstdc++/43622] no C++ typeinfo for __float128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #20 from Marc Glisse glisse at gcc dot gnu.org --- Author: glisse Date: Thu Apr 24 13:58:36 2014 New Revision: 209748 URL: http://gcc.gnu.org/viewcvs?rev=209748root=gccview=rev Log: 2014-04-24 Marc Glisse marc.gli...@inria.fr PR libstdc++/43622 gcc/cp/ * rtti.c (emit_support_tinfos): Do not iterate on registered_builtin_types (partial revert). libstdc++/ * config/abi/pre/gnu.ver (CXXABI_1.3.9): Remove __float128 symbols. * config/abi/pre/gnu-versioned-namespace.ver: Likewise. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update. Modified: 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
[Bug libstdc++/43622] no C++ typeinfo for __float128
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=209652root=gccview=rev Log: 2014-04-22 Marc Glisse marc.gli...@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
[Bug libstdc++/43622] no C++ typeinfo for __float128
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?
[Bug libstdc++/43622] no C++ typeinfo for __float128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Marc Glisse from comment #16) Should I revert right away? If it doesn't break bootstrap for the ldbl targets (only causes test failures) then I would say reverting it is not necessary if you will be able to work on a fix fairly quickly. 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? I honestly don't know, but that sounds reasonable.
[Bug libstdc++/43622] no C++ typeinfo for __float128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128
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=32654action=edit potential export fix I am currently testing the attached.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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. ***
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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 |---
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
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.
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
