public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [c++] typeinfo for target types
@ 2014-04-13  8:41 Marc Glisse
  2014-04-14  4:16 ` Jason Merrill
  2014-04-23 18:48 ` Richard Henderson
  0 siblings, 2 replies; 12+ messages in thread
From: Marc Glisse @ 2014-04-13  8:41 UTC (permalink / raw)
  To: gcc-patches; +Cc: jason

[-- Attachment #1: Type: TEXT/PLAIN, Size: 958 bytes --]

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.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.

-- 
Marc Glisse

[-- Attachment #2: Type: TEXT/PLAIN, Size: 6425 bytes --]

Index: gcc/c-family/c-common.c
===================================================================
--- gcc/c-family/c-common.c	(revision 209345)
+++ gcc/c-family/c-common.c	(working copy)
@@ -3462,21 +3462,21 @@ c_common_fixed_point_type_for_size (unsi
 	     "fixed-point types that have too many integral and "
 	     "fractional bits together");
       return 0;
     }
 
   return c_common_type_for_mode (mode, satp);
 }
 
 /* Used for communication between c_common_type_for_mode and
    c_register_builtin_type.  */
-static GTY(()) tree registered_builtin_types;
+tree registered_builtin_types;
 
 /* Return a data type that has machine mode MODE.
    If the mode is an integer,
    then UNSIGNEDP selects between signed and unsigned types.
    If the mode is a fixed-point mode,
    then UNSIGNEDP selects between saturating and nonsaturating types.  */
 
 tree
 c_common_type_for_mode (enum machine_mode mode, int unsignedp)
 {
Index: gcc/c-family/c-common.h
===================================================================
--- gcc/c-family/c-common.h	(revision 209345)
+++ gcc/c-family/c-common.h	(working copy)
@@ -1006,20 +1006,24 @@ extern void do_warn_double_promotion (tr
 extern void set_underlying_type (tree);
 extern void record_locally_defined_typedef (tree);
 extern void maybe_record_typedef_use (tree);
 extern void maybe_warn_unused_local_typedefs (void);
 extern vec<tree, va_gc> *make_tree_vector (void);
 extern void release_tree_vector (vec<tree, va_gc> *);
 extern vec<tree, va_gc> *make_tree_vector_single (tree);
 extern vec<tree, va_gc> *make_tree_vector_from_list (tree);
 extern vec<tree, va_gc> *make_tree_vector_copy (const vec<tree, va_gc> *);
 
+/* Used for communication between c_common_type_for_mode and
+   c_register_builtin_type.  */
+extern GTY(()) tree registered_builtin_types;
+
 /* In c-gimplify.c  */
 extern void c_genericize (tree);
 extern int c_gimplify_expr (tree *, gimple_seq *, gimple_seq *);
 extern tree c_build_bind_expr (location_t, tree, tree);
 
 /* In c-pch.c  */
 extern void pch_init (void);
 extern void pch_cpp_save_state (void);
 extern int c_common_valid_pch (cpp_reader *pfile, const char *name, int fd);
 extern void c_common_read_pch (cpp_reader *pfile, const char *name, int fd,
Index: gcc/cp/rtti.c
===================================================================
--- gcc/cp/rtti.c	(revision 209345)
+++ gcc/cp/rtti.c	(working copy)
@@ -1458,20 +1458,58 @@ create_tinfo_types (void)
 		    FIELD_DECL, NULL_TREE, integer_type_node),
 	build_decl (BUILTINS_LOCATION,
 		    FIELD_DECL, NULL_TREE, type_info_ptr_type),
 	build_decl (BUILTINS_LOCATION,
 		    FIELD_DECL, NULL_TREE, type_info_ptr_type),
 	NULL);
 
   pop_abi_namespace ();
 }
 
+/* Helper for emit_support_tinfos. Emits the type_info descriptor of
+   a single type.  */
+
+void
+emit_support_tinfo_1 (tree bltn)
+{
+  tree types[3];
+
+  if (bltn == NULL_TREE)
+    return;
+  types[0] = bltn;
+  types[1] = build_pointer_type (bltn);
+  types[2] = build_pointer_type (cp_build_qualified_type (bltn,
+							  TYPE_QUAL_CONST));
+
+  for (int i = 0; i < 3; ++i)
+    {
+      tree tinfo = get_tinfo_decl (types[i]);
+      TREE_USED (tinfo) = 1;
+      mark_needed (tinfo);
+      /* The C++ ABI requires that these objects be COMDAT.  But,
+	 On systems without weak symbols, initialized COMDAT
+	 objects are emitted with internal linkage.  (See
+	 comdat_linkage for details.)  Since we want these objects
+	 to have external linkage so that copies do not have to be
+	 emitted in code outside the runtime library, we make them
+	 non-COMDAT here.  
+
+	 It might also not be necessary to follow this detail of the
+	 ABI.  */
+      if (!flag_weak || ! targetm.cxx.library_rtti_comdat ())
+	{
+	  gcc_assert (TREE_PUBLIC (tinfo) && !DECL_COMDAT (tinfo));
+	  DECL_INTERFACE_KNOWN (tinfo) = 1;
+	}
+    }
+}
+
 /* Emit the type_info descriptors which are guaranteed to be in the runtime
    support.  Generating them here guarantees consistency with the other
    structures.  We use the following heuristic to determine when the runtime
    is being generated.  If std::__fundamental_type_info is defined, and its
    destructor is defined, then the runtime is being built.  */
 
 void
 emit_support_tinfos (void)
 {
   /* Dummy static variable so we can put nullptr in the array; it will be
@@ -1500,56 +1538,23 @@ emit_support_tinfos (void)
 			get_identifier ("__fundamental_type_info"),
 			/*tag_scope=*/ts_current, false);
   pop_abi_namespace ();
   if (!COMPLETE_TYPE_P (bltn_type))
     return;
   dtor = CLASSTYPE_DESTRUCTORS (bltn_type);
   if (!dtor || DECL_EXTERNAL (dtor))
     return;
   doing_runtime = 1;
   for (ix = 0; fundamentals[ix]; ix++)
