On Wed, 23 Apr 2014, Richard Henderson wrote:

On 04/13/2014 01:41 AM, Marc Glisse wrote:
Hello,

this patch generates typeinfo for target types. On x86_64, it adds these 6
lines to nm -C libsupc++.a. A follow-up patch will be needed to export and
version those in the shared library.

+0000000000000000 V typeinfo for __float128
+0000000000000000 V typeinfo for __float128 const*
+0000000000000000 V typeinfo for __float128*
+0000000000000000 V typeinfo name for __float128
+0000000000000000 V typeinfo name for __float128 const*
+0000000000000000 V typeinfo name for __float128*

Bootstrap and testsuite on x86_64-linux-gnu (a bit of noise in tsan/tls_race.c).

2014-04-13  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.


This is causing aarch64 builds to break.

If it is causing too much trouble, we could ifdef out the last 2 lines of emit_support_tinfos and revert the libstdc++ changes (or even revert the whole thing).

Any c++ compilation aborts at

That's surprising, the code I touched is only ever supposed to run while compiling one file in libsupc++, if I understand correctly.

#0  fancy_abort (file=0x14195c8 "../../git-rh/gcc/cp/mangle.c", line=2303,
   function=0x1419ff8 <write_builtin_type(tree_node*)::__FUNCTION__>
   "write_builtin_type") at ../../git-rh/gcc/diagnostic.c:1190
#1  0x00000000007ce2b4 in write_builtin_type (
   type=<real_type 0x7fb1653540 __builtin_aarch64_simd_df>)
   at ../../git-rh/gcc/cp/mangle.c:2303
#2  0x00000000007cc85c in write_type (
   type=<real_type 0x7fb1653540 __builtin_aarch64_simd_df>)
   at ../../git-rh/gcc/cp/mangle.c:1969
#3  0x00000000007d4d98 in mangle_special_for_type (
   type=<real_type 0x7fb1653540 __builtin_aarch64_simd_df>,
   code=0x1419a98 "TI") at ../../git-rh/gcc/cp/mangle.c:3569
#4  0x00000000007d4dcc in mangle_typeinfo_for_type (
   type=<real_type 0x7fb1653540 __builtin_aarch64_simd_df>)
   at ../../git-rh/gcc/cp/mangle.c:3585
#5  0x000000000070618c in get_tinfo_decl (
   type=<real_type 0x7fb1653540 __builtin_aarch64_simd_df>)
   at ../../git-rh/gcc/cp/rtti.c:422
#6  0x0000000000709ff0 in emit_support_tinfo_1 (
   bltn=<real_type 0x7fb1653540 __builtin_aarch64_simd_df>)
   at ../../git-rh/gcc/cp/rtti.c:1485
#7  0x000000000070a344 in emit_support_tinfos ()
   at ../../git-rh/gcc/cp/rtti.c:1550

Presumably the backend needs to grow some mangling support for its builtins,

aarch64 has complicated builtins... __builtin_aarch64_simd_df uses double_aarch64_type_node which is not the same as double_type_node. I mostly looked at the x86 backend, so I didn't notice that aarch64 registers a lot more builtins.

but in the meantime can we do something less drastic than abort?

Sounds good, but I am not sure how exactly. We could use a separate hook (register_builtin_type_for_typeinfo?) so back-ends have to explicitly say they want typeinfo, but it is ugly having to register types multiple times. We could add a parameter to the existing register_builtin_type saying whether we want typeinfo, but that means updating all back-ends. We could get the mangling functions to take a parameter that says whether errors should be fatal and skip generating the typeinfo when we can't mangle, but there is no convenient way to communicate this mangling failure (0 bytes written?).

Would mangling the aarch64 builtins be a lot of work? Did other platforms break as well?

Isn't this only really an issue if someone tries to access one of these types via typeinfo?

Yes.

--
Marc Glisse

Reply via email to