$ cat tf-test.cpp #include <typeinfo> typedef float type __attribute__((__mode__(TF))); int main() { return *(typeid(type).name()); } $ g++ tf-test.cpp /tmp/cc8RAh4o.o: In function `main': tf-test.cpp:(.text+0x5): undefined reference to `typeinfo for __float128' collect2: ld returned 1 exit status $ cat ti-test.cpp #include <typeinfo> typedef int type __attribute__((__mode__(TI))); int main() { return *(typeid(type).name()); } $ g++ ti-test.cpp /tmp/ccI1nTTK.o: In function `main': ti-test.cpp:(.text+0x5): undefined reference to `typeinfo for __int128' collect2: ld returned 1 exit status $ g++ --version | head -1 g++ (GCC) 4.5.0 20100401 (experimental)
Mine.
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.
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.
Created attachment 23457 [details] typeinfo exports for float128
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.
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.
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.
GCC 4.6.0 is being released, adjusting target milestone.
Created attachment 23982 [details] 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 40855 has been marked as a duplicate of this bug. ***
This problem still exists in g++ 4.7.2.
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.
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.
Updating the title: it seems to me that typeinfo for __int128 has been available for a while, it is only __float128 that is missing.
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
(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?
(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.
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.
Created attachment 32654 [details] potential export fix I am currently testing the attached.
Author: glisse Date: Thu Apr 24 13:58:36 2014 New Revision: 209748 URL: http://gcc.gnu.org/viewcvs?rev=209748&root=gcc&view=rev Log: 2014-04-24 Marc Glisse <marc.glisse@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
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
__float128 is still missing a specialization of numeric_limits.
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.
(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!
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.
(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...
Renaming since typeinfo is in gcc-5.
I suspect this has now been fixed with the additional of full _Float128 support in the C++ front-end and the library work.
(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.
(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.
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.
Hmm, yes. Well I think we can at least make std::is_integral<__int128> true, which will remove once source of surprises for users.