-    {
-      tree bltn = *fundamentals[ix];
-      tree types[3];
-      int i;
-
-      if (bltn == NULL_TREE)
-	continue;
-      types[0] = bltn;
-      types[1] = build_pointer_type (bltn);
-      types[2] = build_pointer_type (cp_build_qualified_type (bltn,
-							      TYPE_QUAL_CONST));
-
-      for (i = 0; i < 3; ++i)
-	{
-	  tree tinfo;
-
-	  tinfo = get_tinfo_decl (types[i]);
-	  TREE_USED (tinfo) = 1;
-	  mark_needed (tinfo);
-	  /* The C++ ABI requires that these objects be COMDAT.  But,
-	     On systems without weak symbols, initialized COMDAT
-	     objects are emitted with internal linkage.  (See
-	     comdat_linkage for details.)  Since we want these objects
-	     to have external linkage so that copies do not have to be
-	     emitted in code outside the runtime library, we make them
-	     non-COMDAT here.  
-
-	     It might also not be necessary to follow this detail of the
-	     ABI.  */
-	  if (!flag_weak || ! targetm.cxx.library_rtti_comdat ())
-	    {
-	      gcc_assert (TREE_PUBLIC (tinfo) && !DECL_COMDAT (tinfo));
-	      DECL_INTERFACE_KNOWN (tinfo) = 1;
-	    }
-	}
-    }
+    emit_support_tinfo_1 (*fundamentals[ix]);
+  for (tree t = registered_builtin_types; t; t = TREE_CHAIN (t))
+    emit_support_tinfo_1 (TREE_VALUE (t));
 }
 
 /* Finish a type info decl. DECL_PTR is a pointer to an unemitted
    tinfo decl.  Determine whether it needs emitting, and if so
    generate the initializer.  */
 
 bool
 emit_tinfo_decl (tree decl)
 {
   tree type = TREE_TYPE (DECL_NAME (decl));

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [c++] typeinfo for target types
  2014-04-13  8:41 [c++] typeinfo for target types Marc Glisse
@ 2014-04-14  4:16 ` Jason Merrill
  2014-04-23 18:48 ` Richard Henderson
  1 sibling, 0 replies; 12+ messages in thread
From: Jason Merrill @ 2014-04-14  4:16 UTC (permalink / raw)
  To: Marc Glisse, gcc-patches

On 04/13/2014 04:41 AM, Marc Glisse wrote:
> 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.

This looks fine, but shouldn't be checked in without that other patch.

Jason


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [c++] typeinfo for target types
  2014-04-13  8:41 [c++] typeinfo for target types Marc Glisse
  2014-04-14  4:16 ` Jason Merrill
@ 2014-04-23 18:48 ` Richard Henderson
  2014-04-23 19:44   ` Marc Glisse
  1 sibling, 1 reply; 12+ messages in thread
From: Richard Henderson @ 2014-04-23 18:48 UTC (permalink / raw)
  To: Marc Glisse, gcc-patches; +Cc: jason

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.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.
> 

This is causing aarch64 builds to break.  Any c++ compilation aborts at

#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,
but in the meantime can we do something less drastic than abort?  Isn't this
only really an issue if someone tries to access one of these types via typeinfo?


r~

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [c++] typeinfo for target types
  2014-04-23 18:48 ` Richard Henderson
@ 2014-04-23 19:44   ` Marc Glisse
  2014-04-23 20:35     ` Richard Henderson
                       ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Marc Glisse @ 2014-04-23 19:44 UTC (permalink / raw)
  To: Richard Henderson; +Cc: gcc-patches, jason

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.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.
>>
>
> 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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [c++] typeinfo for target types
  2014-04-23 19:44   ` Marc Glisse
@ 2014-04-23 20:35     ` Richard Henderson
  2014-04-24  8:49       ` Kyrill Tkachov
  2014-04-23 21:16     ` [AArch64] Broken builtin type mangling -- was " Richard Henderson
  2014-04-24 10:45     ` Ramana Radhakrishnan
  2 siblings, 1 reply; 12+ messages in thread
From: Richard Henderson @ 2014-04-23 20:35 UTC (permalink / raw)
  To: Marc Glisse; +Cc: gcc-patches, jason

On 04/23/2014 12:43 PM, Marc Glisse wrote:
>> 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.

Ah, well, perhaps it's one of the first built for stage1 libstdc++.
I admit to not digging much deeper.  ;-)

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

I've no idea on difficulty.  I've not yet checked other platforms.


r~

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [AArch64] Broken builtin type mangling -- was [c++] typeinfo for target types
  2014-04-23 19:44   ` Marc Glisse
  2014-04-23 20:35     ` Richard Henderson
@ 2014-04-23 21:16     ` Richard Henderson
  2014-04-24 10:45     ` Ramana Radhakrishnan
  2 siblings, 0 replies; 12+ messages in thread
From: Richard Henderson @ 2014-04-23 21:16 UTC (permalink / raw)
  To: Marc Glisse; +Cc: gcc-patches, jason, Marcus Shawcroft, Richard Earnshaw

On 04/23/2014 12:43 PM, Marc Glisse wrote:
> Would mangling the aarch64 builtins be a lot of work? Did other platforms break
> as well?

Hmm.  Apparently, aarch64 already *has* mangling support, but it's broken.

The node is built with DFmode in aarch64_init_simd_builtins, but then (not)
matched with V2DFmode in aarch64_mangle_type and its table.

The same appears to be true with every single one of the aarch64 backend types,
so I have no idea what is intended here.  I'm going to have to leave this to
the ARM maintainers to clear up.


r~

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [c++] typeinfo for target types
  2014-04-23 20:35     ` Richard Henderson
@ 2014-04-24  8:49       ` Kyrill Tkachov
  0 siblings, 0 replies; 12+ messages in thread
From: Kyrill Tkachov @ 2014-04-24  8:49 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Marc Glisse, gcc-patches, jason

On 23/04/14 21:35, Richard Henderson wrote:
> On 04/23/2014 12:43 PM, Marc Glisse wrote:
>>> 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.
> Ah, well, perhaps it's one of the first built for stage1 libstdc++.
> I admit to not digging much deeper.  ;-)
>
>> Would mangling the aarch64 builtins be a lot of work? Did other platforms break as well?
> I've no idea on difficulty.  I've not yet checked other platforms.

This affects arm as well. The same ICE in mangle.c.
The arm and aarch64 mangling code is very similar...

Kyrill

>
>
> r~
>


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [c++] typeinfo for target types
  2014-04-23 19:44   ` Marc Glisse
  2014-04-23 20:35     ` Richard Henderson
  2014-04-23 21:16     ` [AArch64] Broken builtin type mangling -- was " Richard Henderson
@ 2014-04-24 10:45     ` Ramana Radhakrishnan
  2014-04-24 13:25       ` Marc Glisse
  2 siblings, 1 reply; 12+ messages in thread
From: Ramana Radhakrishnan @ 2014-04-24 10:45 UTC (permalink / raw)
  To: Marc Glisse; +Cc: Richard Henderson, gcc-patches, Jason Merrill

On Wed, Apr 23, 2014 at 8:43 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> 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.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.
>>>
>>
>> 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.

Well some of these scalar types are not really user visible which is
where I believe the problem is coming from and prima-facie I don't
think we should be inventing mangling for some of these "internal"
types.

>  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?
>

It's not a lot of work but I'd like to make sure we're doing the right
thing on both AArch32 and AArch64. So, for now can we just revert this
till the thing is sorted out.

regards
Ramana

>
>> Isn't this only really an issue if someone tries to access one of these
>> types via typeinfo?
>
>
> Yes.
>
> --
> Marc Glisse

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [c++] typeinfo for target types
  2014-04-24 10:45     ` Ramana Radhakrishnan
@ 2014-04-24 13:25       ` Marc Glisse
  2014-04-24 13:44         ` Ramana Radhakrishnan
  2014-04-24 15:34         ` Tejas Belagod
  0 siblings, 2 replies; 12+ messages in thread
From: Marc Glisse @ 2014-04-24 13:25 UTC (permalink / raw)
  To: ramrad01; +Cc: Richard Henderson, gcc-patches, Jason Merrill

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5413 bytes --]

On Thu, 24 Apr 2014, Ramana Radhakrishnan wrote:

> On Wed, Apr 23, 2014 at 8:43 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
>> 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.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.
>>>>
>>>
>>> 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 also make typeinfo_in_lib_p more strict so for REAL_TYPE it only 
returns true for the types listed in fundamentals.

> Well some of these scalar types are not really user visible which is
> where I believe the problem is coming from and prima-facie I don't
> think we should be inventing mangling for some of these "internal"
> types.

If the types are not user-visible, it is not clear to me why they need to 
be registered with the front-end...

>>  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?
>
> It's not a lot of work but I'd like to make sure we're doing the right
> thing on both AArch32 and AArch64. So, for now can we just revert this
> till the thing is sorted out.

Ok, I'll commit the attached as soon as I've checked it isn't too broken. 
It is not a complete revert: splitting the rtti function is still cleaner, 
and the int128 symbols are still there.

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.

-- 
Marc Glisse

[-- Attachment #2: Type: TEXT/PLAIN, Size: 7888 bytes --]

Index: gcc/cp/rtti.c
===================================================================
--- gcc/cp/rtti.c	(revision 209747)
+++ gcc/cp/rtti.c	(working copy)
@@ -1539,22 +1539,20 @@ emit_support_tinfos (void)
 			/*tag_scope=*/ts_current, false);
   pop_abi_namespace ();
   if (!COMPLETE_TYPE_P (bltn_type))
     return;
   dtor = CLASSTYPE_DESTRUCTORS (bltn_type);
   if (!dtor || DECL_EXTERNAL (dtor))
     return;
   doing_runtime = 1;
   for (ix = 0; fundamentals[ix]; ix++)
     emit_support_tinfo_1 (*fundamentals[ix]);
-  for (tree t = registered_builtin_types; t; t = TREE_CHAIN (t))
-    emit_support_tinfo_1 (TREE_VALUE (t));
 }
 
 /* Finish a type info decl. DECL_PTR is a pointer to an unemitted
    tinfo decl.  Determine whether it needs emitting, and if so
    generate the initializer.  */
 
 bool
 emit_tinfo_decl (tree decl)
 {
   tree type = TREE_TYPE (DECL_NAME (decl));
Index: libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
===================================================================
--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt	(revision 209747)
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt	(working copy)
@@ -2618,21 +2618,20 @@ OBJECT:16:_ZTISt16nested_exception@@CXXA
 OBJECT:16:_ZTISt8ios_base@@GLIBCXX_3.4
 OBJECT:16:_ZTISt9exception@@GLIBCXX_3.4
 OBJECT:16:_ZTISt9time_base@@GLIBCXX_3.4
 OBJECT:16:_ZTISt9type_info@@GLIBCXX_3.4
 OBJECT:16:_ZTIa@@CXXABI_1.3
 OBJECT:16:_ZTIb@@CXXABI_1.3
 OBJECT:16:_ZTIc@@CXXABI_1.3
 OBJECT:16:_ZTId@@CXXABI_1.3
 OBJECT:16:_ZTIe@@CXXABI_1.3
 OBJECT:16:_ZTIf@@CXXABI_1.3
-OBJECT:16:_ZTIg@@CXXABI_1.3.9
 OBJECT:16:_ZTIh@@CXXABI_1.3
 OBJECT:16:_ZTIi@@CXXABI_1.3
 OBJECT:16:_ZTIj@@CXXABI_1.3
 OBJECT:16:_ZTIl@@CXXABI_1.3
 OBJECT:16:_ZTIm@@CXXABI_1.3
 OBJECT:16:_ZTIn@@CXXABI_1.3.5
 OBJECT:16:_ZTIo@@CXXABI_1.3.5
 OBJECT:16:_ZTIs@@CXXABI_1.3
 OBJECT:16:_ZTIt@@CXXABI_1.3
 OBJECT:16:_ZTIv@@CXXABI_1.3
@@ -3119,21 +3118,20 @@ OBJECT:2:_ZNSt10ctype_base5printE@@GLIBC
 OBJECT:2:_ZNSt10ctype_base5punctE@@GLIBCXX_3.4
 OBJECT:2:_ZNSt10ctype_base5spaceE@@GLIBCXX_3.4
 OBJECT:2:_ZNSt10ctype_base5upperE@@GLIBCXX_3.4
 OBJECT:2:_ZNSt10ctype_base6xdigitE@@GLIBCXX_3.4
 OBJECT:2:_ZTSa@@CXXABI_1.3
 OBJECT:2:_ZTSb@@CXXABI_1.3
 OBJECT:2:_ZTSc@@CXXABI_1.3
 OBJECT:2:_ZTSd@@CXXABI_1.3
 OBJECT:2:_ZTSe@@CXXABI_1.3
 OBJECT:2:_ZTSf@@CXXABI_1.3
-OBJECT:2:_ZTSg@@CXXABI_1.3.9
 OBJECT:2:_ZTSh@@CXXABI_1.3
 OBJECT:2:_ZTSi@@CXXABI_1.3
 OBJECT:2:_ZTSj@@CXXABI_1.3
 OBJECT:2:_ZTSl@@CXXABI_1.3
 OBJECT:2:_ZTSm@@CXXABI_1.3
 OBJECT:2:_ZTSn@@CXXABI_1.3.9
 OBJECT:2:_ZTSo@@CXXABI_1.3.9
 OBJECT:2:_ZTSs@@CXXABI_1.3
 OBJECT:2:_ZTSt@@CXXABI_1.3
 OBJECT:2:_ZTSv@@CXXABI_1.3
@@ -3153,41 +3151,39 @@ OBJECT:32:_ZTIPKDe@@CXXABI_1.3.4
 OBJECT:32:_ZTIPKDf@@CXXABI_1.3.4
 OBJECT:32:_ZTIPKDi@@CXXABI_1.3.3
 OBJECT:32:_ZTIPKDn@@CXXABI_1.3.5
 OBJECT:32:_ZTIPKDs@@CXXABI_1.3.3
 OBJECT:32:_ZTIPKa@@CXXABI_1.3
 OBJECT:32:_ZTIPKb@@CXXABI_1.3
 OBJECT:32:_ZTIPKc@@CXXABI_1.3
 OBJECT:32:_ZTIPKd@@CXXABI_1.3
 OBJECT:32:_ZTIPKe@@CXXABI_1.3
 OBJECT:32:_ZTIPKf@@CXXABI_1.3
-OBJECT:32:_ZTIPKg@@CXXABI_1.3.9
 OBJECT:32:_ZTIPKh@@CXXABI_1.3
 OBJECT:32:_ZTIPKi@@CXXABI_1.3
 OBJECT:32:_ZTIPKj@@CXXABI_1.3
 OBJECT:32:_ZTIPKl@@CXXABI_1.3
 OBJECT:32:_ZTIPKm@@CXXABI_1.3
 OBJECT:32:_ZTIPKn@@CXXABI_1.3.5
 OBJECT:32:_ZTIPKo@@CXXABI_1.3.5
 OBJECT:32:_ZTIPKs@@CXXABI_1.3
 OBJECT:32:_ZTIPKt@@CXXABI_1.3
 OBJECT:32:_ZTIPKv@@CXXABI_1.3
 OBJECT:32:_ZTIPKw@@CXXABI_1.3
 OBJECT:32:_ZTIPKx@@CXXABI_1.3
 OBJECT:32:_ZTIPKy@@CXXABI_1.3
 OBJECT:32:_ZTIPa@@CXXABI_1.3
 OBJECT:32:_ZTIPb@@CXXABI_1.3
 OBJECT:32:_ZTIPc@@CXXABI_1.3
 OBJECT:32:_ZTIPd@@CXXABI_1.3
 OBJECT:32:_ZTIPe@@CXXABI_1.3
 OBJECT:32:_ZTIPf@@CXXABI_1.3
-OBJECT:32:_ZTIPg@@CXXABI_1.3.9
 OBJECT:32:_ZTIPh@@CXXABI_1.3
 OBJECT:32:_ZTIPi@@CXXABI_1.3
 OBJECT:32:_ZTIPj@@CXXABI_1.3
 OBJECT:32:_ZTIPl@@CXXABI_1.3
 OBJECT:32:_ZTIPm@@CXXABI_1.3
 OBJECT:32:_ZTIPn@@CXXABI_1.3.5
 OBJECT:32:_ZTIPo@@CXXABI_1.3.5
 OBJECT:32:_ZTIPs@@CXXABI_1.3
 OBJECT:32:_ZTIPt@@CXXABI_1.3
 OBJECT:32:_ZTIPv@@CXXABI_1.3
@@ -3228,21 +3224,20 @@ OBJECT:39:_ZTSSt13basic_filebufIwSt11cha
 OBJECT:39:_ZTSSt13basic_fstreamIcSt11char_traitsIcEE@@GLIBCXX_3.4
 OBJECT:39:_ZTSSt13basic_fstreamIwSt11char_traitsIwEE@@GLIBCXX_3.4
 OBJECT:39:_ZTSSt13basic_istreamIwSt11char_traitsIwEE@@GLIBCXX_3.4
 OBJECT:39:_ZTSSt13basic_ostreamIwSt11char_traitsIwEE@@GLIBCXX_3.4
 OBJECT:3:_ZTSPa@@CXXABI_1.3
 OBJECT:3:_ZTSPb@@CXXABI_1.3
 OBJECT:3:_ZTSPc@@CXXABI_1.3
 OBJECT:3:_ZTSPd@@CXXABI_1.3
 OBJECT:3:_ZTSPe@@CXXABI_1.3
 OBJECT:3:_ZTSPf@@CXXABI_1.3
-OBJECT:3:_ZTSPg@@CXXABI_1.3.9
 OBJECT:3:_ZTSPh@@CXXABI_1.3
 OBJECT:3:_ZTSPi@@CXXABI_1.3
 OBJECT:3:_ZTSPj@@CXXABI_1.3
 OBJECT:3:_ZTSPl@@CXXABI_1.3
 OBJECT:3:_ZTSPm@@CXXABI_1.3
 OBJECT:3:_ZTSPn@@CXXABI_1.3.9
 OBJECT:3:_ZTSPo@@CXXABI_1.3.9
 OBJECT:3:_ZTSPs@@CXXABI_1.3
 OBJECT:3:_ZTSPt@@CXXABI_1.3
 OBJECT:3:_ZTSPv@@CXXABI_1.3
@@ -3558,21 +3553,20 @@ OBJECT:4:_ZNSt8ios_base8showbaseE@@GLIBC
 OBJECT:4:_ZNSt8ios_base9basefieldE@@GLIBCXX_3.4
 OBJECT:4:_ZNSt8ios_base9boolalphaE@@GLIBCXX_3.4
 OBJECT:4:_ZNSt8ios_base9showpointE@@GLIBCXX_3.4
 OBJECT:4:_ZNSt8ios_base9uppercaseE@@GLIBCXX_3.4
 OBJECT:4:_ZTSPKa@@CXXABI_1.3
 OBJECT:4:_ZTSPKb@@CXXABI_1.3
 OBJECT:4:_ZTSPKc@@CXXABI_1.3
 OBJECT:4:_ZTSPKd@@CXXABI_1.3
 OBJECT:4:_ZTSPKe@@CXXABI_1.3
 OBJECT:4:_ZTSPKf@@CXXABI_1.3
-OBJECT:4:_ZTSPKg@@CXXABI_1.3.9
 OBJECT:4:_ZTSPKh@@CXXABI_1.3
 OBJECT:4:_ZTSPKi@@CXXABI_1.3
 OBJECT:4:_ZTSPKj@@CXXABI_1.3
 OBJECT:4:_ZTSPKl@@CXXABI_1.3
 OBJECT:4:_ZTSPKm@@CXXABI_1.3
 OBJECT:4:_ZTSPKn@@CXXABI_1.3.9
 OBJECT:4:_ZTSPKo@@CXXABI_1.3.9
 OBJECT:4:_ZTSPKs@@CXXABI_1.3
 OBJECT:4:_ZTSPKt@@CXXABI_1.3
 OBJECT:4:_ZTSPKv@@CXXABI_1.3
Index: libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
===================================================================
--- libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver	(revision 209747)
+++ libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver	(working copy)
@@ -314,24 +314,24 @@ CXXABI_2.0 {
     # typeinfo for decimal floating point types
     _ZTID[fde];
     _ZTIPD[fde];
     _ZTIPKD[fde];
 
     # typeinfo for decltype(nullptr)
     _ZTIDn;
     _ZTIPDn;
     _ZTIPKDn;
 
-    # typeinfo for __int128, unsigned __int128 and __float128
-    _ZTI[gno];
-    _ZTIP[gno];
-    _ZTIPK[gno];
+    # typeinfo for __int128 and unsigned __int128
+    _ZTI[no];
+    _ZTIP[no];
+    _ZTIPK[no];
 
     # virtual table
     _ZTVN10__cxxabiv117__array_type_infoE;
     _ZTVN10__cxxabiv117__class_type_infoE;
     _ZTVN10__cxxabiv116__enum_type_infoE;
     _ZTVN10__cxxabiv120__function_type_infoE;
     _ZTVN10__cxxabiv123__fundamental_type_infoE;
     _ZTVN10__cxxabiv117__pbase_type_infoE;
     _ZTVN10__cxxabiv129__pointer_to_member_type_infoE;
     _ZTVN10__cxxabiv119__pointer_type_infoE;
Index: libstdc++-v3/config/abi/pre/gnu.ver
===================================================================
--- libstdc++-v3/config/abi/pre/gnu.ver	(revision 209747)
+++ libstdc++-v3/config/abi/pre/gnu.ver	(working copy)
@@ -1579,29 +1579,24 @@ CXXABI_1.3.8 {
     _Z16__VLTRegisterSet*;
     _Z21__VLTRegisterSetDebug*;
     _Z24__VLTVerifyVtablePointer*;
     _Z29__VLTVerifyVtablePointerDebug*;
     __VLTChangePermission;
 
 } CXXABI_1.3.7;
 
 CXXABI_1.3.9 {
 
-    # typeinfo name for __int128, unsigned __int128 and __float128
-    _ZTS[gno];
-    _ZTSP[gno];
-    _ZTSPK[gno];
-
-    # typeinfo for __float128
-    _ZTIg;
-    _ZTIPg;
-    _ZTIPKg;
+    # typeinfo name for __int128 and unsigned __int128
+    _ZTS[no];
+    _ZTSP[no];
+    _ZTSPK[no];
 
 } CXXABI_1.3.8;
 
 # Symbols in the support library (libsupc++) supporting transactional memory.
 CXXABI_TM_1 {
 
   global:
     __cxa_tm_cleanup;
 
 };

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [c++] typeinfo for target types
  2014-04-24 13:25       ` Marc Glisse
@ 2014-04-24 13:44         ` Ramana Radhakrishnan
  2014-04-24 14:22           ` Marc Glisse
  2014-04-24 15:34         ` Tejas Belagod
  1 sibling, 1 reply; 12+ messages in thread
From: Ramana Radhakrishnan @ 2014-04-24 13:44 UTC (permalink / raw)
  To: Marc Glisse; +Cc: Richard Henderson, gcc-patches, Jason Merrill

>> Well some of these scalar types are not really user visible which is
>> where I believe the problem is coming from and prima-facie I don't
>> think we should be inventing mangling for some of these "internal"
>> types.
>
>
> If the types are not user-visible, it is not clear to me why they need to be
> registered with the front-end...

The vector types that are built on this are user visible, so I suspect
that's why the scalar types need to be registered with the front-end.

A lot of this comes from the original support for the intrinsics way
that goes quite some time back so there is some digging needed here.

regards
Ramana

>
>
>>>  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?
>>
>>
>> It's not a lot of work but I'd like to make sure we're doing the right
>> thing on both AArch32 and AArch64. So, for now can we just revert this
>> till the thing is sorted out.
>
>
> Ok, I'll commit the attached as soon as I've checked it isn't too broken. It
> is not a complete revert: splitting the rtti function is still cleaner, and
> the int128 symbols are still there.
>
> 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.
>
> --
> Marc Glisse
> Index: gcc/cp/rtti.c
> ===================================================================
> --- gcc/cp/rtti.c       (revision 209747)
> +++ gcc/cp/rtti.c       (working copy)
> @@ -1539,22 +1539,20 @@ emit_support_tinfos (void)
>                         /*tag_scope=*/ts_current, false);
>    pop_abi_namespace ();
>    if (!COMPLETE_TYPE_P (bltn_type))
>      return;
>    dtor = CLASSTYPE_DESTRUCTORS (bltn_type);
>    if (!dtor || DECL_EXTERNAL (dtor))
>      return;
>    doing_runtime = 1;
>    for (ix = 0; fundamentals[ix]; ix++)
>      emit_support_tinfo_1 (*fundamentals[ix]);
> -  for (tree t = registered_builtin_types; t; t = TREE_CHAIN (t))
> -    emit_support_tinfo_1 (TREE_VALUE (t));
>  }
>
>  /* Finish a type info decl. DECL_PTR is a pointer to an unemitted
>     tinfo decl.  Determine whether it needs emitting, and if so
>     generate the initializer.  */
>
>  bool
>  emit_tinfo_decl (tree decl)
>  {
>    tree type = TREE_TYPE (DECL_NAME (decl));
> Index: libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
> ===================================================================
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
> (revision 209747)
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
> (working copy)
> @@ -2618,21 +2618,20 @@ OBJECT:16:_ZTISt16nested_exception@@CXXA
>  OBJECT:16:_ZTISt8ios_base@@GLIBCXX_3.4
>  OBJECT:16:_ZTISt9exception@@GLIBCXX_3.4
>  OBJECT:16:_ZTISt9time_base@@GLIBCXX_3.4
>  OBJECT:16:_ZTISt9type_info@@GLIBCXX_3.4
>  OBJECT:16:_ZTIa@@CXXABI_1.3
>  OBJECT:16:_ZTIb@@CXXABI_1.3
>  OBJECT:16:_ZTIc@@CXXABI_1.3
>  OBJECT:16:_ZTId@@CXXABI_1.3
>  OBJECT:16:_ZTIe@@CXXABI_1.3
>  OBJECT:16:_ZTIf@@CXXABI_1.3
> -OBJECT:16:_ZTIg@@CXXABI_1.3.9
>  OBJECT:16:_ZTIh@@CXXABI_1.3
>  OBJECT:16:_ZTIi@@CXXABI_1.3
>  OBJECT:16:_ZTIj@@CXXABI_1.3
>  OBJECT:16:_ZTIl@@CXXABI_1.3
>  OBJECT:16:_ZTIm@@CXXABI_1.3
>  OBJECT:16:_ZTIn@@CXXABI_1.3.5
>  OBJECT:16:_ZTIo@@CXXABI_1.3.5
>  OBJECT:16:_ZTIs@@CXXABI_1.3
>  OBJECT:16:_ZTIt@@CXXABI_1.3
>  OBJECT:16:_ZTIv@@CXXABI_1.3
> @@ -3119,21 +3118,20 @@ OBJECT:2:_ZNSt10ctype_base5printE@@GLIBC
>  OBJECT:2:_ZNSt10ctype_base5punctE@@GLIBCXX_3.4
>  OBJECT:2:_ZNSt10ctype_base5spaceE@@GLIBCXX_3.4
>  OBJECT:2:_ZNSt10ctype_base5upperE@@GLIBCXX_3.4
>  OBJECT:2:_ZNSt10ctype_base6xdigitE@@GLIBCXX_3.4
>  OBJECT:2:_ZTSa@@CXXABI_1.3
>  OBJECT:2:_ZTSb@@CXXABI_1.3
>  OBJECT:2:_ZTSc@@CXXABI_1.3
>  OBJECT:2:_ZTSd@@CXXABI_1.3
>  OBJECT:2:_ZTSe@@CXXABI_1.3
>  OBJECT:2:_ZTSf@@CXXABI_1.3
> -OBJECT:2:_ZTSg@@CXXABI_1.3.9
>  OBJECT:2:_ZTSh@@CXXABI_1.3
>  OBJECT:2:_ZTSi@@CXXABI_1.3
>  OBJECT:2:_ZTSj@@CXXABI_1.3
>  OBJECT:2:_ZTSl@@CXXABI_1.3
>  OBJECT:2:_ZTSm@@CXXABI_1.3
>  OBJECT:2:_ZTSn@@CXXABI_1.3.9
>  OBJECT:2:_ZTSo@@CXXABI_1.3.9
>  OBJECT:2:_ZTSs@@CXXABI_1.3
>  OBJECT:2:_ZTSt@@CXXABI_1.3
>  OBJECT:2:_ZTSv@@CXXABI_1.3
> @@ -3153,41 +3151,39 @@ OBJECT:32:_ZTIPKDe@@CXXABI_1.3.4
>  OBJECT:32:_ZTIPKDf@@CXXABI_1.3.4
>  OBJECT:32:_ZTIPKDi@@CXXABI_1.3.3
>  OBJECT:32:_ZTIPKDn@@CXXABI_1.3.5
>  OBJECT:32:_ZTIPKDs@@CXXABI_1.3.3
>  OBJECT:32:_ZTIPKa@@CXXABI_1.3
>  OBJECT:32:_ZTIPKb@@CXXABI_1.3
>  OBJECT:32:_ZTIPKc@@CXXABI_1.3
>  OBJECT:32:_ZTIPKd@@CXXABI_1.3
>  OBJECT:32:_ZTIPKe@@CXXABI_1.3
>  OBJECT:32:_ZTIPKf@@CXXABI_1.3
> -OBJECT:32:_ZTIPKg@@CXXABI_1.3.9
>  OBJECT:32:_ZTIPKh@@CXXABI_1.3
>  OBJECT:32:_ZTIPKi@@CXXABI_1.3
>  OBJECT:32:_ZTIPKj@@CXXABI_1.3
>  OBJECT:32:_ZTIPKl@@CXXABI_1.3
>  OBJECT:32:_ZTIPKm@@CXXABI_1.3
>  OBJECT:32:_ZTIPKn@@CXXABI_1.3.5
>  OBJECT:32:_ZTIPKo@@CXXABI_1.3.5
>  OBJECT:32:_ZTIPKs@@CXXABI_1.3
>  OBJECT:32:_ZTIPKt@@CXXABI_1.3
>  OBJECT:32:_ZTIPKv@@CXXABI_1.3
>  OBJECT:32:_ZTIPKw@@CXXABI_1.3
>  OBJECT:32:_ZTIPKx@@CXXABI_1.3
>  OBJECT:32:_ZTIPKy@@CXXABI_1.3
>  OBJECT:32:_ZTIPa@@CXXABI_1.3
>  OBJECT:32:_ZTIPb@@CXXABI_1.3
>  OBJECT:32:_ZTIPc@@CXXABI_1.3
>  OBJECT:32:_ZTIPd@@CXXABI_1.3
>  OBJECT:32:_ZTIPe@@CXXABI_1.3
>  OBJECT:32:_ZTIPf@@CXXABI_1.3
> -OBJECT:32:_ZTIPg@@CXXABI_1.3.9
>  OBJECT:32:_ZTIPh@@CXXABI_1.3
>  OBJECT:32:_ZTIPi@@CXXABI_1.3
>  OBJECT:32:_ZTIPj@@CXXABI_1.3
>  OBJECT:32:_ZTIPl@@CXXABI_1.3
>  OBJECT:32:_ZTIPm@@CXXABI_1.3
>  OBJECT:32:_ZTIPn@@CXXABI_1.3.5
>  OBJECT:32:_ZTIPo@@CXXABI_1.3.5
>  OBJECT:32:_ZTIPs@@CXXABI_1.3
>  OBJECT:32:_ZTIPt@@CXXABI_1.3
>  OBJECT:32:_ZTIPv@@CXXABI_1.3
> @@ -3228,21 +3224,20 @@ OBJECT:39:_ZTSSt13basic_filebufIwSt11cha
>  OBJECT:39:_ZTSSt13basic_fstreamIcSt11char_traitsIcEE@@GLIBCXX_3.4
>  OBJECT:39:_ZTSSt13basic_fstreamIwSt11char_traitsIwEE@@GLIBCXX_3.4
>  OBJECT:39:_ZTSSt13basic_istreamIwSt11char_traitsIwEE@@GLIBCXX_3.4
>  OBJECT:39:_ZTSSt13basic_ostreamIwSt11char_traitsIwEE@@GLIBCXX_3.4
>  OBJECT:3:_ZTSPa@@CXXABI_1.3
>  OBJECT:3:_ZTSPb@@CXXABI_1.3
>  OBJECT:3:_ZTSPc@@CXXABI_1.3
>  OBJECT:3:_ZTSPd@@CXXABI_1.3
>  OBJECT:3:_ZTSPe@@CXXABI_1.3
>  OBJECT:3:_ZTSPf@@CXXABI_1.3
> -OBJECT:3:_ZTSPg@@CXXABI_1.3.9
>  OBJECT:3:_ZTSPh@@CXXABI_1.3
>  OBJECT:3:_ZTSPi@@CXXABI_1.3
>  OBJECT:3:_ZTSPj@@CXXABI_1.3
>  OBJECT:3:_ZTSPl@@CXXABI_1.3
>  OBJECT:3:_ZTSPm@@CXXABI_1.3
>  OBJECT:3:_ZTSPn@@CXXABI_1.3.9
>  OBJECT:3:_ZTSPo@@CXXABI_1.3.9
>  OBJECT:3:_ZTSPs@@CXXABI_1.3
>  OBJECT:3:_ZTSPt@@CXXABI_1.3
>  OBJECT:3:_ZTSPv@@CXXABI_1.3
> @@ -3558,21 +3553,20 @@ OBJECT:4:_ZNSt8ios_base8showbaseE@@GLIBC
>  OBJECT:4:_ZNSt8ios_base9basefieldE@@GLIBCXX_3.4
>  OBJECT:4:_ZNSt8ios_base9boolalphaE@@GLIBCXX_3.4
>  OBJECT:4:_ZNSt8ios_base9showpointE@@GLIBCXX_3.4
>  OBJECT:4:_ZNSt8ios_base9uppercaseE@@GLIBCXX_3.4
>  OBJECT:4:_ZTSPKa@@CXXABI_1.3
>  OBJECT:4:_ZTSPKb@@CXXABI_1.3
>  OBJECT:4:_ZTSPKc@@CXXABI_1.3
>  OBJECT:4:_ZTSPKd@@CXXABI_1.3
>  OBJECT:4:_ZTSPKe@@CXXABI_1.3
>  OBJECT:4:_ZTSPKf@@CXXABI_1.3
> -OBJECT:4:_ZTSPKg@@CXXABI_1.3.9
>  OBJECT:4:_ZTSPKh@@CXXABI_1.3
>  OBJECT:4:_ZTSPKi@@CXXABI_1.3
>  OBJECT:4:_ZTSPKj@@CXXABI_1.3
>  OBJECT:4:_ZTSPKl@@CXXABI_1.3
>  OBJECT:4:_ZTSPKm@@CXXABI_1.3
>  OBJECT:4:_ZTSPKn@@CXXABI_1.3.9
>  OBJECT:4:_ZTSPKo@@CXXABI_1.3.9
>  OBJECT:4:_ZTSPKs@@CXXABI_1.3
>  OBJECT:4:_ZTSPKt@@CXXABI_1.3
>  OBJECT:4:_ZTSPKv@@CXXABI_1.3
> Index: libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> ===================================================================
> --- libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver     (revision
> 209747)
> +++ libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver     (working
> copy)
> @@ -314,24 +314,24 @@ CXXABI_2.0 {
>      # typeinfo for decimal floating point types
>      _ZTID[fde];
>      _ZTIPD[fde];
>      _ZTIPKD[fde];
>
>      # typeinfo for decltype(nullptr)
>      _ZTIDn;
>      _ZTIPDn;
>      _ZTIPKDn;
>
> -    # typeinfo for __int128, unsigned __int128 and __float128
> -    _ZTI[gno];
> -    _ZTIP[gno];
> -    _ZTIPK[gno];
> +    # typeinfo for __int128 and unsigned __int128
> +    _ZTI[no];
> +    _ZTIP[no];
> +    _ZTIPK[no];
>
>      # virtual table
>      _ZTVN10__cxxabiv117__array_type_infoE;
>      _ZTVN10__cxxabiv117__class_type_infoE;
>      _ZTVN10__cxxabiv116__enum_type_infoE;
>      _ZTVN10__cxxabiv120__function_type_infoE;
>      _ZTVN10__cxxabiv123__fundamental_type_infoE;
>      _ZTVN10__cxxabiv117__pbase_type_infoE;
>      _ZTVN10__cxxabiv129__pointer_to_member_type_infoE;
>      _ZTVN10__cxxabiv119__pointer_type_infoE;
> Index: libstdc++-v3/config/abi/pre/gnu.ver
> ===================================================================
> --- libstdc++-v3/config/abi/pre/gnu.ver (revision 209747)
> +++ libstdc++-v3/config/abi/pre/gnu.ver (working copy)
> @@ -1579,29 +1579,24 @@ CXXABI_1.3.8 {
>      _Z16__VLTRegisterSet*;
>      _Z21__VLTRegisterSetDebug*;
>      _Z24__VLTVerifyVtablePointer*;
>      _Z29__VLTVerifyVtablePointerDebug*;
>      __VLTChangePermission;
>
>  } CXXABI_1.3.7;
>
>  CXXABI_1.3.9 {
>
> -    # typeinfo name for __int128, unsigned __int128 and __float128
> -    _ZTS[gno];
> -    _ZTSP[gno];
> -    _ZTSPK[gno];
> -
> -    # typeinfo for __float128
> -    _ZTIg;
> -    _ZTIPg;
> -    _ZTIPKg;
> +    # typeinfo name for __int128 and unsigned __int128
> +    _ZTS[no];
> +    _ZTSP[no];
> +    _ZTSPK[no];
>
>  } CXXABI_1.3.8;
>
>  # Symbols in the support library (libsupc++) supporting transactional
> memory.
>  CXXABI_TM_1 {
>
>    global:
>      __cxa_tm_cleanup;
>
>  };
>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [c++] typeinfo for target types
  2014-04-24 13:44         ` Ramana Radhakrishnan
@ 2014-04-24 14:22           ` Marc Glisse
  0 siblings, 0 replies; 12+ messages in thread
From: Marc Glisse @ 2014-04-24 14:22 UTC (permalink / raw)
  To: ramrad01; +Cc: Richard Henderson, gcc-patches, Jason Merrill

On Thu, 24 Apr 2014, Ramana Radhakrishnan wrote:

>>> Well some of these scalar types are not really user visible which is
>>> where I believe the problem is coming from and prima-facie I don't
>>> think we should be inventing mangling for some of these "internal"
>>> types.
>>
>>
>> If the types are not user-visible, it is not clear to me why they need to be
>> registered with the front-end...
>
> The vector types that are built on this are user visible, so I suspect
> that's why the scalar types need to be registered with the front-end.
>
> A lot of this comes from the original support for the intrinsics way
> that goes quite some time back so there is some digging needed here.

Problematic part of the patch was reverted, arm and aarch64 should be ok
now. Please do investigate...

-- 
Marc Glisse

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [c++] typeinfo for target types
  2014-04-24 13:25       ` Marc Glisse
  2014-04-24 13:44         ` Ramana Radhakrishnan
@ 2014-04-24 15:34         ` Tejas Belagod
  1 sibling, 0 replies; 12+ messages in thread
From: Tejas Belagod @ 2014-04-24 15:34 UTC (permalink / raw)
  To: Marc Glisse
  Cc: Ramana Radhakrishnan, Richard Henderson, gcc-patches, Jason Merrill

Marc Glisse wrote:
> On Thu, 24 Apr 2014, Ramana Radhakrishnan wrote:
> 
>> On Wed, Apr 23, 2014 at 8:43 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
>>> 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.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.
>>>>>
>>>> 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 also make typeinfo_in_lib_p more strict so for REAL_TYPE it only 
> returns true for the types listed in fundamentals.
> 
>> Well some of these scalar types are not really user visible which is
>> where I believe the problem is coming from and prima-facie I don't
>> think we should be inventing mangling for some of these "internal"
>> types.
> 
> If the types are not user-visible, it is not clear to me why they need to 
> be registered with the front-end...

That's probably because of the way they are used in typedefs in arm_neon.h to 
build vector types and also them being used as internal base-type names to look 
up the mangling table.

Perhaps a cleaner solution is to build only the vector types in terms of 
standard base-types and not have to define back-end-specific scalar types just 
to build their vector types. That will also mean changing how the mangling names 
are looked up ARM/AArch64 backend...

Tejas.

> 
>>>  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?
>> It's not a lot of work but I'd like to make sure we're doing the right
>> thing on both AArch32 and AArch64. So, for now can we just revert this
>> till the thing is sorted out.
> 
> Ok, I'll commit the attached as soon as I've checked it isn't too broken. 
> It is not a complete revert: splitting the rtti function is still cleaner, 
> and the int128 symbols are still there.
> 
> 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.
> 
> 


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2014-04-24 15:31 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-13  8:41 [c++] typeinfo for target types Marc Glisse
2014-04-14  4:16 ` Jason Merrill
2014-04-23 18:48 ` Richard Henderson
2014-04-23 19:44   ` Marc Glisse
2014-04-23 20:35     ` Richard Henderson
2014-04-24  8:49       ` Kyrill Tkachov
2014-04-23 21:16     ` [AArch64] Broken builtin type mangling -- was " Richard Henderson
2014-04-24 10:45     ` Ramana Radhakrishnan
2014-04-24 13:25       ` Marc Glisse
2014-04-24 13:44         ` Ramana Radhakrishnan
2014-04-24 14:22           ` Marc Glisse
2014-04-24 15:34         ` Tejas Belagod

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).