public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* ipa-visibility TLC 2/n
@ 2014-05-25  5:54 Jan Hubicka
  2014-05-25 20:45 ` Ramana Radhakrishnan
  2014-05-26 15:39 ` Martin Liška
  0 siblings, 2 replies; 44+ messages in thread
From: Jan Hubicka @ 2014-05-25  5:54 UTC (permalink / raw)
  To: gcc-patches

Hi,
this patch adds code to rerite references in vtable initializers to local aliases
when doing so is a win.

Bootstrapped/regtested x86_64-linux, comitted.

Honza

	* ipa-visibility.c (can_replace_by_local_alias_in_vtable): New function.
	(update_vtable_references): New function.
	(function_and_variable_visibility): Rewrite also vtable initializers.
	* varpool.c (cgraph_variable_initializer_availability): Remove assert.
Index: varpool.c
===================================================================
--- varpool.c	(revision 210908)
+++ varpool.c	(working copy)
@@ -355,7 +355,6 @@ varpool_add_new_variable (tree decl)
 enum availability
 cgraph_variable_initializer_availability (varpool_node *node)
 {
-  gcc_assert (cgraph_function_flags_ready);
   if (!node->definition)
     return AVAIL_NOT_AVAILABLE;
   if (!TREE_PUBLIC (node->decl))
Index: ipa-visibility.c
===================================================================
--- ipa-visibility.c	(revision 210908)
+++ ipa-visibility.c	(working copy)
@@ -343,6 +343,36 @@ can_replace_by_local_alias (symtab_node
 	  && !symtab_can_be_discarded (node));
 }
 
+/* Return true if we can replace refernece to NODE by local alias
+   within a virtual table.  Generally we can replace function pointers
+   and virtual table pointers.  */
+
+bool
+can_replace_by_local_alias_in_vtable (symtab_node *node)
+{
+  if (is_a <varpool_node *> (node)
+      && !DECL_VIRTUAL_P (node->decl))
+    return false;
+  return can_replace_by_local_alias (node);
+}
+
+/* walk_tree callback that rewrites initializer references.   */
+
+static tree
+update_vtable_references (tree *tp, int *walk_subtrees, void *data ATTRIBUTE_UNUSED)
+{
+  if (TREE_CODE (*tp) == VAR_DECL
+      || TREE_CODE (*tp) == FUNCTION_DECL)
+    {
+      if (can_replace_by_local_alias_in_vtable (symtab_get_node (*tp)))
+	*tp = symtab_nonoverwritable_alias (symtab_get_node (*tp))->decl;
+      *walk_subtrees = 0;
+    }
+  else if (IS_TYPE_OR_DECL_P (*tp))
+    *walk_subtrees = 0;
+  return NULL;
+}
+
 /* In LTO we can remove COMDAT groups and weak symbols.
    Either turn them into normal symbols or external symbol depending on 
    resolution info.  */
@@ -625,6 +655,34 @@ function_and_variable_visibility (bool w
 	  vnode->resolution = LDPR_PREVAILING_DEF_IRONLY;
 	}
       update_visibility_by_resolution_info (vnode);
+
+      /* Update virutal tables to point to local aliases where possible.  */
+      if (DECL_VIRTUAL_P (vnode->decl)
+	  && !DECL_EXTERNAL (vnode->decl))
+	{
+	  int i;
+	  struct ipa_ref *ref;
+	  bool found = false;
+
+	  /* See if there is something to update.  */
+	  for (i = 0; ipa_ref_list_referring_iterate (&vnode->ref_list,
+						      i, ref); i++)
+	    if (ref->use == IPA_REF_ADDR
+		&& can_replace_by_local_alias_in_vtable (ref->referred))
+	      {
+	        found = true;
+		break;
+	      }
+	  if (found)
+	    {
+	      struct pointer_set_t *visited_nodes = pointer_set_create ();
+	      walk_tree (&DECL_INITIAL (vnode->decl),
+			 update_vtable_references, NULL, visited_nodes);
+	      pointer_set_destroy (visited_nodes);
+	      ipa_remove_all_references (&vnode->ref_list);
+	      record_references_in_initializer (vnode->decl, false);
+	    }
+	}
     }
 
   if (dump_file)

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

* Re: ipa-visibility TLC 2/n
  2014-05-25  5:54 ipa-visibility TLC 2/n Jan Hubicka
@ 2014-05-25 20:45 ` Ramana Radhakrishnan
  2014-05-25 22:23   ` Jan Hubicka
  2014-05-26 15:39 ` Martin Liška
  1 sibling, 1 reply; 44+ messages in thread
From: Ramana Radhakrishnan @ 2014-05-25 20:45 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: gcc-patches

On Sun, May 25, 2014 at 6:54 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> Hi,
> this patch adds code to rerite references in vtable initializers to local aliases
> when doing so is a win.
>
> Bootstrapped/regtested x86_64-linux, comitted.

This is the most likely patch to have caused build failures on
arm-linux-gnueabihf

My last successful build was 210908 as is evident from

http://gcc.gnu.org/ml/gcc-testresults/2014-05/msg02245.html

and between that and 210913 builds failed with the following error message.

I haven't dug further yet.


libtool: compile:
/work/trunk-nightlies/builds/build-210913/./gcc/xgcc -shared-libgcc
-B/work/trunk-nightlies/builds/build-210913/./gcc -nostdinc++
-L/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/src
-L/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs
-L/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-B/work/trunk-nightlies/installs/install-210913/armv7l-unknown-linux-gnueabihf/bin/
-B/work/trunk-nightlies/installs/install-210913/armv7l-unknown-linux-gnueabihf/lib/
-isystem /work/trunk-nightlies/installs/install-210913/armv7l-unknown-linux-gnueabihf/include
-isystem /work/trunk-nightlies/installs/install-210913/armv7l-unknown-linux-gnueabihf/sys-include
-I/work/gcc/libstdc++-v3/../libgcc
-I/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/armv7l-unknown-linux-gnueabihf
-I/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include
-I/work/gcc/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=strstream.lo -g -O2 -D_GNU_SOURCE
-I/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward
-Wno-deprecated -c /work/gcc/libstdc++-v3/src/c++98/strstream.cc
-fPIC -DPIC -D_GLIBCXX_SHARED -o strstream.o
In file included from /work/gcc/libstdc++-v3/src/c++98/strstream.cc:44:0:
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:126:9:
error: std::istrstream::_ZTVSt10istrstream.localalias.0 causes a
section type conflict with std::istrstream::_ZTVSt10istrstream
   class istrstream : public basic_istream<char>
         ^
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:126:9:
note: _std::istrstream::_ZTVSt10istrstream_ was declared here
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:143:9:
error: std::ostrstream::_ZTVSt10ostrstream.localalias.1 causes a
section type conflict with std::ostrstream::_ZTVSt10ostrstream
   class ostrstream : public basic_ostream<char>
         ^
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:143:9:
note: _std::ostrstream::_ZTVSt10ostrstream_ was declared here
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:160:9:
error: std::strstream::_ZTVSt9strstream.localalias.2 causes a section
type conflict with std::strstream::_ZTVSt9strstream
   class strstream : public basic_iostream<char>
         ^
/work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:160:9:
note: _std::strstream::_ZTVSt9strstream_ was declared here


regards
Ramana


>
> Honza
>
>         * ipa-visibility.c (can_replace_by_local_alias_in_vtable): New function.
>         (update_vtable_references): New function.
>         (function_and_variable_visibility): Rewrite also vtable initializers.
>         * varpool.c (cgraph_variable_initializer_availability): Remove assert.
> Index: varpool.c
> ===================================================================
> --- varpool.c   (revision 210908)
> +++ varpool.c   (working copy)
> @@ -355,7 +355,6 @@ varpool_add_new_variable (tree decl)
>  enum availability
>  cgraph_variable_initializer_availability (varpool_node *node)
>  {
> -  gcc_assert (cgraph_function_flags_ready);
>    if (!node->definition)
>      return AVAIL_NOT_AVAILABLE;
>    if (!TREE_PUBLIC (node->decl))
> Index: ipa-visibility.c
> ===================================================================
> --- ipa-visibility.c    (revision 210908)
> +++ ipa-visibility.c    (working copy)
> @@ -343,6 +343,36 @@ can_replace_by_local_alias (symtab_node
>           && !symtab_can_be_discarded (node));
>  }
>
> +/* Return true if we can replace refernece to NODE by local alias
> +   within a virtual table.  Generally we can replace function pointers
> +   and virtual table pointers.  */
> +
> +bool
> +can_replace_by_local_alias_in_vtable (symtab_node *node)
> +{
> +  if (is_a <varpool_node *> (node)
> +      && !DECL_VIRTUAL_P (node->decl))
> +    return false;
> +  return can_replace_by_local_alias (node);
> +}
> +
> +/* walk_tree callback that rewrites initializer references.   */
> +
> +static tree
> +update_vtable_references (tree *tp, int *walk_subtrees, void *data ATTRIBUTE_UNUSED)
> +{
> +  if (TREE_CODE (*tp) == VAR_DECL
> +      || TREE_CODE (*tp) == FUNCTION_DECL)
> +    {
> +      if (can_replace_by_local_alias_in_vtable (symtab_get_node (*tp)))
> +       *tp = symtab_nonoverwritable_alias (symtab_get_node (*tp))->decl;
> +      *walk_subtrees = 0;
> +    }
> +  else if (IS_TYPE_OR_DECL_P (*tp))
> +    *walk_subtrees = 0;
> +  return NULL;
> +}
> +
>  /* In LTO we can remove COMDAT groups and weak symbols.
>     Either turn them into normal symbols or external symbol depending on
>     resolution info.  */
> @@ -625,6 +655,34 @@ function_and_variable_visibility (bool w
>           vnode->resolution = LDPR_PREVAILING_DEF_IRONLY;
>         }
>        update_visibility_by_resolution_info (vnode);
> +
> +      /* Update virutal tables to point to local aliases where possible.  */
> +      if (DECL_VIRTUAL_P (vnode->decl)
> +         && !DECL_EXTERNAL (vnode->decl))
> +       {
> +         int i;
> +         struct ipa_ref *ref;
> +         bool found = false;
> +
> +         /* See if there is something to update.  */
> +         for (i = 0; ipa_ref_list_referring_iterate (&vnode->ref_list,
> +                                                     i, ref); i++)
> +           if (ref->use == IPA_REF_ADDR
> +               && can_replace_by_local_alias_in_vtable (ref->referred))
> +             {
> +               found = true;
> +               break;
> +             }
> +         if (found)
> +           {
> +             struct pointer_set_t *visited_nodes = pointer_set_create ();
> +             walk_tree (&DECL_INITIAL (vnode->decl),
> +                        update_vtable_references, NULL, visited_nodes);
> +             pointer_set_destroy (visited_nodes);
> +             ipa_remove_all_references (&vnode->ref_list);
> +             record_references_in_initializer (vnode->decl, false);
> +           }
> +       }
>      }
>
>    if (dump_file)

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

* Re: ipa-visibility TLC 2/n
  2014-05-25 20:45 ` Ramana Radhakrishnan
@ 2014-05-25 22:23   ` Jan Hubicka
  2014-05-26  1:04     ` Jan Hubicka
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-05-25 22:23 UTC (permalink / raw)
  To: ramrad01; +Cc: Jan Hubicka, gcc-patches

> On Sun, May 25, 2014 at 6:54 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> > Hi,
> > this patch adds code to rerite references in vtable initializers to local aliases
> > when doing so is a win.
> >
> > Bootstrapped/regtested x86_64-linux, comitted.
> 
> This is the most likely patch to have caused build failures on
> arm-linux-gnueabihf
>          ^
> /work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:143:9:
> note: _std::ostrstream::_ZTVSt10ostrstream_ was declared here
> /work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:160:9:
> error: std::strstream::_ZTVSt9strstream.localalias.2 causes a section
> type conflict with std::strstream::_ZTVSt9strstream
>    class strstream : public basic_iostream<char>
>          ^
> /work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:160:9:
> note: _std::strstream::_ZTVSt9strstream_ was declared here

I suppose it is because wrong readonly flag on the alias created. Does the following patch help?

Index: symtab.c
===================================================================
--- symtab.c	(revision 210914)
+++ symtab.c	(working copy)
@@ -1163,7 +1163,10 @@
 				 (new_decl, node->decl);
     }
   else
-    new_node = varpool_create_variable_alias (new_decl, node->decl);
+    {
+      DECL_READONLY (new_decl) = DECL_READONLY (node->decl);
+      new_node = varpool_create_variable_alias (new_decl, node->decl);
+    }
   symtab_resolve_alias (new_node, node);  
   gcc_assert (decl_binds_to_current_def_p (new_decl));
   return new_node;
> 
> 
> regards
> Ramana
> 
> 
> >
> > Honza
> >
> >         * ipa-visibility.c (can_replace_by_local_alias_in_vtable): New function.
> >         (update_vtable_references): New function.
> >         (function_and_variable_visibility): Rewrite also vtable initializers.
> >         * varpool.c (cgraph_variable_initializer_availability): Remove assert.
> > Index: varpool.c
> > ===================================================================
> > --- varpool.c   (revision 210908)
> > +++ varpool.c   (working copy)
> > @@ -355,7 +355,6 @@ varpool_add_new_variable (tree decl)
> >  enum availability
> >  cgraph_variable_initializer_availability (varpool_node *node)
> >  {
> > -  gcc_assert (cgraph_function_flags_ready);
> >    if (!node->definition)
> >      return AVAIL_NOT_AVAILABLE;
> >    if (!TREE_PUBLIC (node->decl))
> > Index: ipa-visibility.c
> > ===================================================================
> > --- ipa-visibility.c    (revision 210908)
> > +++ ipa-visibility.c    (working copy)
> > @@ -343,6 +343,36 @@ can_replace_by_local_alias (symtab_node
> >           && !symtab_can_be_discarded (node));
> >  }
> >
> > +/* Return true if we can replace refernece to NODE by local alias
> > +   within a virtual table.  Generally we can replace function pointers
> > +   and virtual table pointers.  */
> > +
> > +bool
> > +can_replace_by_local_alias_in_vtable (symtab_node *node)
> > +{
> > +  if (is_a <varpool_node *> (node)
> > +      && !DECL_VIRTUAL_P (node->decl))
> > +    return false;
> > +  return can_replace_by_local_alias (node);
> > +}
> > +
> > +/* walk_tree callback that rewrites initializer references.   */
> > +
> > +static tree
> > +update_vtable_references (tree *tp, int *walk_subtrees, void *data ATTRIBUTE_UNUSED)
> > +{
> > +  if (TREE_CODE (*tp) == VAR_DECL
> > +      || TREE_CODE (*tp) == FUNCTION_DECL)
> > +    {
> > +      if (can_replace_by_local_alias_in_vtable (symtab_get_node (*tp)))
> > +       *tp = symtab_nonoverwritable_alias (symtab_get_node (*tp))->decl;
> > +      *walk_subtrees = 0;
> > +    }
> > +  else if (IS_TYPE_OR_DECL_P (*tp))
> > +    *walk_subtrees = 0;
> > +  return NULL;
> > +}
> > +
> >  /* In LTO we can remove COMDAT groups and weak symbols.
> >     Either turn them into normal symbols or external symbol depending on
> >     resolution info.  */
> > @@ -625,6 +655,34 @@ function_and_variable_visibility (bool w
> >           vnode->resolution = LDPR_PREVAILING_DEF_IRONLY;
> >         }
> >        update_visibility_by_resolution_info (vnode);
> > +
> > +      /* Update virutal tables to point to local aliases where possible.  */
> > +      if (DECL_VIRTUAL_P (vnode->decl)
> > +         && !DECL_EXTERNAL (vnode->decl))
> > +       {
> > +         int i;
> > +         struct ipa_ref *ref;
> > +         bool found = false;
> > +
> > +         /* See if there is something to update.  */
> > +         for (i = 0; ipa_ref_list_referring_iterate (&vnode->ref_list,
> > +                                                     i, ref); i++)
> > +           if (ref->use == IPA_REF_ADDR
> > +               && can_replace_by_local_alias_in_vtable (ref->referred))
> > +             {
> > +               found = true;
> > +               break;
> > +             }
> > +         if (found)
> > +           {
> > +             struct pointer_set_t *visited_nodes = pointer_set_create ();
> > +             walk_tree (&DECL_INITIAL (vnode->decl),
> > +                        update_vtable_references, NULL, visited_nodes);
> > +             pointer_set_destroy (visited_nodes);
> > +             ipa_remove_all_references (&vnode->ref_list);
> > +             record_references_in_initializer (vnode->decl, false);
> > +           }
> > +       }
> >      }
> >
> >    if (dump_file)

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

* Re: ipa-visibility TLC 2/n
  2014-05-25 22:23   ` Jan Hubicka
@ 2014-05-26  1:04     ` Jan Hubicka
  2014-05-26  5:29       ` Ramana Radhakrishnan
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-05-26  1:04 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: ramrad01, gcc-patches

> > On Sun, May 25, 2014 at 6:54 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> > > Hi,
> > > this patch adds code to rerite references in vtable initializers to local aliases
> > > when doing so is a win.
> > >
> > > Bootstrapped/regtested x86_64-linux, comitted.
> > 
> > This is the most likely patch to have caused build failures on
> > arm-linux-gnueabihf
> >          ^
> > /work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:143:9:
> > note: _std::ostrstream::_ZTVSt10ostrstream_ was declared here
> > /work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:160:9:
> > error: std::strstream::_ZTVSt9strstream.localalias.2 causes a section
> > type conflict with std::strstream::_ZTVSt9strstream
> >    class strstream : public basic_iostream<char>
> >          ^
> > /work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:160:9:
> > note: _std::strstream::_ZTVSt9strstream_ was declared here
> 
> I suppose it is because wrong readonly flag on the alias created. Does the following patch help?

I bootstrapped & comitted the patch in meantime.  Even if it does not fix the error, it is obviously
right thing to do.

Honza

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

* Re: ipa-visibility TLC 2/n
  2014-05-26  1:04     ` Jan Hubicka
@ 2014-05-26  5:29       ` Ramana Radhakrishnan
  2014-05-27 20:06         ` Jan Hubicka
  0 siblings, 1 reply; 44+ messages in thread
From: Ramana Radhakrishnan @ 2014-05-26  5:29 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: gcc-patches

On Mon, May 26, 2014 at 2:04 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > On Sun, May 25, 2014 at 6:54 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > > Hi,
>> > > this patch adds code to rerite references in vtable initializers to local aliases
>> > > when doing so is a win.
>> > >
>> > > Bootstrapped/regtested x86_64-linux, comitted.
>> >
>> > This is the most likely patch to have caused build failures on
>> > arm-linux-gnueabihf
>> >          ^
>> > /work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:143:9:
>> > note: _std::ostrstream::_ZTVSt10ostrstream_ was declared here
>> > /work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:160:9:
>> > error: std::strstream::_ZTVSt9strstream.localalias.2 causes a section
>> > type conflict with std::strstream::_ZTVSt9strstream
>> >    class strstream : public basic_iostream<char>
>> >          ^
>> > /work/trunk-nightlies/builds/build-210913/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/backward/strstream:160:9:
>> > note: _std::strstream::_ZTVSt9strstream_ was declared here
>>
>> I suppose it is because wrong readonly flag on the alias created. Does the following patch help?
>
> I bootstrapped & comitted the patch in meantime.  Even if it does not fix the error, it is obviously
> right thing to do.

Sadly this doesn't appear to have fixed the issue.

Ramana
>
> Honza

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

* Re: ipa-visibility TLC 2/n
  2014-05-25  5:54 ipa-visibility TLC 2/n Jan Hubicka
  2014-05-25 20:45 ` Ramana Radhakrishnan
@ 2014-05-26 15:39 ` Martin Liška
  1 sibling, 0 replies; 44+ messages in thread
From: Martin Liška @ 2014-05-26 15:39 UTC (permalink / raw)
  To: gcc-patches


On 05/25/2014 07:54 AM, Jan Hubicka wrote:
> Hi,
> this patch adds code to rerite references in vtable initializers to local aliases
> when doing so is a win.
>
> Bootstrapped/regtested x86_64-linux, comitted.
>
> Honza
>
> 	* ipa-visibility.c (can_replace_by_local_alias_in_vtable): New function.
> 	(update_vtable_references): New function.
> 	(function_and_variable_visibility): Rewrite also vtable initializers.
> 	* varpool.c (cgraph_variable_initializer_availability): Remove assert.
> Index: varpool.c
> ===================================================================
> --- varpool.c	(revision 210908)
> +++ varpool.c	(working copy)
> @@ -355,7 +355,6 @@ varpool_add_new_variable (tree decl)
>   enum availability
>   cgraph_variable_initializer_availability (varpool_node *node)
>   {
> -  gcc_assert (cgraph_function_flags_ready);
>     if (!node->definition)
>       return AVAIL_NOT_AVAILABLE;
>     if (!TREE_PUBLIC (node->decl))
> Index: ipa-visibility.c
> ===================================================================
> --- ipa-visibility.c	(revision 210908)
> +++ ipa-visibility.c	(working copy)
> @@ -343,6 +343,36 @@ can_replace_by_local_alias (symtab_node
>   	  && !symtab_can_be_discarded (node));
>   }
>   
> +/* Return true if we can replace refernece to NODE by local alias

Hello Jan,

s/refernece/reference

> +   within a virtual table.  Generally we can replace function pointers
> +   and virtual table pointers.  */
> +
> +bool
> +can_replace_by_local_alias_in_vtable (symtab_node *node)
> +{
> +  if (is_a <varpool_node *> (node)
> +      && !DECL_VIRTUAL_P (node->decl))
> +    return false;
> +  return can_replace_by_local_alias (node);
> +}
> +
> +/* walk_tree callback that rewrites initializer references.   */
> +
> +static tree
> +update_vtable_references (tree *tp, int *walk_subtrees, void *data ATTRIBUTE_UNUSED)
> +{
> +  if (TREE_CODE (*tp) == VAR_DECL
> +      || TREE_CODE (*tp) == FUNCTION_DECL)
> +    {
> +      if (can_replace_by_local_alias_in_vtable (symtab_get_node (*tp)))
> +	*tp = symtab_nonoverwritable_alias (symtab_get_node (*tp))->decl;
> +      *walk_subtrees = 0;
> +    }
> +  else if (IS_TYPE_OR_DECL_P (*tp))
> +    *walk_subtrees = 0;
> +  return NULL;
> +}
> +
>   /* In LTO we can remove COMDAT groups and weak symbols.
>      Either turn them into normal symbols or external symbol depending on
>      resolution info.  */
> @@ -625,6 +655,34 @@ function_and_variable_visibility (bool w
>   	  vnode->resolution = LDPR_PREVAILING_DEF_IRONLY;
>   	}
>         update_visibility_by_resolution_info (vnode);
> +
> +      /* Update virutal tables to point to local aliases where possible.  */
s/virutal/virtual

Martin
> +      if (DECL_VIRTUAL_P (vnode->decl)
> +	  && !DECL_EXTERNAL (vnode->decl))
> +	{
> +	  int i;
> +	  struct ipa_ref *ref;
> +	  bool found = false;
> +
> +	  /* See if there is something to update.  */
> +	  for (i = 0; ipa_ref_list_referring_iterate (&vnode->ref_list,
> +						      i, ref); i++)
> +	    if (ref->use == IPA_REF_ADDR
> +		&& can_replace_by_local_alias_in_vtable (ref->referred))
> +	      {
> +	        found = true;
> +		break;
> +	      }
> +	  if (found)
> +	    {
> +	      struct pointer_set_t *visited_nodes = pointer_set_create ();
> +	      walk_tree (&DECL_INITIAL (vnode->decl),
> +			 update_vtable_references, NULL, visited_nodes);
> +	      pointer_set_destroy (visited_nodes);
> +	      ipa_remove_all_references (&vnode->ref_list);
> +	      record_references_in_initializer (vnode->decl, false);
> +	    }
> +	}
>       }
>   
>     if (dump_file)

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

* Re: ipa-visibility TLC 2/n
  2014-05-26  5:29       ` Ramana Radhakrishnan
@ 2014-05-27 20:06         ` Jan Hubicka
  2014-05-27 22:20           ` Jan Hubicka
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-05-27 20:06 UTC (permalink / raw)
  To: ramrad01; +Cc: Jan Hubicka, gcc-patches, rth

> 
> Sadly this doesn't appear to have fixed the issue.

I have now reproduced it on AIX. We die at:
          /* Sanity check user variables for flag changes.  */
          if (sect->named.decl != NULL
              && DECL_P (sect->named.decl)
              && decl != sect->named.decl)
            {
              if (decl != NULL && DECL_P (decl))
                error ("%+D causes a section type conflict with %D",
                       decl, sect->named.decl);
              else
                error ("section type conflict with %D", sect->named.decl);
              inform (DECL_SOURCE_LOCATION (sect->named.decl),
                      "%qD was declared here", sect->named.decl);
            }

here we have decl and its local alias:
(gdb) p debug_tree (sect->named.decl)
 <var_decl 70f7d060 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
    type <array_type 70dd8840
        type <pointer_type 700f5840 __vtbl_ptr_type type <function_type 700f57e0>
            unsigned SI
            size <integer_cst 70006498 constant 32>
            unit size <integer_cst 700064b0 constant 4>
            align 32 symtab 45 alias set 3 canonical type 700f5840
            pointer_to_this <pointer_type 700f5900>>
        BLK
        size <integer_cst 708002d0 constant 320>
        unit size <integer_cst 708000d8 constant 40>
        align 32 symtab 0 alias set 3 canonical type 70dd8840
        domain <integer_type 701a78a0 type <integer_type 7001d000 sizetype>
            type_6 SI size <integer_cst 70006498 32> unit size <integer_cst 700064b0 4>
            align 32 symtab 0 alias set -1 canonical type 701a78a0 precision 32 min <integer_cst 700064c8 0> max <integer_cst 701a5b88 9>>
        pointer_to_this <pointer_type 71272d80>>
    readonly addressable used public static tree_1 tree_5 tree_6 ignored weak in_system_header virtual decl_5 SI file /home/jh/trunk/c/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/fstream line 444 col 11 size <integer_cst 708002d0 320> unit size <integer_cst 708000d8 40>
    user align 32 context <record_type 701eb000 basic_ifstream> initial <constructor 70f63680>
   
    (mem/u/c:SI (symbol_ref/i:SI ("_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si") [flags 0x82] <var_decl 70f7d060 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>) [3 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+0 S40 A32])>
$6 = 10
(gdb) p debug_tree (decl)
 <var_decl 714174e0 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69
    type <array_type 70dd8840
        type <pointer_type 700f5840 __vtbl_ptr_type type <function_type 700f57e0>
            unsigned SI
            size <integer_cst 70006498 constant 32>
            unit size <integer_cst 700064b0 constant 4>
            align 32 symtab 45 alias set 3 canonical type 700f5840
            pointer_to_this <pointer_type 700f5900>>
        BLK
        size <integer_cst 708002d0 constant 320>
        unit size <integer_cst 708000d8 constant 40>
        align 32 symtab 0 alias set 3 canonical type 70dd8840
        domain <integer_type 701a78a0 type <integer_type 7001d000 sizetype>
            type_6 SI size <integer_cst 70006498 32> unit size <integer_cst 700064b0 4>
            align 32 symtab 0 alias set -1 canonical type 701a78a0 precision 32 min <integer_cst 700064c8 0> max <integer_cst 701a5b88 9>>
        pointer_to_this <pointer_type 71272d80>>
    readonly addressable used static tree_1 tree_5 tree_6 ignored in_system_header decl_5 SI file /home/jh/trunk/c/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/fstream line 444 col 11 size <integer_cst 708002d0 320> unit size <integer_cst 708000d8 40>
    user align 32 context <record_type 701eb000 basic_ifstream>
   >
$7 = 10

this seems correct - the alias definitely belongs to the section that its terget is placed into.
I am not however sure what the test is really checking.   It seems to insist on named sections
to consist only of one decl.

The error happens when we attempt to produce RTL for alias:
#0  _Z5errorPKcz (gmsgid=0x11775e44 <__gmpn_bases+42484> "%+D causes a section type conflict with %D") at ../../gcc/diagnostic.c:1048
#1  0x1088d0a0 in _Z11get_sectionPKcjP9tree_node (name=0x711de9d0 "_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si", flags=2097667, decl=0x714174e0) at ../../gcc/varasm.c:320
#2  0x1088d4d0 in _Z17get_named_sectionP9tree_nodePKci (decl=0x714174e0, name=0x711de9d0 "_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si", reloc=0) at ../../gcc/varasm.c:419
#3  0x1088f2e8 in _Z20get_variable_sectionP9tree_nodeb (decl=0x714174e0, prefer_noswitch_p=true) at ../../gcc/varasm.c:1112
#4  0x1088f594 in _ZL18get_block_for_declP9tree_node (decl=0x714174e0) at ../../gcc/varasm.c:1161
#5  0x1088ff60 in _Z13make_decl_rtlP9tree_node (decl=0x714174e0) at ../../gcc/varasm.c:1376

Perhaps get_vairable_section should look for alias target, since that is the
decl really deciding on the section? Richard?

Honza

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

* Re: ipa-visibility TLC 2/n
  2014-05-27 20:06         ` Jan Hubicka
@ 2014-05-27 22:20           ` Jan Hubicka
  2014-05-28 17:39             ` Yufeng Zhang
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-05-27 22:20 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: ramrad01, gcc-patches, rth

> 
> here we have decl and its local alias:
> (gdb) p debug_tree (sect->named.decl)
>  <var_decl 70f7d060 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
>     type <array_type 70dd8840
>         type <pointer_type 700f5840 __vtbl_ptr_type type <function_type 700f57e0>
>             unsigned SI
>             size <integer_cst 70006498 constant 32>
>             unit size <integer_cst 700064b0 constant 4>
>             align 32 symtab 45 alias set 3 canonical type 700f5840
>             pointer_to_this <pointer_type 700f5900>>
>         BLK
>         size <integer_cst 708002d0 constant 320>
>         unit size <integer_cst 708000d8 constant 40>
>         align 32 symtab 0 alias set 3 canonical type 70dd8840
>         domain <integer_type 701a78a0 type <integer_type 7001d000 sizetype>
>             type_6 SI size <integer_cst 70006498 32> unit size <integer_cst 700064b0 4>
>             align 32 symtab 0 alias set -1 canonical type 701a78a0 precision 32 min <integer_cst 700064c8 0> max <integer_cst 701a5b88 9>>
>         pointer_to_this <pointer_type 71272d80>>
>     readonly addressable used public static tree_1 tree_5 tree_6 ignored weak in_system_header virtual decl_5 SI file /home/jh/trunk/c/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/fstream line 444 col 11 size <integer_cst 708002d0 320> unit size <integer_cst 708000d8 40>
>     user align 32 context <record_type 701eb000 basic_ifstream> initial <constructor 70f63680>
>    
>     (mem/u/c:SI (symbol_ref/i:SI ("_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si") [flags 0x82] <var_decl 70f7d060 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>) [3 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+0 S40 A32])>
> $6 = 10
> (gdb) p debug_tree (decl)
>  <var_decl 714174e0 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69
>     type <array_type 70dd8840
>         type <pointer_type 700f5840 __vtbl_ptr_type type <function_type 700f57e0>
>             unsigned SI
>             size <integer_cst 70006498 constant 32>
>             unit size <integer_cst 700064b0 constant 4>
>             align 32 symtab 45 alias set 3 canonical type 700f5840
>             pointer_to_this <pointer_type 700f5900>>
>         BLK
>         size <integer_cst 708002d0 constant 320>
>         unit size <integer_cst 708000d8 constant 40>
>         align 32 symtab 0 alias set 3 canonical type 70dd8840
>         domain <integer_type 701a78a0 type <integer_type 7001d000 sizetype>
>             type_6 SI size <integer_cst 70006498 32> unit size <integer_cst 700064b0 4>
>             align 32 symtab 0 alias set -1 canonical type 701a78a0 precision 32 min <integer_cst 700064c8 0> max <integer_cst 701a5b88 9>>
>         pointer_to_this <pointer_type 71272d80>>
>     readonly addressable used static tree_1 tree_5 tree_6 ignored in_system_header decl_5 SI file /home/jh/trunk/c/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/fstream line 444 col 11 size <integer_cst 708002d0 320> unit size <integer_cst 708000d8 40>
>     user align 32 context <record_type 701eb000 basic_ifstream>
>    >
> $7 = 10
> 
> 
> Perhaps get_vairable_section should look for alias target, since that is the
> decl really deciding on the section? Richard?

This is patch that makes get_variable_section to look through the aliases

Index: varasm.c
===================================================================
--- varasm.c	(revision 210914)
+++ varasm.c	(working copy)
@@ -1083,6 +1083,9 @@
 {
   addr_space_t as = ADDR_SPACE_GENERIC;
   int reloc;
+  symtab_node *snode = symtab_get_node (decl);
+  if (snode)
+    decl = symtab_alias_ultimate_target (snode)->decl;
 
   if (TREE_TYPE (decl) != error_mark_node)
     as = TYPE_ADDR_SPACE (TREE_TYPE (decl));

For AIX it makes the bug go away and I eventually get:

/tmp//ccyAATFr.s: line 30042: 1252-001 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69 is defined already.
/tmp//ccyAATFr.s: line 30125: 1252-001 _ZTCSt14basic_ofstreamIcSt11char_traitsIcEE0_So.localalias.71 is defined already.
/tmp//ccyAATFr.s: line 30164: 1252-001 _ZTCSt13basic_fstreamIcSt11char_traitsIcEE8_So.localalias.75 is defined already.
/tmp//ccyAATFr.s: line 30223: 1252-001 _ZTCSt13basic_fstreamIcSt11char_traitsIcEE0_Si.localalias.74 is defined already.
/tmp//ccyAATFr.s: line 30263: 1252-001 _ZTCSt14basic_ofstreamIwSt11char_traitsIwEE0_St13basic_ostreamIwS1_E.localalias.80 is defined already.
/tmp//ccyAATFr.s: line 30323: 1252-001 _ZTCSt13basic_fstreamIwSt11char_traitsIwEE8_St13basic_ostreamIwS1_E.localalias.84 is defined already.
/tmp//ccyAATFr.s: line 30388: 1252-001 _ZTCSt14basic_ifstreamIwSt11char_traitsIwEE0_St13basic_istreamIwS1_E.localalias.78 is defined already.
/tmp//ccyAATFr.s: line 30436: 1252-001 _ZTCSt13basic_fstreamIwSt11char_traitsIwEE0_St13basic_istreamIwS1_E.localalias.83 is defined already.

David, this looks like a bug in the AIX target output macros. I get:
        .set _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69,_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si

(this is correct since localalias is really an alias)

_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69:
        .space 40
_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si:
...

This is wrong, since we should not try to out the variable at least if I read AIX assembly correctly.

varpool has explicit test to not output any aliases, so perhaps this is a bug in wrapup_globals
and AIX output macros.  I will try to track more after my teaching tonight.

Honza

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

* Re: ipa-visibility TLC 2/n
  2014-05-27 22:20           ` Jan Hubicka
@ 2014-05-28 17:39             ` Yufeng Zhang
  2014-05-28 19:52               ` Jan Hubicka
  2014-05-28 21:56               ` Jan Hubicka
  0 siblings, 2 replies; 44+ messages in thread
From: Yufeng Zhang @ 2014-05-28 17:39 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: Ramana Radhakrishnan, gcc-patches, rth

On 05/27/14 23:20, Jan Hubicka wrote:
>>
>> here we have decl and its local alias:
>> (gdb) p debug_tree (sect->named.decl)
>>   <var_decl 70f7d060 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
>>      type<array_type 70dd8840
>>          type<pointer_type 700f5840 __vtbl_ptr_type type<function_type 700f57e0>
>>              unsigned SI
>>              size<integer_cst 70006498 constant 32>
>>              unit size<integer_cst 700064b0 constant 4>
>>              align 32 symtab 45 alias set 3 canonical type 700f5840
>>              pointer_to_this<pointer_type 700f5900>>
>>          BLK
>>          size<integer_cst 708002d0 constant 320>
>>          unit size<integer_cst 708000d8 constant 40>
>>          align 32 symtab 0 alias set 3 canonical type 70dd8840
>>          domain<integer_type 701a78a0 type<integer_type 7001d000 sizetype>
>>              type_6 SI size<integer_cst 70006498 32>  unit size<integer_cst 700064b0 4>
>>              align 32 symtab 0 alias set -1 canonical type 701a78a0 precision 32 min<integer_cst 700064c8 0>  max<integer_cst 701a5b88 9>>
>>          pointer_to_this<pointer_type 71272d80>>
>>      readonly addressable used public static tree_1 tree_5 tree_6 ignored weak in_system_header virtual decl_5 SI file /home/jh/trunk/c/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/fstream line 444 col 11 size<integer_cst 708002d0 320>  unit size<integer_cst 708000d8 40>
>>      user align 32 context<record_type 701eb000 basic_ifstream>  initial<constructor 70f63680>
>>
>>      (mem/u/c:SI (symbol_ref/i:SI ("_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si") [flags 0x82]<var_decl 70f7d060 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>) [3 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+0 S40 A32])>
>> $6 = 10
>> (gdb) p debug_tree (decl)
>>   <var_decl 714174e0 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69
>>      type<array_type 70dd8840
>>          type<pointer_type 700f5840 __vtbl_ptr_type type<function_type 700f57e0>
>>              unsigned SI
>>              size<integer_cst 70006498 constant 32>
>>              unit size<integer_cst 700064b0 constant 4>
>>              align 32 symtab 45 alias set 3 canonical type 700f5840
>>              pointer_to_this<pointer_type 700f5900>>
>>          BLK
>>          size<integer_cst 708002d0 constant 320>
>>          unit size<integer_cst 708000d8 constant 40>
>>          align 32 symtab 0 alias set 3 canonical type 70dd8840
>>          domain<integer_type 701a78a0 type<integer_type 7001d000 sizetype>
>>              type_6 SI size<integer_cst 70006498 32>  unit size<integer_cst 700064b0 4>
>>              align 32 symtab 0 alias set -1 canonical type 701a78a0 precision 32 min<integer_cst 700064c8 0>  max<integer_cst 701a5b88 9>>
>>          pointer_to_this<pointer_type 71272d80>>
>>      readonly addressable used static tree_1 tree_5 tree_6 ignored in_system_header decl_5 SI file /home/jh/trunk/c/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/fstream line 444 col 11 size<integer_cst 708002d0 320>  unit size<integer_cst 708000d8 40>
>>      user align 32 context<record_type 701eb000 basic_ifstream>
>>     >
>> $7 = 10
>>
>>
>> Perhaps get_vairable_section should look for alias target, since that is the
>> decl really deciding on the section? Richard?
>
> This is patch that makes get_variable_section to look through the aliases
>
> Index: varasm.c
> ===================================================================
> --- varasm.c	(revision 210914)
> +++ varasm.c	(working copy)
> @@ -1083,6 +1083,9 @@
>   {
>     addr_space_t as = ADDR_SPACE_GENERIC;
>     int reloc;
> +  symtab_node *snode = symtab_get_node (decl);
> +  if (snode)
> +    decl = symtab_alias_ultimate_target (snode)->decl;
>
>     if (TREE_TYPE (decl) != error_mark_node)
>       as = TYPE_ADDR_SPACE (TREE_TYPE (decl));
>
> For AIX it makes the bug go away and I eventually get:
>
> /tmp//ccyAATFr.s: line 30042: 1252-001 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69 is defined already.
> /tmp//ccyAATFr.s: line 30125: 1252-001 _ZTCSt14basic_ofstreamIcSt11char_traitsIcEE0_So.localalias.71 is defined already.
> /tmp//ccyAATFr.s: line 30164: 1252-001 _ZTCSt13basic_fstreamIcSt11char_traitsIcEE8_So.localalias.75 is defined already.
> /tmp//ccyAATFr.s: line 30223: 1252-001 _ZTCSt13basic_fstreamIcSt11char_traitsIcEE0_Si.localalias.74 is defined already.
> /tmp//ccyAATFr.s: line 30263: 1252-001 _ZTCSt14basic_ofstreamIwSt11char_traitsIwEE0_St13basic_ostreamIwS1_E.localalias.80 is defined already.
> /tmp//ccyAATFr.s: line 30323: 1252-001 _ZTCSt13basic_fstreamIwSt11char_traitsIwEE8_St13basic_ostreamIwS1_E.localalias.84 is defined already.
> /tmp//ccyAATFr.s: line 30388: 1252-001 _ZTCSt14basic_ifstreamIwSt11char_traitsIwEE0_St13basic_istreamIwS1_E.localalias.78 is defined already.
> /tmp//ccyAATFr.s: line 30436: 1252-001 _ZTCSt13basic_fstreamIwSt11char_traitsIwEE0_St13basic_istreamIwS1_E.localalias.83 is defined already.
>
> David, this looks like a bug in the AIX target output macros. I get:
>          .set _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69,_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
>
> (this is correct since localalias is really an alias)
>
> _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69:
>          .space 40
> _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si:
> ...
>
> This is wrong, since we should not try to out the variable at least if I read AIX assembly correctly.
>
> varpool has explicit test to not output any aliases, so perhaps this is a bug in wrapup_globals
> and AIX output macros.  I will try to track more after my teaching tonight.

Any update?

I've managed to generate a simple test case from 
libstdc++-v3/src/c++98/strstream.cc which reproduces the issue on ARM 
that Ramana has reported previously:


template<class _CharT>  struct char_traits;

template<typename _CharT, typename _Traits>
class basic_ios
{
};

template<typename _CharT, typename _Traits = char_traits<_CharT> >
class basic_istream : virtual public basic_ios<_CharT, _Traits>
{
protected:
   int _M_gcount;
   virtual ~basic_istream()
     { }
};

class istrstream : public basic_istream<char>
{
   virtual ~istrstream();
};

istrstream::~istrstream()
{
}

------------------ CUT ------------------

With an arm-none-linux-gnueabi gcc configured as:

./gcc/configure --target=arm-none-linux-gnueabi 
--enable-gnu-indirect-function --enable-shared --with-arch=armv7-a 
--with-fpu=vfpv3-d16 --with-float=softfp --with-arch=armv7-a 
(irrelevant parts omitted)

With the following command line options:

  -fdata-sections    -O2  -fPIC  -S ./test.cpp

We'll see

./test.cpp:17:7: error: istrstream::_ZTV10istrstream.localalias.0 causes 
a section type conflict with istrstream::_ZTV10istrstream
  class istrstream : public basic_istream<char>
        ^
./test.cpp:17:7: note: 'istrstream::_ZTV10istrstream' was declared here


Yufeng

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

* Re: ipa-visibility TLC 2/n
  2014-05-28 17:39             ` Yufeng Zhang
@ 2014-05-28 19:52               ` Jan Hubicka
  2014-05-28 21:56               ` Jan Hubicka
  1 sibling, 0 replies; 44+ messages in thread
From: Jan Hubicka @ 2014-05-28 19:52 UTC (permalink / raw)
  To: Yufeng Zhang; +Cc: Jan Hubicka, Ramana Radhakrishnan, gcc-patches, rth

> On 05/27/14 23:20, Jan Hubicka wrote:
> >>
> >>here we have decl and its local alias:
> >>(gdb) p debug_tree (sect->named.decl)
> >>  <var_decl 70f7d060 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
> >>     type<array_type 70dd8840
> >>         type<pointer_type 700f5840 __vtbl_ptr_type type<function_type 700f57e0>
> >>             unsigned SI
> >>             size<integer_cst 70006498 constant 32>
> >>             unit size<integer_cst 700064b0 constant 4>
> >>             align 32 symtab 45 alias set 3 canonical type 700f5840
> >>             pointer_to_this<pointer_type 700f5900>>
> >>         BLK
> >>         size<integer_cst 708002d0 constant 320>
> >>         unit size<integer_cst 708000d8 constant 40>
> >>         align 32 symtab 0 alias set 3 canonical type 70dd8840
> >>         domain<integer_type 701a78a0 type<integer_type 7001d000 sizetype>
> >>             type_6 SI size<integer_cst 70006498 32>  unit size<integer_cst 700064b0 4>
> >>             align 32 symtab 0 alias set -1 canonical type 701a78a0 precision 32 min<integer_cst 700064c8 0>  max<integer_cst 701a5b88 9>>
> >>         pointer_to_this<pointer_type 71272d80>>
> >>     readonly addressable used public static tree_1 tree_5 tree_6 ignored weak in_system_header virtual decl_5 SI file /home/jh/trunk/c/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/fstream line 444 col 11 size<integer_cst 708002d0 320>  unit size<integer_cst 708000d8 40>
> >>     user align 32 context<record_type 701eb000 basic_ifstream>  initial<constructor 70f63680>
> >>
> >>     (mem/u/c:SI (symbol_ref/i:SI ("_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si") [flags 0x82]<var_decl 70f7d060 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>) [3 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+0 S40 A32])>
> >>$6 = 10
> >>(gdb) p debug_tree (decl)
> >>  <var_decl 714174e0 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69
> >>     type<array_type 70dd8840
> >>         type<pointer_type 700f5840 __vtbl_ptr_type type<function_type 700f57e0>
> >>             unsigned SI
> >>             size<integer_cst 70006498 constant 32>
> >>             unit size<integer_cst 700064b0 constant 4>
> >>             align 32 symtab 45 alias set 3 canonical type 700f5840
> >>             pointer_to_this<pointer_type 700f5900>>
> >>         BLK
> >>         size<integer_cst 708002d0 constant 320>
> >>         unit size<integer_cst 708000d8 constant 40>
> >>         align 32 symtab 0 alias set 3 canonical type 70dd8840
> >>         domain<integer_type 701a78a0 type<integer_type 7001d000 sizetype>
> >>             type_6 SI size<integer_cst 70006498 32>  unit size<integer_cst 700064b0 4>
> >>             align 32 symtab 0 alias set -1 canonical type 701a78a0 precision 32 min<integer_cst 700064c8 0>  max<integer_cst 701a5b88 9>>
> >>         pointer_to_this<pointer_type 71272d80>>
> >>     readonly addressable used static tree_1 tree_5 tree_6 ignored in_system_header decl_5 SI file /home/jh/trunk/c/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/fstream line 444 col 11 size<integer_cst 708002d0 320>  unit size<integer_cst 708000d8 40>
> >>     user align 32 context<record_type 701eb000 basic_ifstream>
> >>    >
> >>$7 = 10
> >>
> >>
> >>Perhaps get_vairable_section should look for alias target, since that is the
> >>decl really deciding on the section? Richard?
> >
> >This is patch that makes get_variable_section to look through the aliases
> >
> >Index: varasm.c
> >===================================================================
> >--- varasm.c	(revision 210914)
> >+++ varasm.c	(working copy)
> >@@ -1083,6 +1083,9 @@
> >  {
> >    addr_space_t as = ADDR_SPACE_GENERIC;
> >    int reloc;
> >+  symtab_node *snode = symtab_get_node (decl);
> >+  if (snode)
> >+    decl = symtab_alias_ultimate_target (snode)->decl;
> >
> >    if (TREE_TYPE (decl) != error_mark_node)
> >      as = TYPE_ADDR_SPACE (TREE_TYPE (decl));
> >
> >For AIX it makes the bug go away and I eventually get:
> >
> >/tmp//ccyAATFr.s: line 30042: 1252-001 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69 is defined already.
> >/tmp//ccyAATFr.s: line 30125: 1252-001 _ZTCSt14basic_ofstreamIcSt11char_traitsIcEE0_So.localalias.71 is defined already.
> >/tmp//ccyAATFr.s: line 30164: 1252-001 _ZTCSt13basic_fstreamIcSt11char_traitsIcEE8_So.localalias.75 is defined already.
> >/tmp//ccyAATFr.s: line 30223: 1252-001 _ZTCSt13basic_fstreamIcSt11char_traitsIcEE0_Si.localalias.74 is defined already.
> >/tmp//ccyAATFr.s: line 30263: 1252-001 _ZTCSt14basic_ofstreamIwSt11char_traitsIwEE0_St13basic_ostreamIwS1_E.localalias.80 is defined already.
> >/tmp//ccyAATFr.s: line 30323: 1252-001 _ZTCSt13basic_fstreamIwSt11char_traitsIwEE8_St13basic_ostreamIwS1_E.localalias.84 is defined already.
> >/tmp//ccyAATFr.s: line 30388: 1252-001 _ZTCSt14basic_ifstreamIwSt11char_traitsIwEE0_St13basic_istreamIwS1_E.localalias.78 is defined already.
> >/tmp//ccyAATFr.s: line 30436: 1252-001 _ZTCSt13basic_fstreamIwSt11char_traitsIwEE0_St13basic_istreamIwS1_E.localalias.83 is defined already.
> >
> >David, this looks like a bug in the AIX target output macros. I get:
> >         .set _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69,_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
> >
> >(this is correct since localalias is really an alias)
> >
> >_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69:
> >         .space 40
> >_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si:
> >...
> >
> >This is wrong, since we should not try to out the variable at least if I read AIX assembly correctly.
> >
> >varpool has explicit test to not output any aliases, so perhaps this is a bug in wrapup_globals
> >and AIX output macros.  I will try to track more after my teaching tonight.
> 
> Any update?
> 
> I've managed to generate a simple test case from
> libstdc++-v3/src/c++98/strstream.cc which reproduces the issue on
> ARM that Ramana has reported previously:

Thanks, that is very useful!  I will look into it today - I am teaching at evening, so first I need
to prepare my class and will do it next.

Honza

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

* Re: ipa-visibility TLC 2/n
  2014-05-28 17:39             ` Yufeng Zhang
  2014-05-28 19:52               ` Jan Hubicka
@ 2014-05-28 21:56               ` Jan Hubicka
  2014-05-29 14:17                 ` Yufeng Zhang
  1 sibling, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-05-28 21:56 UTC (permalink / raw)
  To: Yufeng Zhang; +Cc: Jan Hubicka, Ramana Radhakrishnan, gcc-patches, rth

> Any update?
> 
> I've managed to generate a simple test case from
> libstdc++-v3/src/c++98/strstream.cc which reproduces the issue on
> ARM that Ramana has reported previously:
> 
> 
> template<class _CharT>  struct char_traits;
> 
> template<typename _CharT, typename _Traits>
> class basic_ios
> {
> };
> 
> template<typename _CharT, typename _Traits = char_traits<_CharT> >
> class basic_istream : virtual public basic_ios<_CharT, _Traits>
> {
> protected:
>   int _M_gcount;
>   virtual ~basic_istream()
>     { }
> };
> 
> class istrstream : public basic_istream<char>
> {
>   virtual ~istrstream();
> };
> 
> istrstream::~istrstream()
> {
> }
> 
> ------------------ CUT ------------------
> 
> With an arm-none-linux-gnueabi gcc configured as:
> 
> ./gcc/configure --target=arm-none-linux-gnueabi
> --enable-gnu-indirect-function --enable-shared --with-arch=armv7-a
> --with-fpu=vfpv3-d16 --with-float=softfp --with-arch=armv7-a
> (irrelevant parts omitted)
> 
> With the following command line options:
> 
>  -fdata-sections    -O2  -fPIC  -S ./test.cpp
> 
> We'll see
> 
> ./test.cpp:17:7: error: istrstream::_ZTV10istrstream.localalias.0
> causes a section type conflict with istrstream::_ZTV10istrstream
>  class istrstream : public basic_istream<char>
>        ^
> ./test.cpp:17:7: note: 'istrstream::_ZTV10istrstream' was declared here

This seems to be same cause as on AIX - we do section for decl rather than
original.  The following patch seems to fix it.  Does it allows bootstrap
for you? (it doesn't for AIX. but that seems bug in output machinery)

Index: varasm.c
===================================================================
--- varasm.c	(revision 210914)
+++ varasm.c	(working copy)
@@ -1083,6 +1083,9 @@
 {
   addr_space_t as = ADDR_SPACE_GENERIC;
   int reloc;
+  symtab_node *snode = symtab_get_node (decl);
+  if (snode)
+    decl = symtab_alias_ultimate_target (snode)->decl;
 
   if (TREE_TYPE (decl) != error_mark_node)
     as = TYPE_ADDR_SPACE (TREE_TYPE (decl));
> 
> 
> Yufeng

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

* Re: ipa-visibility TLC 2/n
  2014-05-28 21:56               ` Jan Hubicka
@ 2014-05-29 14:17                 ` Yufeng Zhang
  2014-05-30 16:18                   ` Ramana Radhakrishnan
  0 siblings, 1 reply; 44+ messages in thread
From: Yufeng Zhang @ 2014-05-29 14:17 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: Ramana Radhakrishnan, gcc-patches, rth

Hi Honza,

I can confirm that with your commit r211045 the 
arm-none-linux-gnueabi{hf} builds are OK now.  Thanks for the fix.

Yufeng

On 05/28/14 22:56, Jan Hubicka wrote:
>> Any update?
>>
>> I've managed to generate a simple test case from
>> libstdc++-v3/src/c++98/strstream.cc which reproduces the issue on
>> ARM that Ramana has reported previously:
>>
>>
>> template<class _CharT>   struct char_traits;
>>
>> template<typename _CharT, typename _Traits>
>> class basic_ios
>> {
>> };
>>
>> template<typename _CharT, typename _Traits = char_traits<_CharT>  >
>> class basic_istream : virtual public basic_ios<_CharT, _Traits>
>> {
>> protected:
>>    int _M_gcount;
>>    virtual ~basic_istream()
>>      { }
>> };
>>
>> class istrstream : public basic_istream<char>
>> {
>>    virtual ~istrstream();
>> };
>>
>> istrstream::~istrstream()
>> {
>> }
>>
>> ------------------ CUT ------------------
>>
>> With an arm-none-linux-gnueabi gcc configured as:
>>
>> ./gcc/configure --target=arm-none-linux-gnueabi
>> --enable-gnu-indirect-function --enable-shared --with-arch=armv7-a
>> --with-fpu=vfpv3-d16 --with-float=softfp --with-arch=armv7-a
>> (irrelevant parts omitted)
>>
>> With the following command line options:
>>
>>   -fdata-sections    -O2  -fPIC  -S ./test.cpp
>>
>> We'll see
>>
>> ./test.cpp:17:7: error: istrstream::_ZTV10istrstream.localalias.0
>> causes a section type conflict with istrstream::_ZTV10istrstream
>>   class istrstream : public basic_istream<char>
>>         ^
>> ./test.cpp:17:7: note: 'istrstream::_ZTV10istrstream' was declared here
>
> This seems to be same cause as on AIX - we do section for decl rather than
> original.  The following patch seems to fix it.  Does it allows bootstrap
> for you? (it doesn't for AIX. but that seems bug in output machinery)
>
> Index: varasm.c
> ===================================================================
> --- varasm.c	(revision 210914)
> +++ varasm.c	(working copy)
> @@ -1083,6 +1083,9 @@
>   {
>     addr_space_t as = ADDR_SPACE_GENERIC;
>     int reloc;
> +  symtab_node *snode = symtab_get_node (decl);
> +  if (snode)
> +    decl = symtab_alias_ultimate_target (snode)->decl;
>
>     if (TREE_TYPE (decl) != error_mark_node)
>       as = TYPE_ADDR_SPACE (TREE_TYPE (decl));
>>
>>
>> Yufeng
>


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

* Re: ipa-visibility TLC 2/n
  2014-05-29 14:17                 ` Yufeng Zhang
@ 2014-05-30 16:18                   ` Ramana Radhakrishnan
  0 siblings, 0 replies; 44+ messages in thread
From: Ramana Radhakrishnan @ 2014-05-30 16:18 UTC (permalink / raw)
  To: Yufeng Zhang; +Cc: Jan Hubicka, Ramana Radhakrishnan, gcc-patches, rth

On Thu, May 29, 2014 at 3:17 PM, Yufeng Zhang <Yufeng.Zhang@arm.com> wrote:
> Hi Honza,
>
> I can confirm that with your commit r211045 the arm-none-linux-gnueabi{hf}
> builds are OK now.  Thanks for the fix.

Testsuite regressions like


FAIL: g++.dg/ipa/devirt-21.C -std=gnu++1y (test for excess errors)
Excess errors:
src/gcc/gcc/testsuite/g++.dg/ipa/devirt-21.C:39:1: internal compiler
error: in gimple_get_virt_method_for_vtable, at gimple-fold.c:3273
0x9ed491 record_target_from_binfo
src/gcc/gcc/ipa-devirt.c:868
0x9ed574 record_target_from_binfo
gcc/gcc/ipa-devirt.c:885
0x9edb09 possible_polymorphic_call_targets_1
gcc/gcc/ipa-devirt.c:932
0x9eff59 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, int*)
gcc/gcc/ipa-devirt.c:1744
0xa19724 possible_polymorphic_call_targets
src/gcc/gcc/ipa-utils.h:121
0xa19724 walk_polymorphic_call_targets
src/gcc/gcc/ipa.c:151
0xa19724 symtab_remove_unreachable_nodes(bool, _IO_FILE*)
src/gcc/gcc/ipa.c:384
0xadc4d3 execute_todo
src/gcc/gcc/passes.c:1843

Number of unexpected g++ failures now up to 127 on arm-linux-gnueabi(hf).

regards
Ramana


>
> Yufeng
>
>
> On 05/28/14 22:56, Jan Hubicka wrote:
>>>
>>> Any update?
>>>
>>> I've managed to generate a simple test case from
>>> libstdc++-v3/src/c++98/strstream.cc which reproduces the issue on
>>> ARM that Ramana has reported previously:
>>>
>>>
>>> template<class _CharT>   struct char_traits;
>>>
>>> template<typename _CharT, typename _Traits>
>>> class basic_ios
>>> {
>>> };
>>>
>>> template<typename _CharT, typename _Traits = char_traits<_CharT>  >
>>> class basic_istream : virtual public basic_ios<_CharT, _Traits>
>>> {
>>> protected:
>>>    int _M_gcount;
>>>    virtual ~basic_istream()
>>>      { }
>>> };
>>>
>>> class istrstream : public basic_istream<char>
>>> {
>>>    virtual ~istrstream();
>>> };
>>>
>>> istrstream::~istrstream()
>>> {
>>> }
>>>
>>> ------------------ CUT ------------------
>>>
>>> With an arm-none-linux-gnueabi gcc configured as:
>>>
>>> ./gcc/configure --target=arm-none-linux-gnueabi
>>> --enable-gnu-indirect-function --enable-shared --with-arch=armv7-a
>>> --with-fpu=vfpv3-d16 --with-float=softfp --with-arch=armv7-a
>>> (irrelevant parts omitted)
>>>
>>> With the following command line options:
>>>
>>>   -fdata-sections    -O2  -fPIC  -S ./test.cpp
>>>
>>> We'll see
>>>
>>> ./test.cpp:17:7: error: istrstream::_ZTV10istrstream.localalias.0
>>> causes a section type conflict with istrstream::_ZTV10istrstream
>>>   class istrstream : public basic_istream<char>
>>>         ^
>>> ./test.cpp:17:7: note: 'istrstream::_ZTV10istrstream' was declared here
>>
>>
>> This seems to be same cause as on AIX - we do section for decl rather than
>> original.  The following patch seems to fix it.  Does it allows bootstrap
>> for you? (it doesn't for AIX. but that seems bug in output machinery)
>>
>> Index: varasm.c
>> ===================================================================
>> --- varasm.c    (revision 210914)
>> +++ varasm.c    (working copy)
>> @@ -1083,6 +1083,9 @@
>>   {
>>     addr_space_t as = ADDR_SPACE_GENERIC;
>>     int reloc;
>> +  symtab_node *snode = symtab_get_node (decl);
>> +  if (snode)
>> +    decl = symtab_alias_ultimate_target (snode)->decl;
>>
>>     if (TREE_TYPE (decl) != error_mark_node)
>>       as = TYPE_ADDR_SPACE (TREE_TYPE (decl));
>>>
>>>
>>>
>>> Yufeng
>>
>>
>
>

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

* Re: ipa-visibility TLC 2/n
  2014-06-12 10:43                               ` Rainer Orth
  2014-06-12 13:33                                 ` Rainer Orth
@ 2014-06-13  3:22                                 ` Jan Hubicka
  1 sibling, 0 replies; 44+ messages in thread
From: Jan Hubicka @ 2014-06-13  3:22 UTC (permalink / raw)
  To: Rainer Orth
  Cc: Jan Hubicka, David Edelsohn, Richard Biener, GCC Patches,
	Richard Henderson, ramrad01, Richard Sandiford

> >
> > Comdat locals are now used by ipa-comdats, for thunks and for decloned ctors.
> > We probably need to figure out bit more precise limitation of Solaris and either
> > fix or add way for target to say what kind of comdat locals are not supported.
> 
> Right.  I'll start reghunting for the patch that caused additional
> breakage even without comdat, as on Solaris 10.

Good, at least one bug is off my radar.
I was thinking about the ipa-comdats issue and I remembered older problem where I wanted
to place thunks before function (to avoid need to jump back to the body) and that caused
problems for you, too, since solaris assembler apparently refused other than main comdat
group symbol being defined first.

Perhaps we run into similar issues? Do you know what precisely are the restrictions here?
(we do, for example, comdat groups that do not contain a symbol the group is called by,
so I do not see how the main symbol name is significant)

IPA-comdat brings extra symbols into the comdat group and pays no attention on the order,
so perhaps this is causing the issue.  We may add some logic into assemble_functions
to fix the order or work out why this breaks.
> 
> > Can I reproduce your setup on the compile farm?
> 
> According to https://gcc.gnu.org/wiki/CompileFarm, there are no Solaris
> machines or VMs in the compile farm.  If a VM could be set up (no idea
> if they allow non-free OSes beyond AIX there), I'd suggest starting with
> Solaris 11.2 Beta
> (http://www.oracle.com/technetwork/server-storage/solaris11/downloads/beta-2182939.html),
> which has the latest in /bin/ld support.  I can certainly help with
> setting something up.

Would be nice to have non-free OS for testing.  Comdats and aliases seems to be riddled by
implementation bugs and it would be nice to have way to test for those.

Honza
> 
> 	Rainer
> 
> -- 
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University

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

* Re: ipa-visibility TLC 2/n
  2014-06-12 10:43                               ` Rainer Orth
@ 2014-06-12 13:33                                 ` Rainer Orth
  2014-06-13  3:22                                 ` Jan Hubicka
  1 sibling, 0 replies; 44+ messages in thread
From: Rainer Orth @ 2014-06-12 13:33 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: Ian Lance Taylor, GCC Patches

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> Hi Honza,
>
>>> Unfortunately, AIX isn't the only target massively affected by your
>>> recent patches.  This all started with r210597
>>> 
>>> 2014-05-17  Jan Hubicka  <hubicka@ucw.cz>
>>> 
>>> 	* tree-pass.h (make_pass_ipa_comdats): New pass.
>>>         * timevar.def (TV_IPA_COMDATS): New timevar.
>>>         * passes.def (pass_ipa_comdats): Add.
>>>         * Makefile.in (OBJS): Add ipa-comdats.o
>>>         * ipa-comdats.c: New file.
>>> 
>>> At that time, only Solaris 11 with gas/Solaris ld was affected: many Go
>>> tests started failing like this:
>>> 
>>> runtime.SetFinalizer: cannot pass *     os      os.file to finalizer func(*     os      os.file) error
>>> fatal error: runtime.SetFinalizer
>>
>> Thanks for letting me know.  THis is different transformation than one
>> causing trouble
>> on AIX (AIX has no comdats, so this pass does nothing).  Go seems tobe
>> quite heavy user
>> of comdat locals produced by that patch, so I suppose they somehow break
>> with Solaris.
>>
>> Comdat locals are now used by ipa-comdats, for thunks and for decloned ctors.
>> We probably need to figure out bit more precise limitation of Solaris and
>> either
>> fix or add way for target to say what kind of comdat locals are not supported.
>
> Right.  I'll start reghunting for the patch that caused additional
> breakage even without comdat, as on Solaris 10.

It turned out that those failures have been caused by the last libgo
merge, rev 211328: many 64-bit tests FAIL like this:

FAIL: go.go-torture/execute/chan-1.go execution,  -O0

fatal error: all goroutines are asleep - deadlock!

goroutine 16 [chan send]:
created by main
        /vol/gcc/src/hg/trunk/local/libgo/runtime/go-main.c:42

There have been massive changes to libgo/runtime/chan.c, perhaps one of
them is the culprit.

It's hard to keep track with so much breakage these days ;-(

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

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

* Re: ipa-visibility TLC 2/n
  2014-06-11 17:02                             ` Jan Hubicka
@ 2014-06-12 10:43                               ` Rainer Orth
  2014-06-12 13:33                                 ` Rainer Orth
  2014-06-13  3:22                                 ` Jan Hubicka
  0 siblings, 2 replies; 44+ messages in thread
From: Rainer Orth @ 2014-06-12 10:43 UTC (permalink / raw)
  To: Jan Hubicka
  Cc: David Edelsohn, Richard Biener, GCC Patches, Richard Henderson,
	ramrad01, Richard Sandiford

Hi Honza,

>> Unfortunately, AIX isn't the only target massively affected by your
>> recent patches.  This all started with r210597
>> 
>> 2014-05-17  Jan Hubicka  <hubicka@ucw.cz>
>> 
>> 	* tree-pass.h (make_pass_ipa_comdats): New pass.
>>         * timevar.def (TV_IPA_COMDATS): New timevar.
>>         * passes.def (pass_ipa_comdats): Add.
>>         * Makefile.in (OBJS): Add ipa-comdats.o
>>         * ipa-comdats.c: New file.
>> 
>> At that time, only Solaris 11 with gas/Solaris ld was affected: many Go
>> tests started failing like this:
>> 
>> runtime.SetFinalizer: cannot pass *     os      os.file to finalizer func(*     os      os.file) error
>> fatal error: runtime.SetFinalizer
>
> Thanks for letting me know.  THis is different transformation than one
> causing trouble
> on AIX (AIX has no comdats, so this pass does nothing).  Go seems tobe
> quite heavy user
> of comdat locals produced by that patch, so I suppose they somehow break
> with Solaris.
>
> Comdat locals are now used by ipa-comdats, for thunks and for decloned ctors.
> We probably need to figure out bit more precise limitation of Solaris and either
> fix or add way for target to say what kind of comdat locals are not supported.

Right.  I'll start reghunting for the patch that caused additional
breakage even without comdat, as on Solaris 10.

> Can I reproduce your setup on the compile farm?

According to https://gcc.gnu.org/wiki/CompileFarm, there are no Solaris
machines or VMs in the compile farm.  If a VM could be set up (no idea
if they allow non-free OSes beyond AIX there), I'd suggest starting with
Solaris 11.2 Beta
(http://www.oracle.com/technetwork/server-storage/solaris11/downloads/beta-2182939.html),
which has the latest in /bin/ld support.  I can certainly help with
setting something up.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

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

* Re: ipa-visibility TLC 2/n
  2014-06-11 14:26                           ` Rainer Orth
@ 2014-06-11 17:02                             ` Jan Hubicka
  2014-06-12 10:43                               ` Rainer Orth
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-06-11 17:02 UTC (permalink / raw)
  To: Rainer Orth
  Cc: Jan Hubicka, David Edelsohn, Richard Biener, GCC Patches,
	Richard Henderson, ramrad01, Richard Sandiford

> 
> Unfortunately, AIX isn't the only target massively affected by your
> recent patches.  This all started with r210597
> 
> 2014-05-17  Jan Hubicka  <hubicka@ucw.cz>
> 
> 	* tree-pass.h (make_pass_ipa_comdats): New pass.
>         * timevar.def (TV_IPA_COMDATS): New timevar.
>         * passes.def (pass_ipa_comdats): Add.
>         * Makefile.in (OBJS): Add ipa-comdats.o
>         * ipa-comdats.c: New file.
> 
> At that time, only Solaris 11 with gas/Solaris ld was affected: many Go
> tests started failing like this:
> 
> runtime.SetFinalizer: cannot pass *     os      os.file to finalizer func(*     os      os.file) error
> fatal error: runtime.SetFinalizer

Thanks for letting me know.  THis is different transformation than one causing trouble
on AIX (AIX has no comdats, so this pass does nothing).  Go seems tobe quite heavy user
of comdat locals produced by that patch, so I suppose they somehow break with Solaris.

Comdat locals are now used by ipa-comdats, for thunks and for decloned ctors.
We probably need to figure out bit more precise limitation of Solaris and either
fix or add way for target to say what kind of comdat locals are not supported.

Can I reproduce your setup on the compile farm?

Honza
> 
> Neither Solaris 10 (which doesn't enable comdat group due to missing ld
> support for what gas emits) nor Solaris 11 with /bin/as (which has
> different comdat syntax, thus emitting groups differently) were
> affected.
> 
> I didn't file a PR at that time since I had started to work with the
> Solaris linker engineers to see what could be done about this on the ld
> side.  Unfortunately, even if this worked, it won't change the installed
> base.
> 
> Since then, the number of Go testsuite failures seems to increase daily,
> now Solaris 10 is also affected.  Given that sparc-sun-solaris2.10 is a
> primary platform, we need to do something about this.
> 
> 	Rainer
> 
> -- 
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University

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

* Re: ipa-visibility TLC 2/n
  2014-06-10 22:55                         ` Jan Hubicka
@ 2014-06-11 14:26                           ` Rainer Orth
  2014-06-11 17:02                             ` Jan Hubicka
  0 siblings, 1 reply; 44+ messages in thread
From: Rainer Orth @ 2014-06-11 14:26 UTC (permalink / raw)
  To: Jan Hubicka
  Cc: David Edelsohn, Richard Biener, GCC Patches, Richard Henderson,
	ramrad01, Richard Sandiford

Jan Hubicka <hubicka@ucw.cz> writes:

>> Honza,
>> 
>> I am not sure that the problem is caused only by aliases and thunks.
>> The large increase in AIX linker warnings about branches not followed
>> by nop also worry me.
>> 
>> Your patch was about visibility. How does the more aggressive
>
> ipa-visibility is a pass that basically bring external symbols local whenever
> it can (i.e. does privatizatoin), it is not that much about ELF visibilities.
>
>> algorithm behave on a platform that does not support visibility? Is it
>> defaulting to hidden? If the new algorithm is being too aggressive and
>> incorrectly converting calls from global to local, it could cause
>> serious problems for AIX because the GOT register will not be
>> restored.
>
> One of optimizations IPA visibility does is that it looks for global symbols
> that
>   1) are believed by target to be overwritable (interposed - I will probably
>      update name here) by linker to a different definition (we have
>      decl_binds_to_current_def_p that is target tweakable), and
>   2) the interposition may not change semantics of the symbol (i.e. function
>      body must be the same or variable initializer must match)
>
>      For some symbols (such as inline functions, virtual tables, readonly
>      variables with no address taken) we know it won't.
>   3) the symbol's definition can not be optimized away by linker
>      (by symtab_can_be_discarded)
> If all conditons match, it creates a static alias (not hidden, just local to
> the .o file) and redirects users of the symbol to the alias.  This should be
> always win: we know that the representation of symbol will survive to final
> binary (it is not discarded) and we replace expensive references through GOT by
> cheap references to local symbol.
>
> We did, for longer time, redirect calls.  The troublesome patch makes us to
> redirect also references in virtual tables and newly we also consider virtual
> tables themselves for aliases.
>
> This should be a win, since virtual tables tends to be startup time hogs and
> it is common to have virtual tables in one DSO to refer to comdats that are
> shared with other DSO, but because they must be the same, we can just ignore
> the sharing.
>
> On AIX we observed interesting series of events.
>
>  1) First the output machinery was not quite able to declare local static
>     alias for a symbol (this was about year ago when I introduced the first
>     change).
>  2) AIX assembler seems to issue warning when jump happens to the local
>     static alias confusing it with the global symbol it is aliasing.
>     I do not know if the warning is just bogus or we output something
>     incorrectly.  This is the reason for NOP warning as I understand.
>  3) Important difference we is that in AIX all COMDAT symbols are considered
>     non-discardable. This makes us to produce a lot more aliases than on ELF
>     system.
>
>     I am not sure if this is acurate and AIX linker really has no means
>     of removing duplicated bodies of COMDAT functions/initializers of variables.
>     If it has, we need to model it in symtab_can_be_discarded.
>     Currently we test whether symbol is in comdat group and in the case of
>     AIX it isn't. 
>
>     As disucssed earlier, I am thinking about making symtab_can_be_discarded
>     return true also for implicit sections (I have WIP patch for this to
>     commit today). Earlier version of the patch however did not solve
>     the warnings.
>
>     I also tested libstdc++.so sizes with current mainline, with the
>     local aliases disabled and with this change and current mainline
>     wins. Suggesting that perhaps there is really no way to discard
>     duplicated comdats or libstdc++ doesn't really have them.
>     Insight here would be welcome - I am sure it is easy to test if 
>     including and using inline __noinline__ function in two units
>     leads to two copies of that beast or not. It would be nice to know
>     how native toolchain handles it and if GCC does the same trick.
>  4) Before 4.9 we hit bug in inliner dealing with aliases that gave me
>     a headache. It reproduced on AIX only because of 3)
>  5) We hit problem with aliases to anchored sections, hopefully solved now
>  6) We hit the problem that AIX assembler silently accepts but miscompile
>     when alias is declared before its target.  THis is also hopefully
>     fixed now.  We hit it twice - one for normal symbols about year ago
>     and now again for thunks.
>  7) Given number of issues I ended up writting a verifier that checks
>     sanity of sections, aliases and comdat groups.  I check
>       a) all symbols in comdat group have the same section
>       b) alias and its target have same comdat group & section characteristics
>          (obivously one can not place alias out of comdat)
>       c) I check sanity of IMPLICIT_SECTION flag.
>     It turns out that C++ FE makes complete mess of those breaking all three
>     rules due to complex interactions in between comdat code, same body aliases
>     and the way thunks are produced.  I think this may confuse AIX output
>     macros since they are just given a contradictionary information.
>     So it may turn out that the AIX assembler warnings are correct.
>
>     Have patch in testing and it seems that warnings are gone, but I am not
>     at the end of bootstrap, yet, now resolving issues with libfortran.
>
>     I plan to add check that we do not have two comdat groups of the same
>     name, but I am not there, yet.  As usual, verifier improvements show
>     issues that are a lot of fun to resolve.
>
> Still, i would not think of the original optimization as aggressive and risky one.
> We just found that the way we deal with aliases is terribly broken at some targets.
> Pretty much all the bugs above are reproducable by a testcases using alias attribute.
> Yes, i understand it is frustrating (to me too) and that I should be faster dealing
> with the issue (teaching in Canada is time consuming). 
>
> I am now again testing similar changes on AIX before comitting.  I considered
> the original TLC patch as simple change given that we already debugged the
> local aliases for 4.9.  I am sorry for that.  I will try to be sure that I get libstdc++
> testsuite into a shape either by comitting the patch for 7) or reverting the relevant
> part of the TLC patch.

Unfortunately, AIX isn't the only target massively affected by your
recent patches.  This all started with r210597

2014-05-17  Jan Hubicka  <hubicka@ucw.cz>

	* tree-pass.h (make_pass_ipa_comdats): New pass.
        * timevar.def (TV_IPA_COMDATS): New timevar.
        * passes.def (pass_ipa_comdats): Add.
        * Makefile.in (OBJS): Add ipa-comdats.o
        * ipa-comdats.c: New file.

At that time, only Solaris 11 with gas/Solaris ld was affected: many Go
tests started failing like this:

runtime.SetFinalizer: cannot pass *     os      os.file to finalizer func(*     os      os.file) error
fatal error: runtime.SetFinalizer

Neither Solaris 10 (which doesn't enable comdat group due to missing ld
support for what gas emits) nor Solaris 11 with /bin/as (which has
different comdat syntax, thus emitting groups differently) were
affected.

I didn't file a PR at that time since I had started to work with the
Solaris linker engineers to see what could be done about this on the ld
side.  Unfortunately, even if this worked, it won't change the installed
base.

Since then, the number of Go testsuite failures seems to increase daily,
now Solaris 10 is also affected.  Given that sparc-sun-solaris2.10 is a
primary platform, we need to do something about this.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

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

* Re: ipa-visibility TLC 2/n
  2014-06-10 22:23                       ` David Edelsohn
  2014-06-10 22:55                         ` Jan Hubicka
@ 2014-06-11  8:17                         ` Jan Hubicka
  1 sibling, 0 replies; 44+ messages in thread
From: Jan Hubicka @ 2014-06-11  8:17 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Jan Hubicka, Richard Biener, GCC Patches, Richard Henderson,
	ramrad01, Richard Sandiford

Deavid,
this is patch to disable the vtable rewriting on AIX.  I did not make much progress
on figuring out why it fails today - just observed that if I produce .o file for the
test and link it against libstdc++ built by older GCC it works. Also objects compiled
w/o optimization works, so I am bit puzzled here.

Honza

Index: ChangeLog
===================================================================
--- ChangeLog	(revision 211436)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2014-06-11  Jan Hubicka  <hubicka@ucw.cz>
+
+	* ipa-visibility.c (function_and_variable_visibility): Disable
+	virtual table rewriting temporarily on targets not supporting
+	ONE_ONLY.
+
 2014-06-11  Richard Biener  <rguenther@suse.de>
 
 	PR middle-end/61437
Index: ipa-visibility.c
===================================================================
--- ipa-visibility.c	(revision 211436)
+++ ipa-visibility.c	(working copy)
@@ -666,9 +666,12 @@ function_and_variable_visibility (bool w
 	}
       update_visibility_by_resolution_info (vnode);
 
-      /* Update virutal tables to point to local aliases where possible.  */
+      /* Update virtual tables to point to local aliases where possible.  */
       if (DECL_VIRTUAL_P (vnode->decl)
-	  && !DECL_EXTERNAL (vnode->decl))
+	  && !DECL_EXTERNAL (vnode->decl)
+	  /* FIXME: currently this optimization breaks on AIX.  Disable it for targets
+	     without comdat support for now.  */
+	  && SUPPORTS_ONE_ONLY)
 	{
 	  int i;
 	  struct ipa_ref *ref;

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

* Re: ipa-visibility TLC 2/n
  2014-06-10 22:23                       ` David Edelsohn
@ 2014-06-10 22:55                         ` Jan Hubicka
  2014-06-11 14:26                           ` Rainer Orth
  2014-06-11  8:17                         ` Jan Hubicka
  1 sibling, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-06-10 22:55 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Jan Hubicka, Richard Biener, GCC Patches, Richard Henderson,
	ramrad01, Richard Sandiford

> Honza,
> 
> I am not sure that the problem is caused only by aliases and thunks.
> The large increase in AIX linker warnings about branches not followed
> by nop also worry me.
> 
> Your patch was about visibility. How does the more aggressive

ipa-visibility is a pass that basically bring external symbols local whenever
it can (i.e. does privatizatoin), it is not that much about ELF visibilities.

> algorithm behave on a platform that does not support visibility? Is it
> defaulting to hidden? If the new algorithm is being too aggressive and
> incorrectly converting calls from global to local, it could cause
> serious problems for AIX because the GOT register will not be
> restored.

One of optimizations IPA visibility does is that it looks for global symbols
that
  1) are believed by target to be overwritable (interposed - I will probably
     update name here) by linker to a different definition (we have
     decl_binds_to_current_def_p that is target tweakable), and
  2) the interposition may not change semantics of the symbol (i.e. function
     body must be the same or variable initializer must match)

     For some symbols (such as inline functions, virtual tables, readonly
     variables with no address taken) we know it won't.
  3) the symbol's definition can not be optimized away by linker
     (by symtab_can_be_discarded)
If all conditons match, it creates a static alias (not hidden, just local to
the .o file) and redirects users of the symbol to the alias.  This should be
always win: we know that the representation of symbol will survive to final
binary (it is not discarded) and we replace expensive references through GOT by
cheap references to local symbol.

We did, for longer time, redirect calls.  The troublesome patch makes us to
redirect also references in virtual tables and newly we also consider virtual
tables themselves for aliases.

This should be a win, since virtual tables tends to be startup time hogs and
it is common to have virtual tables in one DSO to refer to comdats that are
shared with other DSO, but because they must be the same, we can just ignore
the sharing.

On AIX we observed interesting series of events.

 1) First the output machinery was not quite able to declare local static
    alias for a symbol (this was about year ago when I introduced the first
    change).
 2) AIX assembler seems to issue warning when jump happens to the local
    static alias confusing it with the global symbol it is aliasing.
    I do not know if the warning is just bogus or we output something
    incorrectly.  This is the reason for NOP warning as I understand.
 3) Important difference we is that in AIX all COMDAT symbols are considered
    non-discardable. This makes us to produce a lot more aliases than on ELF
    system.

    I am not sure if this is acurate and AIX linker really has no means
    of removing duplicated bodies of COMDAT functions/initializers of variables.
    If it has, we need to model it in symtab_can_be_discarded.
    Currently we test whether symbol is in comdat group and in the case of
    AIX it isn't. 

    As disucssed earlier, I am thinking about making symtab_can_be_discarded
    return true also for implicit sections (I have WIP patch for this to
    commit today). Earlier version of the patch however did not solve
    the warnings.

    I also tested libstdc++.so sizes with current mainline, with the
    local aliases disabled and with this change and current mainline
    wins. Suggesting that perhaps there is really no way to discard
    duplicated comdats or libstdc++ doesn't really have them.
    Insight here would be welcome - I am sure it is easy to test if 
    including and using inline __noinline__ function in two units
    leads to two copies of that beast or not. It would be nice to know
    how native toolchain handles it and if GCC does the same trick.
 4) Before 4.9 we hit bug in inliner dealing with aliases that gave me
    a headache. It reproduced on AIX only because of 3)
 5) We hit problem with aliases to anchored sections, hopefully solved now
 6) We hit the problem that AIX assembler silently accepts but miscompile
    when alias is declared before its target.  THis is also hopefully
    fixed now.  We hit it twice - one for normal symbols about year ago
    and now again for thunks.
 7) Given number of issues I ended up writting a verifier that checks
    sanity of sections, aliases and comdat groups.  I check
      a) all symbols in comdat group have the same section
      b) alias and its target have same comdat group & section characteristics
         (obivously one can not place alias out of comdat)
      c) I check sanity of IMPLICIT_SECTION flag.
    It turns out that C++ FE makes complete mess of those breaking all three
    rules due to complex interactions in between comdat code, same body aliases
    and the way thunks are produced.  I think this may confuse AIX output
    macros since they are just given a contradictionary information.
    So it may turn out that the AIX assembler warnings are correct.

    Have patch in testing and it seems that warnings are gone, but I am not
    at the end of bootstrap, yet, now resolving issues with libfortran.

    I plan to add check that we do not have two comdat groups of the same
    name, but I am not there, yet.  As usual, verifier improvements show
    issues that are a lot of fun to resolve.

Still, i would not think of the original optimization as aggressive and risky one.
We just found that the way we deal with aliases is terribly broken at some targets.
Pretty much all the bugs above are reproducable by a testcases using alias attribute.
Yes, i understand it is frustrating (to me too) and that I should be faster dealing
with the issue (teaching in Canada is time consuming). 

I am now again testing similar changes on AIX before comitting.  I considered
the original TLC patch as simple change given that we already debugged the
local aliases for 4.9.  I am sorry for that.  I will try to be sure that I get libstdc++
testsuite into a shape either by comitting the patch for 7) or reverting the relevant
part of the TLC patch.

Honza

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

* Re: ipa-visibility TLC 2/n
  2014-06-10 18:02                     ` Jan Hubicka
@ 2014-06-10 22:23                       ` David Edelsohn
  2014-06-10 22:55                         ` Jan Hubicka
  2014-06-11  8:17                         ` Jan Hubicka
  0 siblings, 2 replies; 44+ messages in thread
From: David Edelsohn @ 2014-06-10 22:23 UTC (permalink / raw)
  To: Jan Hubicka
  Cc: Richard Biener, GCC Patches, Richard Henderson, ramrad01,
	Richard Sandiford

On Tue, Jun 10, 2014 at 2:02 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> Honza,
>>
>> Thanks for this patch which improves some of the G++ testsuite
>> failures, but most of the libstdc++ testsuite continues to fail on
>> AIX.
>
> Yep, I am still looking into this.  Just made new alias verifier that
> catches quite few nonsenses in how C++ builds thunks and same body
> aliases.  I am testing it on PPC now (it takes a while)
>>
>> This patch clearly was risky and should have been more thoroughly
>> tested on non-GNU/Linux systems. All of these failures make it
>> impossible to know if other failures have been introduced into the AIX
>> port.
>>
>> I will be happy to work with you to debug these failures, but I wish
>> to ask that the IPA visibility patch be reverted until AIX testsuite
>> results can return to a normal state with the patch applied.
>
> OK, the change does redirecting of functions and variables.  I will try
> to figure out which of those two changes actually breaks AIX and disable
> it for time being.

Honza,

I am not sure that the problem is caused only by aliases and thunks.
The large increase in AIX linker warnings about branches not followed
by nop also worry me.

Your patch was about visibility. How does the more aggressive
algorithm behave on a platform that does not support visibility? Is it
defaulting to hidden? If the new algorithm is being too aggressive and
incorrectly converting calls from global to local, it could cause
serious problems for AIX because the GOT register will not be
restored.

Thanks David

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

* Re: ipa-visibility TLC 2/n
  2014-06-10 13:08                   ` David Edelsohn
@ 2014-06-10 18:02                     ` Jan Hubicka
  2014-06-10 22:23                       ` David Edelsohn
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-06-10 18:02 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Jan Hubicka, Richard Biener, GCC Patches, Richard Henderson,
	ramrad01, Richard Sandiford

> Honza,
> 
> Thanks for this patch which improves some of the G++ testsuite
> failures, but most of the libstdc++ testsuite continues to fail on
> AIX.

Yep, I am still looking into this.  Just made new alias verifier that
catches quite few nonsenses in how C++ builds thunks and same body
aliases.  I am testing it on PPC now (it takes a while)
> 
> This patch clearly was risky and should have been more thoroughly
> tested on non-GNU/Linux systems. All of these failures make it
> impossible to know if other failures have been introduced into the AIX
> port.
> 
> I will be happy to work with you to debug these failures, but I wish
> to ask that the IPA visibility patch be reverted until AIX testsuite
> results can return to a normal state with the patch applied.

OK, the change does redirecting of functions and variables.  I will try
to figure out which of those two changes actually breaks AIX and disable
it for time being.

We are running into existing problems with aliases (obvoiusly making alias
and redirecting uses to it should not break code). Do we care about aliases
working on release branches? (I can make backporatble patches for those fixes,
but given that no one noitced it so far means that probably no one uses them)

Honza
> 
> Thanks, David

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

* Re: ipa-visibility TLC 2/n
  2014-06-08 16:58                 ` Jan Hubicka
@ 2014-06-10 13:08                   ` David Edelsohn
  2014-06-10 18:02                     ` Jan Hubicka
  0 siblings, 1 reply; 44+ messages in thread
From: David Edelsohn @ 2014-06-10 13:08 UTC (permalink / raw)
  To: Jan Hubicka, Richard Biener
  Cc: GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

On Sun, Jun 8, 2014 at 12:58 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> Hi,
> this is the last part.  It makes DECL_VIRTUAL to be copied when creating aliases.  This is
> needed to make sanity check in gimple-fold happy (it checks that vtables are DECL_VIRTUAL).
> It also resets initializers of aliases to save memory.

Honza,

Thanks for this patch which improves some of the G++ testsuite
failures, but most of the libstdc++ testsuite continues to fail on
AIX.

This patch clearly was risky and should have been more thoroughly
tested on non-GNU/Linux systems. All of these failures make it
impossible to know if other failures have been introduced into the AIX
port.

I will be happy to work with you to debug these failures, but I wish
to ask that the IPA visibility patch be reverted until AIX testsuite
results can return to a normal state with the patch applied.

Thanks, David

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

* Re: ipa-visibility TLC 2/n
  2014-06-08 16:44               ` Jan Hubicka
@ 2014-06-10  8:51                 ` Richard Biener
  0 siblings, 0 replies; 44+ messages in thread
From: Richard Biener @ 2014-06-10  8:51 UTC (permalink / raw)
  To: Jan Hubicka
  Cc: David Edelsohn, GCC Patches, Richard Henderson, ramrad01,
	Richard Sandiford

On Sun, Jun 8, 2014 at 6:44 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> Honza,
>>
>> I finally was able to bootstrap GCC on AIX yesterday. The bootstrap
>> works, but the testsuite results are in extremely bad shape: 250
>> failures in G++ testsuite and 470 failures in libstdc++ testsuite.
>
> David, this is first of the AIX fixes.
> It makes aliases to be output after thunks so they are not silently miscompiled
> by the assembler.  I checked and the other ordering issue was actually
> Solaris linker not liking thunks before functions (that is a pity, because
> thunk just before function desn't need the tail jump: something I still want
> to get right, but incrementally).
>
> Bootstrapped/regtested on AIX, comitted.
>
> Honza
>
>         * cgraphunit.c (assemble_thunks_and_aliases): Expand thunks before
>         outputting aliases.
>
> Index: cgraphunit.c
> ===================================================================
> --- cgraphunit.c        (revision 211106)
> +++ cgraphunit.c        (working copy)
> @@ -1718,8 +1718,8 @@
>         struct cgraph_node *thunk = e->caller;
>
>         e = e->next_caller;
> +        expand_thunk (thunk, true);
>         assemble_thunks_and_aliases (thunk);

Please add a comment explaining the order of those calls.

> -        expand_thunk (thunk, true);
>        }
>      else
>        e = e->next_caller;

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

* Re: ipa-visibility TLC 2/n
  2014-06-08 16:54               ` Jan Hubicka
@ 2014-06-08 16:58                 ` Jan Hubicka
  2014-06-10 13:08                   ` David Edelsohn
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-06-08 16:58 UTC (permalink / raw)
  To: Jan Hubicka
  Cc: David Edelsohn, GCC Patches, Richard Henderson, ramrad01,
	Richard Sandiford

Hi,
this is the last part.  It makes DECL_VIRTUAL to be copied when creating aliases.  This is
needed to make sanity check in gimple-fold happy (it checks that vtables are DECL_VIRTUAL).
It also resets initializers of aliases to save memory.

Bootstrapped/regtested rs6000-aix, comitted.

Index: symtab.c
===================================================================
--- symtab.c	(revision 211357)
+++ symtab.c	(working copy)
@@ -1154,7 +1154,9 @@
   TREE_PUBLIC (new_decl) = 0;
   DECL_COMDAT (new_decl) = 0;
   DECL_WEAK (new_decl) = 0;
-  DECL_VIRTUAL_P (new_decl) = 0;
+
+  /* Since the aliases can be added to vtables, keep DECL_VIRTUAL flag.  */
+  DECL_VIRTUAL_P (new_decl) = DECL_VIRTUAL_P (node->decl);
   if (TREE_CODE (new_decl) == FUNCTION_DECL)
     {
       DECL_STATIC_CONSTRUCTOR (new_decl) = 0;
@@ -1165,6 +1167,7 @@
   else
     {
       TREE_READONLY (new_decl) = TREE_READONLY (node->decl);
+      DECL_INITIAL (new_decl) = error_mark_node;
       new_node = varpool_create_variable_alias (new_decl, node->decl);
     }
   symtab_resolve_alias (new_node, node);  

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

* Re: ipa-visibility TLC 2/n
  2014-05-30 15:50             ` David Edelsohn
  2014-06-08 16:44               ` Jan Hubicka
  2014-06-08 16:49               ` Jan Hubicka
@ 2014-06-08 16:54               ` Jan Hubicka
  2014-06-08 16:58                 ` Jan Hubicka
  2 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-06-08 16:54 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

Hi,
this is third part - it fixes handling of aliases in the anchor sections
by recursing in place_block_symbol as discussed and also fixing one case
where we lookup attribute instead of using symbol table

	* varasm.c (use_blocks_for_decl_p): Check symbol table instead of alias
	attribute.
	(place_block_symbol): Recurse on aliases.
Index: varasm.c
===================================================================
--- varasm.c	(revision 211356)
+++ varasm.c	(working copy)
@@ -1184,6 +1184,8 @@
 static bool
 use_blocks_for_decl_p (tree decl)
 {
+  struct symtab_node *snode;
+
   /* Only data DECLs can be placed into object blocks.  */
   if (TREE_CODE (decl) != VAR_DECL && TREE_CODE (decl) != CONST_DECL)
     return false;
@@ -1197,7 +1199,9 @@
 
   /* If this decl is an alias, then we don't want to emit a
      definition.  */
-  if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl)))
+  if (TREE_CODE (decl) == VAR_DECL
+      && (snode = symtab_get_node (decl)) != NULL
+      && snode->alias)
     return false;
 
   return targetm.use_blocks_for_decl_p (decl);
@@ -7028,6 +7032,8 @@
       if (snode->alias)
 	{
 	  rtx target = DECL_RTL (symtab_alias_ultimate_target (snode)->decl);
+
+	  place_block_symbol (target);
 	  SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
 	  return;
 	}

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

* Re: ipa-visibility TLC 2/n
  2014-05-30 15:50             ` David Edelsohn
  2014-06-08 16:44               ` Jan Hubicka
@ 2014-06-08 16:49               ` Jan Hubicka
  2014-06-08 16:54               ` Jan Hubicka
  2 siblings, 0 replies; 44+ messages in thread
From: Jan Hubicka @ 2014-06-08 16:49 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

Hi,
this is second part of fix - it just makes ipa-visibility to work less hard when
initializer already contains local aliases.  I noticed this when debugging the original
issue.

Bootstrapped/regtested rs6000-aix, comitted.

Honza

	* ipa-visibility.c: Include varasm.h
	(can_replace_by_local_alias): Ceck decl_binds_to_current_def_p.
Index: ipa-visibility.c
===================================================================
--- ipa-visibility.c	(revision 211120)
+++ ipa-visibility.c	(working copy)
@@ -82,6 +82,7 @@
 #include "pointer-set.h"
 #include "calls.h"
 #include "gimple-expr.h"
+#include "varasm.h"
 
 /* Return true when NODE can not be local. Worker for cgraph_local_node_p.  */
 
@@ -340,6 +341,7 @@
 can_replace_by_local_alias (symtab_node *node)
 {
   return (symtab_node_availability (node) > AVAIL_OVERWRITABLE
+	  && !decl_binds_to_current_def_p (node->decl)
 	  && !symtab_can_be_discarded (node));
 }
 

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

* Re: ipa-visibility TLC 2/n
  2014-05-30 15:50             ` David Edelsohn
@ 2014-06-08 16:44               ` Jan Hubicka
  2014-06-10  8:51                 ` Richard Biener
  2014-06-08 16:49               ` Jan Hubicka
  2014-06-08 16:54               ` Jan Hubicka
  2 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-06-08 16:44 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

> Honza,
> 
> I finally was able to bootstrap GCC on AIX yesterday. The bootstrap
> works, but the testsuite results are in extremely bad shape: 250
> failures in G++ testsuite and 470 failures in libstdc++ testsuite.

David, this is first of the AIX fixes.
It makes aliases to be output after thunks so they are not silently miscompiled
by the assembler.  I checked and the other ordering issue was actually
Solaris linker not liking thunks before functions (that is a pity, because
thunk just before function desn't need the tail jump: something I still want
to get right, but incrementally).

Bootstrapped/regtested on AIX, comitted.

Honza

	* cgraphunit.c (assemble_thunks_and_aliases): Expand thunks before
        outputting aliases.

Index: cgraphunit.c
===================================================================
--- cgraphunit.c	(revision 211106)
+++ cgraphunit.c	(working copy)
@@ -1718,8 +1718,8 @@
 	struct cgraph_node *thunk = e->caller;
 
 	e = e->next_caller;
+        expand_thunk (thunk, true);
 	assemble_thunks_and_aliases (thunk);
-        expand_thunk (thunk, true);
       }
     else
       e = e->next_caller;

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

* Re: ipa-visibility TLC 2/n
  2014-06-06  7:10                 ` Jan Hubicka
@ 2014-06-06 15:53                   ` David Edelsohn
  0 siblings, 0 replies; 44+ messages in thread
From: David Edelsohn @ 2014-06-06 15:53 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

On Fri, Jun 6, 2014 at 3:09 AM, Jan Hubicka <hubicka@ucw.cz> wrote:

> sorry for taking time to get back to it.  I went through the code and see no obvious flaws
> except that I am somewhat concerned what happens with local aliases into the anchors.
> The problem however does not seem to be caused by it.  I tracked it down to the following
> difference:
>
> --- d2.s        2014-06-06 08:59:01.101401622 +0200
> +++ d3.s        2014-06-06 08:59:01.491377632 +0200
> @@ -499,7 +499,7 @@
>         .long   4
>         .long   4
>         .long   _ZTI1B
> -       .long   _ZTv0_n12_N1B1fEv
> +       .long   _ZTv0_n12_N1B1fEv.localalias.5
>         .weak   _ZTV1A
>         .align 2
>  _ZTV1A:
>
> Now _ZTv0_n12_N1B1fEv is thunk declared as:
>
>         .lglobl .LTHUNK..0
>         .lglobl LTHUNK..0
>         .set    .LTHUNK..0,._ZN1B1fEv
>         .set LTHUNK..0,_ZN1B1fEv
>         .lglobl ._ZTv0_n12_N1B1fEv.localalias.5
>         .lglobl _ZTv0_n12_N1B1fEv.localalias.5
>         .set    ._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
>         .set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
>         .align 2
>         .weak   _ZTv0_n12_N1B1fEv[DS]
>         .weak   ._ZTv0_n12_N1B1fEv
>         .csect _ZTv0_n12_N1B1fEv[DS]
> _ZTv0_n12_N1B1fEv:
>         .long ._ZTv0_n12_N1B1fEv, TOC[tc0], 0
>         .csect .text[PR]
> ._ZTv0_n12_N1B1fEv:
> LFB..16:
>         lwz 12,0(3)
>         lwz 12,-12(12)
>         add 3,3,12
>         b .LTHUNK..0
>
> Now when I move the declaration of localalias after the thunk:
>
> --- d3.s        2014-06-06 08:59:01.491377632 +0200
> +++ d4.s        2014-06-06 09:03:58.129810951 +0200
> @@ -212,10 +212,6 @@
>         .lglobl LTHUNK..0
>         .set    .LTHUNK..0,._ZN1B1fEv
>         .set LTHUNK..0,_ZN1B1fEv
> -       .lglobl ._ZTv0_n12_N1B1fEv.localalias.5
> -       .lglobl _ZTv0_n12_N1B1fEv.localalias.5
> -       .set    ._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
> -       .set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
>         .align 2
>         .weak   _ZTv0_n12_N1B1fEv[DS]
>         .weak   ._ZTv0_n12_N1B1fEv
> @@ -229,6 +225,10 @@
>         lwz 12,-12(12)
>         add 3,3,12
>         b .LTHUNK..0
> +       .lglobl ._ZTv0_n12_N1B1fEv.localalias.5
> +       .lglobl _ZTv0_n12_N1B1fEv.localalias.5
> +       .set    ._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
> +       .set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
>  LFE..16:
>         .align 2
>         .weak   _ZN1D1fEv[DS]
>
> The code starts to work.  To me both sources should make same binary, but they don't.
> Can you make better sense of this than claiming it is an assembler bug?
>
> We output aliases after definitions for functions, but before definitions for thunks.
> I am testing patch to change the second order.  I remeber tweaking this order once before
> because of problems on solaris.  Lets see if we find order that works for everyone.

Honza,

The AIX assembler is a very simple, single-pass assembler. The order
has a lot of importance because the assembler makes assumptions about
symbols, such as section placement and annotations, if they are
referenced before defined. I notice that your change places the
.lglobl declaration after the .weak declaration.  That may be more
important than placing it after the thunk.

Thanks, David

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

* Re: ipa-visibility TLC 2/n
  2014-06-03 13:53               ` David Edelsohn
@ 2014-06-06  7:10                 ` Jan Hubicka
  2014-06-06 15:53                   ` David Edelsohn
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-06-06  7:10 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]

> Honza,
> 
> How can we make further progress with the large regression on AIX?
David,
sorry for taking time to get back to it.  I went through the code and see no obvious flaws
except that I am somewhat concerned what happens with local aliases into the anchors.
The problem however does not seem to be caused by it.  I tracked it down to the following
difference:

--- d2.s	2014-06-06 08:59:01.101401622 +0200
+++ d3.s	2014-06-06 08:59:01.491377632 +0200
@@ -499,7 +499,7 @@
 	.long	4
 	.long	4
 	.long	_ZTI1B
-	.long	_ZTv0_n12_N1B1fEv
+	.long	_ZTv0_n12_N1B1fEv.localalias.5
 	.weak	_ZTV1A
 	.align 2
 _ZTV1A:

Now _ZTv0_n12_N1B1fEv is thunk declared as:

        .lglobl .LTHUNK..0
        .lglobl LTHUNK..0
        .set    .LTHUNK..0,._ZN1B1fEv
        .set LTHUNK..0,_ZN1B1fEv
        .lglobl ._ZTv0_n12_N1B1fEv.localalias.5
        .lglobl _ZTv0_n12_N1B1fEv.localalias.5
        .set    ._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
        .set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
        .align 2
        .weak   _ZTv0_n12_N1B1fEv[DS]
        .weak   ._ZTv0_n12_N1B1fEv
        .csect _ZTv0_n12_N1B1fEv[DS]
_ZTv0_n12_N1B1fEv:
        .long ._ZTv0_n12_N1B1fEv, TOC[tc0], 0
        .csect .text[PR]
._ZTv0_n12_N1B1fEv:
LFB..16:
        lwz 12,0(3)
        lwz 12,-12(12)
        add 3,3,12
        b .LTHUNK..0

Now when I move the declaration of localalias after the thunk:

--- d3.s	2014-06-06 08:59:01.491377632 +0200
+++ d4.s	2014-06-06 09:03:58.129810951 +0200
@@ -212,10 +212,6 @@
 	.lglobl	LTHUNK..0
 	.set	.LTHUNK..0,._ZN1B1fEv
 	.set LTHUNK..0,_ZN1B1fEv
-	.lglobl	._ZTv0_n12_N1B1fEv.localalias.5
-	.lglobl	_ZTv0_n12_N1B1fEv.localalias.5
-	.set	._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
-	.set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
 	.align 2
 	.weak	_ZTv0_n12_N1B1fEv[DS]
 	.weak	._ZTv0_n12_N1B1fEv
@@ -229,6 +225,10 @@
 	lwz 12,-12(12)
 	add 3,3,12
 	b .LTHUNK..0
+	.lglobl	._ZTv0_n12_N1B1fEv.localalias.5
+	.lglobl	_ZTv0_n12_N1B1fEv.localalias.5
+	.set	._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
+	.set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
 LFE..16:
 	.align 2
 	.weak	_ZN1D1fEv[DS]

The code starts to work.  To me both sources should make same binary, but they don't.
Can you make better sense of this than claiming it is an assembler bug?

We output aliases after definitions for functions, but before definitions for thunks.
I am testing patch to change the second order.  I remeber tweaking this order once before
because of problems on solaris.  Lets see if we find order that works for everyone.

Honza

[-- Attachment #2: d2.s --]
[-- Type: text/plain, Size: 11831 bytes --]

	.file	"/home/jh/trunk/gcc/testsuite/g++.dg/abi/vcall1.C"
	.csect .text[PR]
	.toc
	.csect .text[PR]
	.globl b
	.csect .data[RW],4
	.align 2
b:
	.space 4
	.csect .text[PR]
	.align 2
	.weak	_ZN1A1fEv[DS]
	.weak	._ZN1A1fEv
	.csect _ZN1A1fEv[DS]
_ZN1A1fEv:
	.long ._ZN1A1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZN1A1fEv:
LFB..0:
	stw 31,-4(1)
	stwu 1,-32(1)
LCFI..0:
	mr 31,1
LCFI..1:
	stw 3,56(31)
	addi 1,31,32
LCFI..2:
	lwz 31,-4(1)
	blr
LT.._ZN1A1fEv:
	.long 0
	.byte 0,9,32,96,128,1,1,1
	.long 0
	.long LT.._ZN1A1fEv-._ZN1A1fEv
	.short 9
	.byte "_ZN1A1fEv"
	.byte 31
	.align 2
LFE..0:
	.lglobl	._ZN1A1fEv.localalias.4
	.lglobl	_ZN1A1fEv.localalias.4
	.set	._ZN1A1fEv.localalias.4,._ZN1A1fEv
	.set _ZN1A1fEv.localalias.4,_ZN1A1fEv
	.toc
LC..0:
	.tc _ZTV1A.P8[TC],_ZTV1A+8
	.csect .text[PR]
	.align 2
	.weak	_ZN1AC2Ev[DS]
	.weak	._ZN1AC2Ev
	.csect _ZN1AC2Ev[DS]
_ZN1AC2Ev:
	.long ._ZN1AC2Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1AC2Ev:
LFB..3:
	stw 31,-4(1)
	stwu 1,-32(1)
LCFI..3:
	mr 31,1
LCFI..4:
	stw 3,56(31)
	lwz 9,56(31)
	lwz 10,LC..0(2)
	stw 10,0(9)
	addi 1,31,32
LCFI..5:
	lwz 31,-4(1)
	blr
LT.._ZN1AC2Ev:
	.long 0
	.byte 0,9,32,96,128,1,1,1
	.long 0
	.long LT.._ZN1AC2Ev-._ZN1AC2Ev
	.short 9
	.byte "_ZN1AC2Ev"
	.byte 31
	.align 2
LFE..3:
	.lglobl	._ZN1AC2Ev.localalias.3
	.lglobl	_ZN1AC2Ev.localalias.3
	.set	._ZN1AC2Ev.localalias.3,._ZN1AC2Ev
	.set _ZN1AC2Ev.localalias.3,_ZN1AC2Ev
	.toc
LC..1:
	.tc b[TC],b
	.csect .text[PR]
	.align 2
	.weak	_ZN1BC2Ev[DS]
	.weak	._ZN1BC2Ev
	.csect _ZN1BC2Ev[DS]
_ZN1BC2Ev:
	.long ._ZN1BC2Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1BC2Ev:
LFB..5:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..6:
	mr 31,1
LCFI..7:
	stw 3,88(31)
	stw 4,92(31)
	lwz 9,92(31)
	lwz 10,0(9)
	lwz 9,88(31)
	stw 10,0(9)
	lwz 9,88(31)
	lwz 9,0(9)
	addi 9,9,-16
	lwz 9,0(9)
	mr 10,9
	lwz 9,88(31)
	add 9,9,10
	lwz 10,92(31)
	lwz 10,4(10)
	stw 10,0(9)
	lwz 9,LC..1(2)
	lwz 10,88(31)
	stw 10,0(9)
	lwz 9,88(31)
	lwz 9,0(9)
	addi 9,9,-16
	lwz 9,0(9)
	mr 10,9
	lwz 9,88(31)
	add 9,9,10
	lwz 9,0(9)
	lwz 9,0(9)
	lwz 10,88(31)
	lwz 10,0(10)
	addi 10,10,-16
	lwz 10,0(10)
	mr 8,10
	lwz 10,88(31)
	add 10,10,8
	mr 3,10
	stw 2,20(1)
	lwz 10,0(9)
	lwz 11,8(9)
	mtctr 10
	lwz 2,4(9)
	bctrl
	lwz 2,20(1)
	addi 1,31,64
LCFI..8:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1BC2Ev:
	.long 0
	.byte 0,9,32,97,128,1,2,1
	.long 0
	.long LT.._ZN1BC2Ev-._ZN1BC2Ev
	.short 9
	.byte "_ZN1BC2Ev"
	.byte 31
	.align 2
LFE..5:
	.lglobl	._ZN1BC2Ev.localalias.2
	.lglobl	_ZN1BC2Ev.localalias.2
	.set	._ZN1BC2Ev.localalias.2,._ZN1BC2Ev
	.set _ZN1BC2Ev.localalias.2,_ZN1BC2Ev
	.toc
	.set LC..2,LC..1
	.csect .text[PR]
	.align 2
	.weak	_ZN1B1fEv[DS]
	.weak	._ZN1B1fEv
	.csect _ZN1B1fEv[DS]
_ZN1B1fEv:
	.long ._ZN1B1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZN1B1fEv:
LFB..7:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..9:
	mr 31,1
LCFI..10:
	stw 3,88(31)
	lwz 9,LC..2(2)
	lwz 9,0(9)
	lwz 10,88(31)
	cmpw 7,10,9
	beq 7,L..4
	bl .abort
	nop
L..4:
	addi 1,31,64
LCFI..11:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1B1fEv:
	.long 0
	.byte 0,9,32,97,128,1,1,1
	.long 0
	.long LT.._ZN1B1fEv-._ZN1B1fEv
	.short 9
	.byte "_ZN1B1fEv"
	.byte 31
	.align 2
LFE..7:
	.lglobl	.LTHUNK..0
	.lglobl	LTHUNK..0
	.set	.LTHUNK..0,._ZN1B1fEv
	.set LTHUNK..0,_ZN1B1fEv
	.lglobl	._ZTv0_n12_N1B1fEv.localalias.5
	.lglobl	_ZTv0_n12_N1B1fEv.localalias.5
	.set	._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
	.set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
	.align 2
	.weak	_ZTv0_n12_N1B1fEv[DS]
	.weak	._ZTv0_n12_N1B1fEv
	.csect _ZTv0_n12_N1B1fEv[DS]
_ZTv0_n12_N1B1fEv:
	.long ._ZTv0_n12_N1B1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZTv0_n12_N1B1fEv:
LFB..16:
	lwz 12,0(3)
	lwz 12,-12(12)
	add 3,3,12
	b .LTHUNK..0
LFE..16:
	.align 2
	.weak	_ZN1D1fEv[DS]
	.weak	._ZN1D1fEv
	.csect _ZN1D1fEv[DS]
_ZN1D1fEv:
	.long ._ZN1D1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZN1D1fEv:
LFB..8:
	stw 31,-4(1)
	stwu 1,-32(1)
LCFI..12:
	mr 31,1
LCFI..13:
	stw 3,56(31)
	addi 1,31,32
LCFI..14:
	lwz 31,-4(1)
	blr
LT.._ZN1D1fEv:
	.long 0
	.byte 0,9,32,96,128,1,1,1
	.long 0
	.long LT.._ZN1D1fEv-._ZN1D1fEv
	.short 9
	.byte "_ZN1D1fEv"
	.byte 31
	.align 2
LFE..8:
	.lglobl	.LTHUNK..2
	.lglobl	LTHUNK..2
	.set	.LTHUNK..2,._ZN1D1fEv
	.set LTHUNK..2,_ZN1D1fEv
	.lglobl	._ZThn4_N1D1fEv.localalias.10
	.lglobl	_ZThn4_N1D1fEv.localalias.10
	.set	._ZThn4_N1D1fEv.localalias.10,._ZThn4_N1D1fEv
	.set _ZThn4_N1D1fEv.localalias.10,_ZThn4_N1D1fEv
	.align 2
	.weak	_ZThn4_N1D1fEv[DS]
	.weak	._ZThn4_N1D1fEv
	.csect _ZThn4_N1D1fEv[DS]
_ZThn4_N1D1fEv:
	.long ._ZThn4_N1D1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZThn4_N1D1fEv:
LFB..17:
	addi 3,3,-4
	b .LTHUNK..2
LFE..17:
	.align 2
	.weak	_ZN1CC2Ev[DS]
	.weak	._ZN1CC2Ev
	.csect _ZN1CC2Ev[DS]
_ZN1CC2Ev:
	.long ._ZN1CC2Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1CC2Ev:
LFB..12:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..15:
	mr 31,1
LCFI..16:
	stw 3,88(31)
	stw 4,92(31)
	lwz 10,88(31)
	lwz 9,92(31)
	addi 9,9,4
	mr 4,9
	mr 3,10
	bl ._ZN1BC2Ev.localalias.2
	lwz 9,92(31)
	lwz 10,0(9)
	lwz 9,88(31)
	stw 10,0(9)
	lwz 9,88(31)
	lwz 9,0(9)
	addi 9,9,-16
	lwz 9,0(9)
	mr 10,9
	lwz 9,88(31)
	add 9,9,10
	lwz 10,92(31)
	lwz 10,12(10)
	stw 10,0(9)
	addi 1,31,64
LCFI..17:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1CC2Ev:
	.long 0
	.byte 0,9,32,97,128,1,2,1
	.long 0
	.long LT.._ZN1CC2Ev-._ZN1CC2Ev
	.short 9
	.byte "_ZN1CC2Ev"
	.byte 31
	.align 2
LFE..12:
	.lglobl	._ZN1CC2Ev.localalias.1
	.lglobl	_ZN1CC2Ev.localalias.1
	.set	._ZN1CC2Ev.localalias.1,._ZN1CC2Ev
	.set _ZN1CC2Ev.localalias.1,_ZN1CC2Ev
	.toc
LC..3:
	.tc _ZTT1D.P4[TC],_ZTT1D+4
LC..4:
	.tc _ZTT1D.P20[TC],_ZTT1D+20
LC..5:
	.tc _ZTV1D.P16[TC],_ZTV1D+16
LC..6:
	.tc _ZTV1D.P36[TC],_ZTV1D+36
	.csect .text[PR]
	.align 2
	.weak	_ZN1DC1Ev[DS]
	.weak	._ZN1DC1Ev
	.csect _ZN1DC1Ev[DS]
_ZN1DC1Ev:
	.long ._ZN1DC1Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1DC1Ev:
LFB..15:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..18:
	mr 31,1
LCFI..19:
	stw 3,88(31)
	lwz 9,88(31)
	mr 3,9
	bl ._ZN1AC2Ev.localalias.3
	lwz 9,88(31)
	lwz 10,LC..3(2)
	mr 4,10
	mr 3,9
	bl ._ZN1CC2Ev.localalias.1
	lwz 9,88(31)
	addi 9,9,4
	lwz 10,LC..4(2)
	mr 4,10
	mr 3,9
	bl ._ZN1BC2Ev.localalias.2
	lwz 10,LC..5(2)
	lwz 9,88(31)
	stw 10,0(9)
	li 9,0
	lwz 10,88(31)
	add 9,10,9
	lwz 10,LC..5(2)
	stw 10,0(9)
	lwz 10,LC..6(2)
	lwz 9,88(31)
	stw 10,4(9)
	addi 1,31,64
LCFI..20:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1DC1Ev:
	.long 0
	.byte 0,9,32,97,128,1,1,1
	.long 0
	.long LT.._ZN1DC1Ev-._ZN1DC1Ev
	.short 9
	.byte "_ZN1DC1Ev"
	.byte 31
	.align 2
LFE..15:
	.lglobl	._ZN1DC1Ev.localalias.0
	.lglobl	_ZN1DC1Ev.localalias.0
	.set	._ZN1DC1Ev.localalias.0,._ZN1DC1Ev
	.set _ZN1DC1Ev.localalias.0,_ZN1DC1Ev
	.align 2
	.globl main
	.globl .main
	.csect main[DS]
main:
	.long .main, TOC[tc0], 0
	.csect .text[PR]
.main:
LFB..9:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-96(1)
LCFI..21:
	mr 31,1
LCFI..22:
	addi 9,31,56
	mr 3,9
	bl ._ZN1DC1Ev.localalias.0
	li 9,0
	mr 3,9
	addi 1,31,96
LCFI..23:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT..main:
	.long 0
	.byte 0,9,32,97,128,1,0,1
	.long LT..main-.main
	.short 4
	.byte "main"
	.byte 31
	.align 2
LFE..9:
	.weak	_ZTV1D
	.csect .data[RW],4
	.align 2
_ZTV1D:
	.long	0
	.long	0
	.long	0
	.long	_ZTI1D
	.long	LTHUNK..0
	.long	-4
	.long	-4
	.long	-4
	.long	_ZTI1D
	.long	_ZThn4_N1D1fEv.localalias.10
	.set _ZTV1D.localalias.6,_ZTV1D
	.weak	_ZTT1D
	.align 2
_ZTT1D:
	.long	_ZTV1D.localalias.6+16
	.long	_ZTC1D0_1C+16
	.long	_ZTC1D0_1B+16
	.long	_ZTC1D0_1B+16
	.long	_ZTC1D0_1C+16
	.long	_ZTC1D4_1B+16
	.long	_ZTC1D4_1B+32
	.long	_ZTV1D.localalias.6+16
	.long	_ZTV1D.localalias.6+36
	.weak	_ZTC1D0_1C
	.align 2
_ZTC1D0_1C:
	.long	0
	.long	0
	.long	0
	.long	_ZTI1C
	.long	LTHUNK..0
	.weak	_ZTC1D0_1B
	.align 2
_ZTC1D0_1B:
	.long	0
	.long	0
	.long	0
	.long	_ZTI1B
	.long	LTHUNK..0
	.weak	_ZTC1D4_1B
	.align 2
_ZTC1D4_1B:
	.long	-4
	.long	0
	.long	0
	.long	_ZTI1B
	.long	LTHUNK..0
	.long	4
	.long	4
	.long	_ZTI1B
	.long	_ZTv0_n12_N1B1fEv
	.weak	_ZTV1A
	.align 2
_ZTV1A:
	.long	0
	.long	_ZTI1A
	.long	_ZN1A1fEv.localalias.4
	.weak	_ZTI1D
	.align 2
_ZTI1D:
	.long	_ZTVN10__cxxabiv121__vmi_class_type_infoE+8
	.long	_ZTS1D
	.long	3
	.long	2
	.long	_ZTI1C
	.long	2
	.long	_ZTI1B
	.long	1026
	.weak	_ZTS1D
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1D:
	.byte "1D"
	.byte 0
	.weak	_ZTI1C
	.csect .data[RW],4
	.align 2
_ZTI1C:
	.long	_ZTVN10__cxxabiv120__si_class_type_infoE+8
	.long	_ZTS1C
	.long	_ZTI1B
	.weak	_ZTS1C
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1C:
	.byte "1C"
	.byte 0
	.weak	_ZTI1B
	.csect .data[RW],4
	.align 2
_ZTI1B:
	.long	_ZTVN10__cxxabiv121__vmi_class_type_infoE+8
	.long	_ZTS1B
	.long	0
	.long	1
	.long	_ZTI1A
	.long	-4093
	.weak	_ZTS1B
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1B:
	.byte "1B"
	.byte 0
	.weak	_ZTI1A
	.csect .data[RW],4
	.align 2
_ZTI1A:
	.long	_ZTVN10__cxxabiv117__class_type_infoE+8
	.long	_ZTS1A
	.weak	_ZTS1A
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1A:
	.byte "1A"
	.byte 0
	.csect .data[RW],4
	.align 2
	.globl _GLOBAL__F_b
_GLOBAL__F_b:
Lframe..1:
	.vbyte	4,LECIE..1-LSCIE..1
LSCIE..1:
	.vbyte	4,0
	.byte	0x3
	.byte 0
	.byte	0x1
	.byte	0x7c
	.byte	0x41
	.byte	0xc
	.byte	0x1
	.byte	0
	.align 2
LECIE..1:
LSFDE..1:
	.vbyte	4,LEFDE..1-LASFDE..1
LASFDE..1:
	.vbyte	4,LASFDE..1-Lframe..1
	.vbyte	4,LFB..5
	.vbyte	4,LFE..5-LFB..5
	.byte	0x4
	.vbyte	4,LCFI..6-LFB..5
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..7-LCFI..6
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..8-LCFI..7
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..1:
LSFDE..3:
	.vbyte	4,LEFDE..3-LASFDE..3
LASFDE..3:
	.vbyte	4,LASFDE..3-Lframe..1
	.vbyte	4,LFB..7
	.vbyte	4,LFE..7-LFB..7
	.byte	0x4
	.vbyte	4,LCFI..9-LFB..7
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..10-LCFI..9
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..11-LCFI..10
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..3:
LSFDE..5:
	.vbyte	4,LEFDE..5-LASFDE..5
LASFDE..5:
	.vbyte	4,LASFDE..5-Lframe..1
	.vbyte	4,LFB..16
	.vbyte	4,LFE..16-LFB..16
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..5:
LSFDE..7:
	.vbyte	4,LEFDE..7-LASFDE..7
LASFDE..7:
	.vbyte	4,LASFDE..7-Lframe..1
	.vbyte	4,LFB..17
	.vbyte	4,LFE..17-LFB..17
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..7:
LSFDE..9:
	.vbyte	4,LEFDE..9-LASFDE..9
LASFDE..9:
	.vbyte	4,LASFDE..9-Lframe..1
	.vbyte	4,LFB..12
	.vbyte	4,LFE..12-LFB..12
	.byte	0x4
	.vbyte	4,LCFI..15-LFB..12
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..16-LCFI..15
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..17-LCFI..16
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..9:
LSFDE..11:
	.vbyte	4,LEFDE..11-LASFDE..11
LASFDE..11:
	.vbyte	4,LASFDE..11-Lframe..1
	.vbyte	4,LFB..15
	.vbyte	4,LFE..15-LFB..15
	.byte	0x4
	.vbyte	4,LCFI..18-LFB..15
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..19-LCFI..18
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..20-LCFI..19
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..11:
LSFDE..13:
	.vbyte	4,LEFDE..13-LASFDE..13
LASFDE..13:
	.vbyte	4,LASFDE..13-Lframe..1
	.vbyte	4,LFB..9
	.vbyte	4,LFE..9-LFB..9
	.byte	0x4
	.vbyte	4,LCFI..21-LFB..9
	.byte	0xe
	.byte	0x60
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..22-LCFI..21
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..23-LCFI..22
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..13:
	.vbyte	4,0
	.csect .text[PR]
_section_.text:
	.csect .data[RW],4
	.long _section_.text

[-- Attachment #3: d3.s --]
[-- Type: text/plain, Size: 11844 bytes --]

	.file	"/home/jh/trunk/gcc/testsuite/g++.dg/abi/vcall1.C"
	.csect .text[PR]
	.toc
	.csect .text[PR]
	.globl b
	.csect .data[RW],4
	.align 2
b:
	.space 4
	.csect .text[PR]
	.align 2
	.weak	_ZN1A1fEv[DS]
	.weak	._ZN1A1fEv
	.csect _ZN1A1fEv[DS]
_ZN1A1fEv:
	.long ._ZN1A1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZN1A1fEv:
LFB..0:
	stw 31,-4(1)
	stwu 1,-32(1)
LCFI..0:
	mr 31,1
LCFI..1:
	stw 3,56(31)
	addi 1,31,32
LCFI..2:
	lwz 31,-4(1)
	blr
LT.._ZN1A1fEv:
	.long 0
	.byte 0,9,32,96,128,1,1,1
	.long 0
	.long LT.._ZN1A1fEv-._ZN1A1fEv
	.short 9
	.byte "_ZN1A1fEv"
	.byte 31
	.align 2
LFE..0:
	.lglobl	._ZN1A1fEv.localalias.4
	.lglobl	_ZN1A1fEv.localalias.4
	.set	._ZN1A1fEv.localalias.4,._ZN1A1fEv
	.set _ZN1A1fEv.localalias.4,_ZN1A1fEv
	.toc
LC..0:
	.tc _ZTV1A.P8[TC],_ZTV1A+8
	.csect .text[PR]
	.align 2
	.weak	_ZN1AC2Ev[DS]
	.weak	._ZN1AC2Ev
	.csect _ZN1AC2Ev[DS]
_ZN1AC2Ev:
	.long ._ZN1AC2Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1AC2Ev:
LFB..3:
	stw 31,-4(1)
	stwu 1,-32(1)
LCFI..3:
	mr 31,1
LCFI..4:
	stw 3,56(31)
	lwz 9,56(31)
	lwz 10,LC..0(2)
	stw 10,0(9)
	addi 1,31,32
LCFI..5:
	lwz 31,-4(1)
	blr
LT.._ZN1AC2Ev:
	.long 0
	.byte 0,9,32,96,128,1,1,1
	.long 0
	.long LT.._ZN1AC2Ev-._ZN1AC2Ev
	.short 9
	.byte "_ZN1AC2Ev"
	.byte 31
	.align 2
LFE..3:
	.lglobl	._ZN1AC2Ev.localalias.3
	.lglobl	_ZN1AC2Ev.localalias.3
	.set	._ZN1AC2Ev.localalias.3,._ZN1AC2Ev
	.set _ZN1AC2Ev.localalias.3,_ZN1AC2Ev
	.toc
LC..1:
	.tc b[TC],b
	.csect .text[PR]
	.align 2
	.weak	_ZN1BC2Ev[DS]
	.weak	._ZN1BC2Ev
	.csect _ZN1BC2Ev[DS]
_ZN1BC2Ev:
	.long ._ZN1BC2Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1BC2Ev:
LFB..5:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..6:
	mr 31,1
LCFI..7:
	stw 3,88(31)
	stw 4,92(31)
	lwz 9,92(31)
	lwz 10,0(9)
	lwz 9,88(31)
	stw 10,0(9)
	lwz 9,88(31)
	lwz 9,0(9)
	addi 9,9,-16
	lwz 9,0(9)
	mr 10,9
	lwz 9,88(31)
	add 9,9,10
	lwz 10,92(31)
	lwz 10,4(10)
	stw 10,0(9)
	lwz 9,LC..1(2)
	lwz 10,88(31)
	stw 10,0(9)
	lwz 9,88(31)
	lwz 9,0(9)
	addi 9,9,-16
	lwz 9,0(9)
	mr 10,9
	lwz 9,88(31)
	add 9,9,10
	lwz 9,0(9)
	lwz 9,0(9)
	lwz 10,88(31)
	lwz 10,0(10)
	addi 10,10,-16
	lwz 10,0(10)
	mr 8,10
	lwz 10,88(31)
	add 10,10,8
	mr 3,10
	stw 2,20(1)
	lwz 10,0(9)
	lwz 11,8(9)
	mtctr 10
	lwz 2,4(9)
	bctrl
	lwz 2,20(1)
	addi 1,31,64
LCFI..8:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1BC2Ev:
	.long 0
	.byte 0,9,32,97,128,1,2,1
	.long 0
	.long LT.._ZN1BC2Ev-._ZN1BC2Ev
	.short 9
	.byte "_ZN1BC2Ev"
	.byte 31
	.align 2
LFE..5:
	.lglobl	._ZN1BC2Ev.localalias.2
	.lglobl	_ZN1BC2Ev.localalias.2
	.set	._ZN1BC2Ev.localalias.2,._ZN1BC2Ev
	.set _ZN1BC2Ev.localalias.2,_ZN1BC2Ev
	.toc
	.set LC..2,LC..1
	.csect .text[PR]
	.align 2
	.weak	_ZN1B1fEv[DS]
	.weak	._ZN1B1fEv
	.csect _ZN1B1fEv[DS]
_ZN1B1fEv:
	.long ._ZN1B1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZN1B1fEv:
LFB..7:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..9:
	mr 31,1
LCFI..10:
	stw 3,88(31)
	lwz 9,LC..2(2)
	lwz 9,0(9)
	lwz 10,88(31)
	cmpw 7,10,9
	beq 7,L..4
	bl .abort
	nop
L..4:
	addi 1,31,64
LCFI..11:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1B1fEv:
	.long 0
	.byte 0,9,32,97,128,1,1,1
	.long 0
	.long LT.._ZN1B1fEv-._ZN1B1fEv
	.short 9
	.byte "_ZN1B1fEv"
	.byte 31
	.align 2
LFE..7:
	.lglobl	.LTHUNK..0
	.lglobl	LTHUNK..0
	.set	.LTHUNK..0,._ZN1B1fEv
	.set LTHUNK..0,_ZN1B1fEv
	.lglobl	._ZTv0_n12_N1B1fEv.localalias.5
	.lglobl	_ZTv0_n12_N1B1fEv.localalias.5
	.set	._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
	.set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
	.align 2
	.weak	_ZTv0_n12_N1B1fEv[DS]
	.weak	._ZTv0_n12_N1B1fEv
	.csect _ZTv0_n12_N1B1fEv[DS]
_ZTv0_n12_N1B1fEv:
	.long ._ZTv0_n12_N1B1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZTv0_n12_N1B1fEv:
LFB..16:
	lwz 12,0(3)
	lwz 12,-12(12)
	add 3,3,12
	b .LTHUNK..0
LFE..16:
	.align 2
	.weak	_ZN1D1fEv[DS]
	.weak	._ZN1D1fEv
	.csect _ZN1D1fEv[DS]
_ZN1D1fEv:
	.long ._ZN1D1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZN1D1fEv:
LFB..8:
	stw 31,-4(1)
	stwu 1,-32(1)
LCFI..12:
	mr 31,1
LCFI..13:
	stw 3,56(31)
	addi 1,31,32
LCFI..14:
	lwz 31,-4(1)
	blr
LT.._ZN1D1fEv:
	.long 0
	.byte 0,9,32,96,128,1,1,1
	.long 0
	.long LT.._ZN1D1fEv-._ZN1D1fEv
	.short 9
	.byte "_ZN1D1fEv"
	.byte 31
	.align 2
LFE..8:
	.lglobl	.LTHUNK..2
	.lglobl	LTHUNK..2
	.set	.LTHUNK..2,._ZN1D1fEv
	.set LTHUNK..2,_ZN1D1fEv
	.lglobl	._ZThn4_N1D1fEv.localalias.10
	.lglobl	_ZThn4_N1D1fEv.localalias.10
	.set	._ZThn4_N1D1fEv.localalias.10,._ZThn4_N1D1fEv
	.set _ZThn4_N1D1fEv.localalias.10,_ZThn4_N1D1fEv
	.align 2
	.weak	_ZThn4_N1D1fEv[DS]
	.weak	._ZThn4_N1D1fEv
	.csect _ZThn4_N1D1fEv[DS]
_ZThn4_N1D1fEv:
	.long ._ZThn4_N1D1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZThn4_N1D1fEv:
LFB..17:
	addi 3,3,-4
	b .LTHUNK..2
LFE..17:
	.align 2
	.weak	_ZN1CC2Ev[DS]
	.weak	._ZN1CC2Ev
	.csect _ZN1CC2Ev[DS]
_ZN1CC2Ev:
	.long ._ZN1CC2Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1CC2Ev:
LFB..12:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..15:
	mr 31,1
LCFI..16:
	stw 3,88(31)
	stw 4,92(31)
	lwz 10,88(31)
	lwz 9,92(31)
	addi 9,9,4
	mr 4,9
	mr 3,10
	bl ._ZN1BC2Ev.localalias.2
	lwz 9,92(31)
	lwz 10,0(9)
	lwz 9,88(31)
	stw 10,0(9)
	lwz 9,88(31)
	lwz 9,0(9)
	addi 9,9,-16
	lwz 9,0(9)
	mr 10,9
	lwz 9,88(31)
	add 9,9,10
	lwz 10,92(31)
	lwz 10,12(10)
	stw 10,0(9)
	addi 1,31,64
LCFI..17:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1CC2Ev:
	.long 0
	.byte 0,9,32,97,128,1,2,1
	.long 0
	.long LT.._ZN1CC2Ev-._ZN1CC2Ev
	.short 9
	.byte "_ZN1CC2Ev"
	.byte 31
	.align 2
LFE..12:
	.lglobl	._ZN1CC2Ev.localalias.1
	.lglobl	_ZN1CC2Ev.localalias.1
	.set	._ZN1CC2Ev.localalias.1,._ZN1CC2Ev
	.set _ZN1CC2Ev.localalias.1,_ZN1CC2Ev
	.toc
LC..3:
	.tc _ZTT1D.P4[TC],_ZTT1D+4
LC..4:
	.tc _ZTT1D.P20[TC],_ZTT1D+20
LC..5:
	.tc _ZTV1D.P16[TC],_ZTV1D+16
LC..6:
	.tc _ZTV1D.P36[TC],_ZTV1D+36
	.csect .text[PR]
	.align 2
	.weak	_ZN1DC1Ev[DS]
	.weak	._ZN1DC1Ev
	.csect _ZN1DC1Ev[DS]
_ZN1DC1Ev:
	.long ._ZN1DC1Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1DC1Ev:
LFB..15:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..18:
	mr 31,1
LCFI..19:
	stw 3,88(31)
	lwz 9,88(31)
	mr 3,9
	bl ._ZN1AC2Ev.localalias.3
	lwz 9,88(31)
	lwz 10,LC..3(2)
	mr 4,10
	mr 3,9
	bl ._ZN1CC2Ev.localalias.1
	lwz 9,88(31)
	addi 9,9,4
	lwz 10,LC..4(2)
	mr 4,10
	mr 3,9
	bl ._ZN1BC2Ev.localalias.2
	lwz 10,LC..5(2)
	lwz 9,88(31)
	stw 10,0(9)
	li 9,0
	lwz 10,88(31)
	add 9,10,9
	lwz 10,LC..5(2)
	stw 10,0(9)
	lwz 10,LC..6(2)
	lwz 9,88(31)
	stw 10,4(9)
	addi 1,31,64
LCFI..20:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1DC1Ev:
	.long 0
	.byte 0,9,32,97,128,1,1,1
	.long 0
	.long LT.._ZN1DC1Ev-._ZN1DC1Ev
	.short 9
	.byte "_ZN1DC1Ev"
	.byte 31
	.align 2
LFE..15:
	.lglobl	._ZN1DC1Ev.localalias.0
	.lglobl	_ZN1DC1Ev.localalias.0
	.set	._ZN1DC1Ev.localalias.0,._ZN1DC1Ev
	.set _ZN1DC1Ev.localalias.0,_ZN1DC1Ev
	.align 2
	.globl main
	.globl .main
	.csect main[DS]
main:
	.long .main, TOC[tc0], 0
	.csect .text[PR]
.main:
LFB..9:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-96(1)
LCFI..21:
	mr 31,1
LCFI..22:
	addi 9,31,56
	mr 3,9
	bl ._ZN1DC1Ev.localalias.0
	li 9,0
	mr 3,9
	addi 1,31,96
LCFI..23:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT..main:
	.long 0
	.byte 0,9,32,97,128,1,0,1
	.long LT..main-.main
	.short 4
	.byte "main"
	.byte 31
	.align 2
LFE..9:
	.weak	_ZTV1D
	.csect .data[RW],4
	.align 2
_ZTV1D:
	.long	0
	.long	0
	.long	0
	.long	_ZTI1D
	.long	LTHUNK..0
	.long	-4
	.long	-4
	.long	-4
	.long	_ZTI1D
	.long	_ZThn4_N1D1fEv.localalias.10
	.set _ZTV1D.localalias.6,_ZTV1D
	.weak	_ZTT1D
	.align 2
_ZTT1D:
	.long	_ZTV1D.localalias.6+16
	.long	_ZTC1D0_1C+16
	.long	_ZTC1D0_1B+16
	.long	_ZTC1D0_1B+16
	.long	_ZTC1D0_1C+16
	.long	_ZTC1D4_1B+16
	.long	_ZTC1D4_1B+32
	.long	_ZTV1D.localalias.6+16
	.long	_ZTV1D.localalias.6+36
	.weak	_ZTC1D0_1C
	.align 2
_ZTC1D0_1C:
	.long	0
	.long	0
	.long	0
	.long	_ZTI1C
	.long	LTHUNK..0
	.weak	_ZTC1D0_1B
	.align 2
_ZTC1D0_1B:
	.long	0
	.long	0
	.long	0
	.long	_ZTI1B
	.long	LTHUNK..0
	.weak	_ZTC1D4_1B
	.align 2
_ZTC1D4_1B:
	.long	-4
	.long	0
	.long	0
	.long	_ZTI1B
	.long	LTHUNK..0
	.long	4
	.long	4
	.long	_ZTI1B
	.long	_ZTv0_n12_N1B1fEv.localalias.5
	.weak	_ZTV1A
	.align 2
_ZTV1A:
	.long	0
	.long	_ZTI1A
	.long	_ZN1A1fEv.localalias.4
	.weak	_ZTI1D
	.align 2
_ZTI1D:
	.long	_ZTVN10__cxxabiv121__vmi_class_type_infoE+8
	.long	_ZTS1D
	.long	3
	.long	2
	.long	_ZTI1C
	.long	2
	.long	_ZTI1B
	.long	1026
	.weak	_ZTS1D
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1D:
	.byte "1D"
	.byte 0
	.weak	_ZTI1C
	.csect .data[RW],4
	.align 2
_ZTI1C:
	.long	_ZTVN10__cxxabiv120__si_class_type_infoE+8
	.long	_ZTS1C
	.long	_ZTI1B
	.weak	_ZTS1C
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1C:
	.byte "1C"
	.byte 0
	.weak	_ZTI1B
	.csect .data[RW],4
	.align 2
_ZTI1B:
	.long	_ZTVN10__cxxabiv121__vmi_class_type_infoE+8
	.long	_ZTS1B
	.long	0
	.long	1
	.long	_ZTI1A
	.long	-4093
	.weak	_ZTS1B
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1B:
	.byte "1B"
	.byte 0
	.weak	_ZTI1A
	.csect .data[RW],4
	.align 2
_ZTI1A:
	.long	_ZTVN10__cxxabiv117__class_type_infoE+8
	.long	_ZTS1A
	.weak	_ZTS1A
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1A:
	.byte "1A"
	.byte 0
	.csect .data[RW],4
	.align 2
	.globl _GLOBAL__F_b
_GLOBAL__F_b:
Lframe..1:
	.vbyte	4,LECIE..1-LSCIE..1
LSCIE..1:
	.vbyte	4,0
	.byte	0x3
	.byte 0
	.byte	0x1
	.byte	0x7c
	.byte	0x41
	.byte	0xc
	.byte	0x1
	.byte	0
	.align 2
LECIE..1:
LSFDE..1:
	.vbyte	4,LEFDE..1-LASFDE..1
LASFDE..1:
	.vbyte	4,LASFDE..1-Lframe..1
	.vbyte	4,LFB..5
	.vbyte	4,LFE..5-LFB..5
	.byte	0x4
	.vbyte	4,LCFI..6-LFB..5
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..7-LCFI..6
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..8-LCFI..7
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..1:
LSFDE..3:
	.vbyte	4,LEFDE..3-LASFDE..3
LASFDE..3:
	.vbyte	4,LASFDE..3-Lframe..1
	.vbyte	4,LFB..7
	.vbyte	4,LFE..7-LFB..7
	.byte	0x4
	.vbyte	4,LCFI..9-LFB..7
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..10-LCFI..9
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..11-LCFI..10
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..3:
LSFDE..5:
	.vbyte	4,LEFDE..5-LASFDE..5
LASFDE..5:
	.vbyte	4,LASFDE..5-Lframe..1
	.vbyte	4,LFB..16
	.vbyte	4,LFE..16-LFB..16
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..5:
LSFDE..7:
	.vbyte	4,LEFDE..7-LASFDE..7
LASFDE..7:
	.vbyte	4,LASFDE..7-Lframe..1
	.vbyte	4,LFB..17
	.vbyte	4,LFE..17-LFB..17
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..7:
LSFDE..9:
	.vbyte	4,LEFDE..9-LASFDE..9
LASFDE..9:
	.vbyte	4,LASFDE..9-Lframe..1
	.vbyte	4,LFB..12
	.vbyte	4,LFE..12-LFB..12
	.byte	0x4
	.vbyte	4,LCFI..15-LFB..12
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..16-LCFI..15
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..17-LCFI..16
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..9:
LSFDE..11:
	.vbyte	4,LEFDE..11-LASFDE..11
LASFDE..11:
	.vbyte	4,LASFDE..11-Lframe..1
	.vbyte	4,LFB..15
	.vbyte	4,LFE..15-LFB..15
	.byte	0x4
	.vbyte	4,LCFI..18-LFB..15
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..19-LCFI..18
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..20-LCFI..19
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..11:
LSFDE..13:
	.vbyte	4,LEFDE..13-LASFDE..13
LASFDE..13:
	.vbyte	4,LASFDE..13-Lframe..1
	.vbyte	4,LFB..9
	.vbyte	4,LFE..9-LFB..9
	.byte	0x4
	.vbyte	4,LCFI..21-LFB..9
	.byte	0xe
	.byte	0x60
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..22-LCFI..21
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..23-LCFI..22
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..13:
	.vbyte	4,0
	.csect .text[PR]
_section_.text:
	.csect .data[RW],4
	.long _section_.text

[-- Attachment #4: d4.s --]
[-- Type: text/plain, Size: 11844 bytes --]

	.file	"/home/jh/trunk/gcc/testsuite/g++.dg/abi/vcall1.C"
	.csect .text[PR]
	.toc
	.csect .text[PR]
	.globl b
	.csect .data[RW],4
	.align 2
b:
	.space 4
	.csect .text[PR]
	.align 2
	.weak	_ZN1A1fEv[DS]
	.weak	._ZN1A1fEv
	.csect _ZN1A1fEv[DS]
_ZN1A1fEv:
	.long ._ZN1A1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZN1A1fEv:
LFB..0:
	stw 31,-4(1)
	stwu 1,-32(1)
LCFI..0:
	mr 31,1
LCFI..1:
	stw 3,56(31)
	addi 1,31,32
LCFI..2:
	lwz 31,-4(1)
	blr
LT.._ZN1A1fEv:
	.long 0
	.byte 0,9,32,96,128,1,1,1
	.long 0
	.long LT.._ZN1A1fEv-._ZN1A1fEv
	.short 9
	.byte "_ZN1A1fEv"
	.byte 31
	.align 2
LFE..0:
	.lglobl	._ZN1A1fEv.localalias.4
	.lglobl	_ZN1A1fEv.localalias.4
	.set	._ZN1A1fEv.localalias.4,._ZN1A1fEv
	.set _ZN1A1fEv.localalias.4,_ZN1A1fEv
	.toc
LC..0:
	.tc _ZTV1A.P8[TC],_ZTV1A+8
	.csect .text[PR]
	.align 2
	.weak	_ZN1AC2Ev[DS]
	.weak	._ZN1AC2Ev
	.csect _ZN1AC2Ev[DS]
_ZN1AC2Ev:
	.long ._ZN1AC2Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1AC2Ev:
LFB..3:
	stw 31,-4(1)
	stwu 1,-32(1)
LCFI..3:
	mr 31,1
LCFI..4:
	stw 3,56(31)
	lwz 9,56(31)
	lwz 10,LC..0(2)
	stw 10,0(9)
	addi 1,31,32
LCFI..5:
	lwz 31,-4(1)
	blr
LT.._ZN1AC2Ev:
	.long 0
	.byte 0,9,32,96,128,1,1,1
	.long 0
	.long LT.._ZN1AC2Ev-._ZN1AC2Ev
	.short 9
	.byte "_ZN1AC2Ev"
	.byte 31
	.align 2
LFE..3:
	.lglobl	._ZN1AC2Ev.localalias.3
	.lglobl	_ZN1AC2Ev.localalias.3
	.set	._ZN1AC2Ev.localalias.3,._ZN1AC2Ev
	.set _ZN1AC2Ev.localalias.3,_ZN1AC2Ev
	.toc
LC..1:
	.tc b[TC],b
	.csect .text[PR]
	.align 2
	.weak	_ZN1BC2Ev[DS]
	.weak	._ZN1BC2Ev
	.csect _ZN1BC2Ev[DS]
_ZN1BC2Ev:
	.long ._ZN1BC2Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1BC2Ev:
LFB..5:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..6:
	mr 31,1
LCFI..7:
	stw 3,88(31)
	stw 4,92(31)
	lwz 9,92(31)
	lwz 10,0(9)
	lwz 9,88(31)
	stw 10,0(9)
	lwz 9,88(31)
	lwz 9,0(9)
	addi 9,9,-16
	lwz 9,0(9)
	mr 10,9
	lwz 9,88(31)
	add 9,9,10
	lwz 10,92(31)
	lwz 10,4(10)
	stw 10,0(9)
	lwz 9,LC..1(2)
	lwz 10,88(31)
	stw 10,0(9)
	lwz 9,88(31)
	lwz 9,0(9)
	addi 9,9,-16
	lwz 9,0(9)
	mr 10,9
	lwz 9,88(31)
	add 9,9,10
	lwz 9,0(9)
	lwz 9,0(9)
	lwz 10,88(31)
	lwz 10,0(10)
	addi 10,10,-16
	lwz 10,0(10)
	mr 8,10
	lwz 10,88(31)
	add 10,10,8
	mr 3,10
	stw 2,20(1)
	lwz 10,0(9)
	lwz 11,8(9)
	mtctr 10
	lwz 2,4(9)
	bctrl
	lwz 2,20(1)
	addi 1,31,64
LCFI..8:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1BC2Ev:
	.long 0
	.byte 0,9,32,97,128,1,2,1
	.long 0
	.long LT.._ZN1BC2Ev-._ZN1BC2Ev
	.short 9
	.byte "_ZN1BC2Ev"
	.byte 31
	.align 2
LFE..5:
	.lglobl	._ZN1BC2Ev.localalias.2
	.lglobl	_ZN1BC2Ev.localalias.2
	.set	._ZN1BC2Ev.localalias.2,._ZN1BC2Ev
	.set _ZN1BC2Ev.localalias.2,_ZN1BC2Ev
	.toc
	.set LC..2,LC..1
	.csect .text[PR]
	.align 2
	.weak	_ZN1B1fEv[DS]
	.weak	._ZN1B1fEv
	.csect _ZN1B1fEv[DS]
_ZN1B1fEv:
	.long ._ZN1B1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZN1B1fEv:
LFB..7:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..9:
	mr 31,1
LCFI..10:
	stw 3,88(31)
	lwz 9,LC..2(2)
	lwz 9,0(9)
	lwz 10,88(31)
	cmpw 7,10,9
	beq 7,L..4
	bl .abort
	nop
L..4:
	addi 1,31,64
LCFI..11:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1B1fEv:
	.long 0
	.byte 0,9,32,97,128,1,1,1
	.long 0
	.long LT.._ZN1B1fEv-._ZN1B1fEv
	.short 9
	.byte "_ZN1B1fEv"
	.byte 31
	.align 2
LFE..7:
	.lglobl	.LTHUNK..0
	.lglobl	LTHUNK..0
	.set	.LTHUNK..0,._ZN1B1fEv
	.set LTHUNK..0,_ZN1B1fEv
	.align 2
	.weak	_ZTv0_n12_N1B1fEv[DS]
	.weak	._ZTv0_n12_N1B1fEv
	.csect _ZTv0_n12_N1B1fEv[DS]
_ZTv0_n12_N1B1fEv:
	.long ._ZTv0_n12_N1B1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZTv0_n12_N1B1fEv:
LFB..16:
	lwz 12,0(3)
	lwz 12,-12(12)
	add 3,3,12
	b .LTHUNK..0
	.lglobl	._ZTv0_n12_N1B1fEv.localalias.5
	.lglobl	_ZTv0_n12_N1B1fEv.localalias.5
	.set	._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
	.set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
LFE..16:
	.align 2
	.weak	_ZN1D1fEv[DS]
	.weak	._ZN1D1fEv
	.csect _ZN1D1fEv[DS]
_ZN1D1fEv:
	.long ._ZN1D1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZN1D1fEv:
LFB..8:
	stw 31,-4(1)
	stwu 1,-32(1)
LCFI..12:
	mr 31,1
LCFI..13:
	stw 3,56(31)
	addi 1,31,32
LCFI..14:
	lwz 31,-4(1)
	blr
LT.._ZN1D1fEv:
	.long 0
	.byte 0,9,32,96,128,1,1,1
	.long 0
	.long LT.._ZN1D1fEv-._ZN1D1fEv
	.short 9
	.byte "_ZN1D1fEv"
	.byte 31
	.align 2
LFE..8:
	.lglobl	.LTHUNK..2
	.lglobl	LTHUNK..2
	.set	.LTHUNK..2,._ZN1D1fEv
	.set LTHUNK..2,_ZN1D1fEv
	.lglobl	._ZThn4_N1D1fEv.localalias.10
	.lglobl	_ZThn4_N1D1fEv.localalias.10
	.set	._ZThn4_N1D1fEv.localalias.10,._ZThn4_N1D1fEv
	.set _ZThn4_N1D1fEv.localalias.10,_ZThn4_N1D1fEv
	.align 2
	.weak	_ZThn4_N1D1fEv[DS]
	.weak	._ZThn4_N1D1fEv
	.csect _ZThn4_N1D1fEv[DS]
_ZThn4_N1D1fEv:
	.long ._ZThn4_N1D1fEv, TOC[tc0], 0
	.csect .text[PR]
._ZThn4_N1D1fEv:
LFB..17:
	addi 3,3,-4
	b .LTHUNK..2
LFE..17:
	.align 2
	.weak	_ZN1CC2Ev[DS]
	.weak	._ZN1CC2Ev
	.csect _ZN1CC2Ev[DS]
_ZN1CC2Ev:
	.long ._ZN1CC2Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1CC2Ev:
LFB..12:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..15:
	mr 31,1
LCFI..16:
	stw 3,88(31)
	stw 4,92(31)
	lwz 10,88(31)
	lwz 9,92(31)
	addi 9,9,4
	mr 4,9
	mr 3,10
	bl ._ZN1BC2Ev.localalias.2
	lwz 9,92(31)
	lwz 10,0(9)
	lwz 9,88(31)
	stw 10,0(9)
	lwz 9,88(31)
	lwz 9,0(9)
	addi 9,9,-16
	lwz 9,0(9)
	mr 10,9
	lwz 9,88(31)
	add 9,9,10
	lwz 10,92(31)
	lwz 10,12(10)
	stw 10,0(9)
	addi 1,31,64
LCFI..17:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1CC2Ev:
	.long 0
	.byte 0,9,32,97,128,1,2,1
	.long 0
	.long LT.._ZN1CC2Ev-._ZN1CC2Ev
	.short 9
	.byte "_ZN1CC2Ev"
	.byte 31
	.align 2
LFE..12:
	.lglobl	._ZN1CC2Ev.localalias.1
	.lglobl	_ZN1CC2Ev.localalias.1
	.set	._ZN1CC2Ev.localalias.1,._ZN1CC2Ev
	.set _ZN1CC2Ev.localalias.1,_ZN1CC2Ev
	.toc
LC..3:
	.tc _ZTT1D.P4[TC],_ZTT1D+4
LC..4:
	.tc _ZTT1D.P20[TC],_ZTT1D+20
LC..5:
	.tc _ZTV1D.P16[TC],_ZTV1D+16
LC..6:
	.tc _ZTV1D.P36[TC],_ZTV1D+36
	.csect .text[PR]
	.align 2
	.weak	_ZN1DC1Ev[DS]
	.weak	._ZN1DC1Ev
	.csect _ZN1DC1Ev[DS]
_ZN1DC1Ev:
	.long ._ZN1DC1Ev, TOC[tc0], 0
	.csect .text[PR]
._ZN1DC1Ev:
LFB..15:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-64(1)
LCFI..18:
	mr 31,1
LCFI..19:
	stw 3,88(31)
	lwz 9,88(31)
	mr 3,9
	bl ._ZN1AC2Ev.localalias.3
	lwz 9,88(31)
	lwz 10,LC..3(2)
	mr 4,10
	mr 3,9
	bl ._ZN1CC2Ev.localalias.1
	lwz 9,88(31)
	addi 9,9,4
	lwz 10,LC..4(2)
	mr 4,10
	mr 3,9
	bl ._ZN1BC2Ev.localalias.2
	lwz 10,LC..5(2)
	lwz 9,88(31)
	stw 10,0(9)
	li 9,0
	lwz 10,88(31)
	add 9,10,9
	lwz 10,LC..5(2)
	stw 10,0(9)
	lwz 10,LC..6(2)
	lwz 9,88(31)
	stw 10,4(9)
	addi 1,31,64
LCFI..20:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT.._ZN1DC1Ev:
	.long 0
	.byte 0,9,32,97,128,1,1,1
	.long 0
	.long LT.._ZN1DC1Ev-._ZN1DC1Ev
	.short 9
	.byte "_ZN1DC1Ev"
	.byte 31
	.align 2
LFE..15:
	.lglobl	._ZN1DC1Ev.localalias.0
	.lglobl	_ZN1DC1Ev.localalias.0
	.set	._ZN1DC1Ev.localalias.0,._ZN1DC1Ev
	.set _ZN1DC1Ev.localalias.0,_ZN1DC1Ev
	.align 2
	.globl main
	.globl .main
	.csect main[DS]
main:
	.long .main, TOC[tc0], 0
	.csect .text[PR]
.main:
LFB..9:
	mflr 0
	stw 0,8(1)
	stw 31,-4(1)
	stwu 1,-96(1)
LCFI..21:
	mr 31,1
LCFI..22:
	addi 9,31,56
	mr 3,9
	bl ._ZN1DC1Ev.localalias.0
	li 9,0
	mr 3,9
	addi 1,31,96
LCFI..23:
	lwz 0,8(1)
	mtlr 0
	lwz 31,-4(1)
	blr
LT..main:
	.long 0
	.byte 0,9,32,97,128,1,0,1
	.long LT..main-.main
	.short 4
	.byte "main"
	.byte 31
	.align 2
LFE..9:
	.weak	_ZTV1D
	.csect .data[RW],4
	.align 2
_ZTV1D:
	.long	0
	.long	0
	.long	0
	.long	_ZTI1D
	.long	LTHUNK..0
	.long	-4
	.long	-4
	.long	-4
	.long	_ZTI1D
	.long	_ZThn4_N1D1fEv.localalias.10
	.set _ZTV1D.localalias.6,_ZTV1D
	.weak	_ZTT1D
	.align 2
_ZTT1D:
	.long	_ZTV1D.localalias.6+16
	.long	_ZTC1D0_1C+16
	.long	_ZTC1D0_1B+16
	.long	_ZTC1D0_1B+16
	.long	_ZTC1D0_1C+16
	.long	_ZTC1D4_1B+16
	.long	_ZTC1D4_1B+32
	.long	_ZTV1D.localalias.6+16
	.long	_ZTV1D.localalias.6+36
	.weak	_ZTC1D0_1C
	.align 2
_ZTC1D0_1C:
	.long	0
	.long	0
	.long	0
	.long	_ZTI1C
	.long	LTHUNK..0
	.weak	_ZTC1D0_1B
	.align 2
_ZTC1D0_1B:
	.long	0
	.long	0
	.long	0
	.long	_ZTI1B
	.long	LTHUNK..0
	.weak	_ZTC1D4_1B
	.align 2
_ZTC1D4_1B:
	.long	-4
	.long	0
	.long	0
	.long	_ZTI1B
	.long	LTHUNK..0
	.long	4
	.long	4
	.long	_ZTI1B
	.long	_ZTv0_n12_N1B1fEv.localalias.5
	.weak	_ZTV1A
	.align 2
_ZTV1A:
	.long	0
	.long	_ZTI1A
	.long	_ZN1A1fEv.localalias.4
	.weak	_ZTI1D
	.align 2
_ZTI1D:
	.long	_ZTVN10__cxxabiv121__vmi_class_type_infoE+8
	.long	_ZTS1D
	.long	3
	.long	2
	.long	_ZTI1C
	.long	2
	.long	_ZTI1B
	.long	1026
	.weak	_ZTS1D
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1D:
	.byte "1D"
	.byte 0
	.weak	_ZTI1C
	.csect .data[RW],4
	.align 2
_ZTI1C:
	.long	_ZTVN10__cxxabiv120__si_class_type_infoE+8
	.long	_ZTS1C
	.long	_ZTI1B
	.weak	_ZTS1C
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1C:
	.byte "1C"
	.byte 0
	.weak	_ZTI1B
	.csect .data[RW],4
	.align 2
_ZTI1B:
	.long	_ZTVN10__cxxabiv121__vmi_class_type_infoE+8
	.long	_ZTS1B
	.long	0
	.long	1
	.long	_ZTI1A
	.long	-4093
	.weak	_ZTS1B
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1B:
	.byte "1B"
	.byte 0
	.weak	_ZTI1A
	.csect .data[RW],4
	.align 2
_ZTI1A:
	.long	_ZTVN10__cxxabiv117__class_type_infoE+8
	.long	_ZTS1A
	.weak	_ZTS1A
	.csect _vcall1.ro_[RO],4
	.align 2
_ZTS1A:
	.byte "1A"
	.byte 0
	.csect .data[RW],4
	.align 2
	.globl _GLOBAL__F_b
_GLOBAL__F_b:
Lframe..1:
	.vbyte	4,LECIE..1-LSCIE..1
LSCIE..1:
	.vbyte	4,0
	.byte	0x3
	.byte 0
	.byte	0x1
	.byte	0x7c
	.byte	0x41
	.byte	0xc
	.byte	0x1
	.byte	0
	.align 2
LECIE..1:
LSFDE..1:
	.vbyte	4,LEFDE..1-LASFDE..1
LASFDE..1:
	.vbyte	4,LASFDE..1-Lframe..1
	.vbyte	4,LFB..5
	.vbyte	4,LFE..5-LFB..5
	.byte	0x4
	.vbyte	4,LCFI..6-LFB..5
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..7-LCFI..6
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..8-LCFI..7
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..1:
LSFDE..3:
	.vbyte	4,LEFDE..3-LASFDE..3
LASFDE..3:
	.vbyte	4,LASFDE..3-Lframe..1
	.vbyte	4,LFB..7
	.vbyte	4,LFE..7-LFB..7
	.byte	0x4
	.vbyte	4,LCFI..9-LFB..7
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..10-LCFI..9
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..11-LCFI..10
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..3:
LSFDE..5:
	.vbyte	4,LEFDE..5-LASFDE..5
LASFDE..5:
	.vbyte	4,LASFDE..5-Lframe..1
	.vbyte	4,LFB..16
	.vbyte	4,LFE..16-LFB..16
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..5:
LSFDE..7:
	.vbyte	4,LEFDE..7-LASFDE..7
LASFDE..7:
	.vbyte	4,LASFDE..7-Lframe..1
	.vbyte	4,LFB..17
	.vbyte	4,LFE..17-LFB..17
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..7:
LSFDE..9:
	.vbyte	4,LEFDE..9-LASFDE..9
LASFDE..9:
	.vbyte	4,LASFDE..9-Lframe..1
	.vbyte	4,LFB..12
	.vbyte	4,LFE..12-LFB..12
	.byte	0x4
	.vbyte	4,LCFI..15-LFB..12
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..16-LCFI..15
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..17-LCFI..16
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..9:
LSFDE..11:
	.vbyte	4,LEFDE..11-LASFDE..11
LASFDE..11:
	.vbyte	4,LASFDE..11-Lframe..1
	.vbyte	4,LFB..15
	.vbyte	4,LFE..15-LFB..15
	.byte	0x4
	.vbyte	4,LCFI..18-LFB..15
	.byte	0xe
	.byte	0x40
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..19-LCFI..18
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..20-LCFI..19
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..11:
LSFDE..13:
	.vbyte	4,LEFDE..13-LASFDE..13
LASFDE..13:
	.vbyte	4,LASFDE..13-Lframe..1
	.vbyte	4,LFB..9
	.vbyte	4,LFE..9-LFB..9
	.byte	0x4
	.vbyte	4,LCFI..21-LFB..9
	.byte	0xe
	.byte	0x60
	.byte	0x11
	.byte	0x41
	.byte	0x7e
	.byte	0x9f
	.byte	0x1
	.byte	0x4
	.vbyte	4,LCFI..22-LCFI..21
	.byte	0xd
	.byte	0x1f
	.byte	0x4
	.vbyte	4,LCFI..23-LCFI..22
	.byte	0xc
	.byte	0x1
	.byte	0
	.csect .text[PR]
	.ref Lframe..1
	.csect .data[RW],4
	.align 2
LEFDE..13:
	.vbyte	4,0
	.csect .text[PR]
_section_.text:
	.csect .data[RW],4
	.long _section_.text

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

* Re: ipa-visibility TLC 2/n
  2014-05-30 17:24             ` David Edelsohn
  2014-05-30 21:02               ` Jan Hubicka
@ 2014-06-03 13:53               ` David Edelsohn
  2014-06-06  7:10                 ` Jan Hubicka
  1 sibling, 1 reply; 44+ messages in thread
From: David Edelsohn @ 2014-06-03 13:53 UTC (permalink / raw)
  To: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

Honza,

How can we make further progress with the large regression on AIX?

Thanks, David

On Fri, May 30, 2014 at 1:24 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> Honza,
>
> For example g++.dg/abi/vcall1.C fails at a call in a "localalias"
> function, which jumps to a bad location:
>
>
> (gdb) up
> #1  0x100004c0 in B::B() [clone .localalias.2] ()
> (gdb) x/16i $pc-32
>    0x100004a0 <_ZN1BC2Ev+156>:  add     r10,r10,r8
>    0x100004a4 <_ZN1BC2Ev+160>:  mr      r3,r10
>    0x100004a8 <_ZN1BC2Ev+164>:  stw     r2,20(r1)
>    0x100004ac <_ZN1BC2Ev+168>:  lwz     r10,0(r9)
>    0x100004b0 <_ZN1BC2Ev+172>:  lwz     r11,8(r9)
>    0x100004b4 <_ZN1BC2Ev+176>:  mtctr   r10
>    0x100004b8 <_ZN1BC2Ev.localalias.2+180>:     lwz     r2,4(r9)
>    0x100004bc <_ZN1BC2Ev.localalias.2+184>:     bctrl
> => 0x100004c0 <_ZN1BC2Ev.localalias.2+188>:     lwz     r2,20(r1)
>    0x100004c4 <_ZN1BC2Ev.localalias.2+192>:     addi    r1,r31,64
>    0x100004c8 <_ZN1BC2Ev.localalias.2+196>:     lwz     r0,8(r1)
>    0x100004cc <_ZN1BC2Ev.localalias.2+200>:     mtlr    r0
>    0x100004d0 <_ZN1BC2Ev.localalias.2+204>:     lwz     r31,-4(r1)
>    0x100004d4 <_ZN1BC2Ev.localalias.2+208>:     blr
>
>
>
> On Fri, May 30, 2014 at 3:20 AM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> Jan Hubicka <hubicka@ucw.cz> writes:
>>>> Jan Hubicka <hubicka@ucw.cz> writes:
>>>> >> Richard Sandiford wrote the original section anchors implementation,
>>>> >> so he would be a good person to comment about the interaction between
>>>> >> aliases and section anchors.
>>>> >
>>>> > Thanks! Richard, does this patch seem sane?
>>>>
>>>> Looks good to me in principle, but with:
>>>>
>>>> > +      struct symtab_node *snode;
>>>> >        decl = SYMBOL_REF_DECL (symbol);
>>>> > +
>>>> > +      snode = symtab_node (decl);
>>>> > +      if (snode->alias)
>>>> > +       {
>>>> > + rtx target = DECL_RTL (symtab_alias_ultimate_target
>>>> > (snode)->decl);
>>>> > + SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET
>>>> > (target);
>>>> > +         return;
>>>> > +       }
>>>>
>>>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
>>>> It looked at face value like you'd need a recursive call to place_block_symbol
>>>> on the target before the copy.
>>>
>>> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
>>> calculation time. But you are right - it is done by validize_mem that
>>> is not done by DECL_RTL.  Shall I just call it on target first?
>>
>> Yeah, sounds like calling place_block_symbol would be safer.
>>
>> IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
>> tended to create placeholder decls that for whatever reason ended up with
>> an initial DECL_RTL, then changed the properties of the decl later once
>> more information was known.  (This was all many years ago.)
>>
>> Thanks,
>> Richard

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

* Re: ipa-visibility TLC 2/n
  2014-05-31  7:42                   ` Richard Sandiford
@ 2014-05-31 14:43                     ` David Edelsohn
  0 siblings, 0 replies; 44+ messages in thread
From: David Edelsohn @ 2014-05-31 14:43 UTC (permalink / raw)
  To: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

This leads to bootstrap errors like:

In file included from
/tmp/20140531/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/backward/strstream:54:0,
                 from
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++98/strstream.cc:44:
/tmp/20140531/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/istream: In
constructor 'std::istrstream::istrstream(char*)':
/tmp/20140531/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/istream:94:32:
internal compiler error: in place_block_symbol, at varasm.c:7067
       : _M_gcount(streamsize(0))
                                ^

On Sat, May 31, 2014 at 3:42 AM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> David Edelsohn <dje.gcc@gmail.com> writes:
>> Honza,
>>
>> With the patch, I cannot bootstrap.
>
> I think it was meant to be:
>
>           place_block_symbol (target);
>
> rather than:
>
>           place_block_symbol (symbol);
>
> I.e. we need to place "target" before copying its offset.
>
> Thanks,
> Richard

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

* Re: ipa-visibility TLC 2/n
  2014-05-31  0:57                 ` David Edelsohn
@ 2014-05-31  7:42                   ` Richard Sandiford
  2014-05-31 14:43                     ` David Edelsohn
  0 siblings, 1 reply; 44+ messages in thread
From: Richard Sandiford @ 2014-05-31  7:42 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01

David Edelsohn <dje.gcc@gmail.com> writes:
> Honza,
>
> With the patch, I cannot bootstrap.

I think it was meant to be:

	  place_block_symbol (target);

rather than:

	  place_block_symbol (symbol);

I.e. we need to place "target" before copying its offset.

Thanks,
Richard

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

* Re: ipa-visibility TLC 2/n
  2014-05-30 21:02               ` Jan Hubicka
@ 2014-05-31  0:57                 ` David Edelsohn
  2014-05-31  7:42                   ` Richard Sandiford
  0 siblings, 1 reply; 44+ messages in thread
From: David Edelsohn @ 2014-05-31  0:57 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

Honza,

With the patch, I cannot bootstrap.

I am concerned about the much greater frequency of AIX linker warnings
about branch not followed by no-op after your patch.

GCC may bootstrap only because it links libstdc++ statically. If your
patch is too aggressive in its effort to remove PLT calls, it may be
breaking shared library support on AIX. Previously there were a few
recursive libstdc++ calls that binds_local_p() asserted were bound
locally to functions declared global.  I hope that cross-module calls
have not been incorrectly analyzed as local.

Thanks, David


On Fri, May 30, 2014 at 5:02 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> Honza,
>>
>> For example g++.dg/abi/vcall1.C fails at a call in a "localalias"
>> function, which jumps to a bad location:
>>
>>
>> (gdb) up
>> #1  0x100004c0 in B::B() [clone .localalias.2] ()
>> (gdb) x/16i $pc-32
>>    0x100004a0 <_ZN1BC2Ev+156>:  add     r10,r10,r8
>>    0x100004a4 <_ZN1BC2Ev+160>:  mr      r3,r10
>>    0x100004a8 <_ZN1BC2Ev+164>:  stw     r2,20(r1)
>>    0x100004ac <_ZN1BC2Ev+168>:  lwz     r10,0(r9)
>>    0x100004b0 <_ZN1BC2Ev+172>:  lwz     r11,8(r9)
>>    0x100004b4 <_ZN1BC2Ev+176>:  mtctr   r10
>>    0x100004b8 <_ZN1BC2Ev.localalias.2+180>:     lwz     r2,4(r9)
>>    0x100004bc <_ZN1BC2Ev.localalias.2+184>:     bctrl
>> => 0x100004c0 <_ZN1BC2Ev.localalias.2+188>:     lwz     r2,20(r1)
>>    0x100004c4 <_ZN1BC2Ev.localalias.2+192>:     addi    r1,r31,64
>>    0x100004c8 <_ZN1BC2Ev.localalias.2+196>:     lwz     r0,8(r1)
>>    0x100004cc <_ZN1BC2Ev.localalias.2+200>:     mtlr    r0
>>    0x100004d0 <_ZN1BC2Ev.localalias.2+204>:     lwz     r31,-4(r1)
>>    0x100004d4 <_ZN1BC2Ev.localalias.2+208>:     blr
>
> I suppose this is the problem Richard mentioned - the offsets are not computed
> by DECL_RTL callback but by place_block.
>
>> >>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
>> >>> It looked at face value like you'd need a recursive call to place_block_symbol
>> >>> on the target before the copy.
>> >>
>> >> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
>> >> calculation time. But you are right - it is done by validize_mem that
>> >> is not done by DECL_RTL.  Shall I just call it on target first?
>> >
>> > Yeah, sounds like calling place_block_symbol would be safer.
>
> I will test:
> Index: varasm.c
> ===================================================================
> --- varasm.c    (revision 211096)
> +++ varasm.c    (working copy)
> @@ -7094,6 +7094,7 @@
>        if (snode->alias)
>         {
>           rtx target = DECL_RTL (symtab_alias_ultimate_target (snode)->decl);
> +         place_block_symbol (symbol);
>           SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
>           return;
>         }
>
>
> Honza
>> >
>> > IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
>> > tended to create placeholder decls that for whatever reason ended up with
>> > an initial DECL_RTL, then changed the properties of the decl later once
>> > more information was known.  (This was all many years ago.)
>> >
>> > Thanks,
>> > Richard

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

* Re: ipa-visibility TLC 2/n
  2014-05-30 17:24             ` David Edelsohn
@ 2014-05-30 21:02               ` Jan Hubicka
  2014-05-31  0:57                 ` David Edelsohn
  2014-06-03 13:53               ` David Edelsohn
  1 sibling, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-05-30 21:02 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

> Honza,
> 
> For example g++.dg/abi/vcall1.C fails at a call in a "localalias"
> function, which jumps to a bad location:
> 
> 
> (gdb) up
> #1  0x100004c0 in B::B() [clone .localalias.2] ()
> (gdb) x/16i $pc-32
>    0x100004a0 <_ZN1BC2Ev+156>:  add     r10,r10,r8
>    0x100004a4 <_ZN1BC2Ev+160>:  mr      r3,r10
>    0x100004a8 <_ZN1BC2Ev+164>:  stw     r2,20(r1)
>    0x100004ac <_ZN1BC2Ev+168>:  lwz     r10,0(r9)
>    0x100004b0 <_ZN1BC2Ev+172>:  lwz     r11,8(r9)
>    0x100004b4 <_ZN1BC2Ev+176>:  mtctr   r10
>    0x100004b8 <_ZN1BC2Ev.localalias.2+180>:     lwz     r2,4(r9)
>    0x100004bc <_ZN1BC2Ev.localalias.2+184>:     bctrl
> => 0x100004c0 <_ZN1BC2Ev.localalias.2+188>:     lwz     r2,20(r1)
>    0x100004c4 <_ZN1BC2Ev.localalias.2+192>:     addi    r1,r31,64
>    0x100004c8 <_ZN1BC2Ev.localalias.2+196>:     lwz     r0,8(r1)
>    0x100004cc <_ZN1BC2Ev.localalias.2+200>:     mtlr    r0
>    0x100004d0 <_ZN1BC2Ev.localalias.2+204>:     lwz     r31,-4(r1)
>    0x100004d4 <_ZN1BC2Ev.localalias.2+208>:     blr

I suppose this is the problem Richard mentioned - the offsets are not computed
by DECL_RTL callback but by place_block. 

> >>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
> >>> It looked at face value like you'd need a recursive call to place_block_symbol
> >>> on the target before the copy.
> >>
> >> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
> >> calculation time. But you are right - it is done by validize_mem that
> >> is not done by DECL_RTL.  Shall I just call it on target first?
> >
> > Yeah, sounds like calling place_block_symbol would be safer.

I will test:
Index: varasm.c
===================================================================
--- varasm.c    (revision 211096)
+++ varasm.c    (working copy)
@@ -7094,6 +7094,7 @@
       if (snode->alias)
        {
          rtx target = DECL_RTL (symtab_alias_ultimate_target (snode)->decl);
+         place_block_symbol (symbol);
          SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
          return;
        }


Honza
> >
> > IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
> > tended to create placeholder decls that for whatever reason ended up with
> > an initial DECL_RTL, then changed the properties of the decl later once
> > more information was known.  (This was all many years ago.)
> >
> > Thanks,
> > Richard

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

* Re: ipa-visibility TLC 2/n
  2014-05-30  7:20           ` Richard Sandiford
  2014-05-30 15:50             ` David Edelsohn
@ 2014-05-30 17:24             ` David Edelsohn
  2014-05-30 21:02               ` Jan Hubicka
  2014-06-03 13:53               ` David Edelsohn
  1 sibling, 2 replies; 44+ messages in thread
From: David Edelsohn @ 2014-05-30 17:24 UTC (permalink / raw)
  To: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

Honza,

For example g++.dg/abi/vcall1.C fails at a call in a "localalias"
function, which jumps to a bad location:


(gdb) up
#1  0x100004c0 in B::B() [clone .localalias.2] ()
(gdb) x/16i $pc-32
   0x100004a0 <_ZN1BC2Ev+156>:  add     r10,r10,r8
   0x100004a4 <_ZN1BC2Ev+160>:  mr      r3,r10
   0x100004a8 <_ZN1BC2Ev+164>:  stw     r2,20(r1)
   0x100004ac <_ZN1BC2Ev+168>:  lwz     r10,0(r9)
   0x100004b0 <_ZN1BC2Ev+172>:  lwz     r11,8(r9)
   0x100004b4 <_ZN1BC2Ev+176>:  mtctr   r10
   0x100004b8 <_ZN1BC2Ev.localalias.2+180>:     lwz     r2,4(r9)
   0x100004bc <_ZN1BC2Ev.localalias.2+184>:     bctrl
=> 0x100004c0 <_ZN1BC2Ev.localalias.2+188>:     lwz     r2,20(r1)
   0x100004c4 <_ZN1BC2Ev.localalias.2+192>:     addi    r1,r31,64
   0x100004c8 <_ZN1BC2Ev.localalias.2+196>:     lwz     r0,8(r1)
   0x100004cc <_ZN1BC2Ev.localalias.2+200>:     mtlr    r0
   0x100004d0 <_ZN1BC2Ev.localalias.2+204>:     lwz     r31,-4(r1)
   0x100004d4 <_ZN1BC2Ev.localalias.2+208>:     blr



On Fri, May 30, 2014 at 3:20 AM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Jan Hubicka <hubicka@ucw.cz> writes:
>>> Jan Hubicka <hubicka@ucw.cz> writes:
>>> >> Richard Sandiford wrote the original section anchors implementation,
>>> >> so he would be a good person to comment about the interaction between
>>> >> aliases and section anchors.
>>> >
>>> > Thanks! Richard, does this patch seem sane?
>>>
>>> Looks good to me in principle, but with:
>>>
>>> > +      struct symtab_node *snode;
>>> >        decl = SYMBOL_REF_DECL (symbol);
>>> > +
>>> > +      snode = symtab_node (decl);
>>> > +      if (snode->alias)
>>> > +       {
>>> > + rtx target = DECL_RTL (symtab_alias_ultimate_target
>>> > (snode)->decl);
>>> > + SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET
>>> > (target);
>>> > +         return;
>>> > +       }
>>>
>>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
>>> It looked at face value like you'd need a recursive call to place_block_symbol
>>> on the target before the copy.
>>
>> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
>> calculation time. But you are right - it is done by validize_mem that
>> is not done by DECL_RTL.  Shall I just call it on target first?
>
> Yeah, sounds like calling place_block_symbol would be safer.
>
> IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
> tended to create placeholder decls that for whatever reason ended up with
> an initial DECL_RTL, then changed the properties of the decl later once
> more information was known.  (This was all many years ago.)
>
> Thanks,
> Richard

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

* Re: ipa-visibility TLC 2/n
  2014-05-30  7:20           ` Richard Sandiford
@ 2014-05-30 15:50             ` David Edelsohn
  2014-06-08 16:44               ` Jan Hubicka
                                 ` (2 more replies)
  2014-05-30 17:24             ` David Edelsohn
  1 sibling, 3 replies; 44+ messages in thread
From: David Edelsohn @ 2014-05-30 15:50 UTC (permalink / raw)
  To: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01, Richard Sandiford

Honza,

I finally was able to bootstrap GCC on AIX yesterday. The bootstrap
works, but the testsuite results are in extremely bad shape: 250
failures in G++ testsuite and 470 failures in libstdc++ testsuite.

G++ previously had about 65 failures, mainly TLS and init. libstdc++
previously hovered around 12-14 failure.

This is unacceptable breakage and fallout from the recent changes.

- David

On Fri, May 30, 2014 at 3:20 AM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Jan Hubicka <hubicka@ucw.cz> writes:
>>> Jan Hubicka <hubicka@ucw.cz> writes:
>>> >> Richard Sandiford wrote the original section anchors implementation,
>>> >> so he would be a good person to comment about the interaction between
>>> >> aliases and section anchors.
>>> >
>>> > Thanks! Richard, does this patch seem sane?
>>>
>>> Looks good to me in principle, but with:
>>>
>>> > +      struct symtab_node *snode;
>>> >        decl = SYMBOL_REF_DECL (symbol);
>>> > +
>>> > +      snode = symtab_node (decl);
>>> > +      if (snode->alias)
>>> > +       {
>>> > + rtx target = DECL_RTL (symtab_alias_ultimate_target
>>> > (snode)->decl);
>>> > + SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET
>>> > (target);
>>> > +         return;
>>> > +       }
>>>
>>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
>>> It looked at face value like you'd need a recursive call to place_block_symbol
>>> on the target before the copy.
>>
>> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
>> calculation time. But you are right - it is done by validize_mem that
>> is not done by DECL_RTL.  Shall I just call it on target first?
>
> Yeah, sounds like calling place_block_symbol would be safer.
>
> IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
> tended to create placeholder decls that for whatever reason ended up with
> an initial DECL_RTL, then changed the properties of the decl later once
> more information was known.  (This was all many years ago.)
>
> Thanks,
> Richard

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

* Re: ipa-visibility TLC 2/n
  2014-05-29 17:12         ` Jan Hubicka
@ 2014-05-30  7:20           ` Richard Sandiford
  2014-05-30 15:50             ` David Edelsohn
  2014-05-30 17:24             ` David Edelsohn
  0 siblings, 2 replies; 44+ messages in thread
From: Richard Sandiford @ 2014-05-30  7:20 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: David Edelsohn, GCC Patches, Richard Henderson, ramrad01

Jan Hubicka <hubicka@ucw.cz> writes:
>> Jan Hubicka <hubicka@ucw.cz> writes:
>> >> Richard Sandiford wrote the original section anchors implementation,
>> >> so he would be a good person to comment about the interaction between
>> >> aliases and section anchors.
>> >
>> > Thanks! Richard, does this patch seem sane?
>> 
>> Looks good to me in principle, but with:
>> 
>> > +      struct symtab_node *snode;
>> >        decl = SYMBOL_REF_DECL (symbol);
>> > +
>> > +      snode = symtab_node (decl);
>> > +      if (snode->alias)
>> > +       {
>> > + rtx target = DECL_RTL (symtab_alias_ultimate_target
>> > (snode)->decl);
>> > + SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET
>> > (target);
>> > +         return;
>> > +       }
>> 
>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
>> It looked at face value like you'd need a recursive call to place_block_symbol
>> on the target before the copy.
>
> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
> calculation time. But you are right - it is done by validize_mem that
> is not done by DECL_RTL.  Shall I just call it on target first?

Yeah, sounds like calling place_block_symbol would be safer.

IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
tended to create placeholder decls that for whatever reason ended up with
an initial DECL_RTL, then changed the properties of the decl later once
more information was known.  (This was all many years ago.)

Thanks,
Richard

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

* Re: ipa-visibility TLC 2/n
  2014-05-29  8:08       ` Richard Sandiford
@ 2014-05-29 17:12         ` Jan Hubicka
  2014-05-30  7:20           ` Richard Sandiford
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-05-29 17:12 UTC (permalink / raw)
  To: Jan Hubicka, David Edelsohn, GCC Patches, Richard Henderson,
	ramrad01, rdsandiford

> Jan Hubicka <hubicka@ucw.cz> writes:
> >> Richard Sandiford wrote the original section anchors implementation,
> >> so he would be a good person to comment about the interaction between
> >> aliases and section anchors.
> >
> > Thanks! Richard, does this patch seem sane?
> 
> Looks good to me in principle, but with:
> 
> > +      struct symtab_node *snode;
> >        decl = SYMBOL_REF_DECL (symbol);
> > +
> > +      snode = symtab_node (decl);
> > +      if (snode->alias)
> > +       {
> > +         rtx target = DECL_RTL (symtab_alias_ultimate_target (snode)->decl);
> > +         SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
> > +         return;
> > +       }
> 
> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
> It looked at face value like you'd need a recursive call to place_block_symbol
> on the target before the copy.

My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL calculation
time. But you are right - it is done by validize_mem that is not done by DECL_RTL.
Shall I just call it on target first?

Honza
> 
> Thanks,
> Richard

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

* Re: ipa-visibility TLC 2/n
  2014-05-28 23:17     ` Jan Hubicka
@ 2014-05-29  8:08       ` Richard Sandiford
  2014-05-29 17:12         ` Jan Hubicka
  0 siblings, 1 reply; 44+ messages in thread
From: Richard Sandiford @ 2014-05-29  8:08 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: David Edelsohn, GCC Patches, Richard Henderson, ramrad01

Jan Hubicka <hubicka@ucw.cz> writes:
>> Richard Sandiford wrote the original section anchors implementation,
>> so he would be a good person to comment about the interaction between
>> aliases and section anchors.
>
> Thanks! Richard, does this patch seem sane?

Looks good to me in principle, but with:

> +      struct symtab_node *snode;
>        decl = SYMBOL_REF_DECL (symbol);
> +
> +      snode = symtab_node (decl);
> +      if (snode->alias)
> +       {
> +         rtx target = DECL_RTL (symtab_alias_ultimate_target (snode)->decl);
> +         SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
> +         return;
> +       }

is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
It looked at face value like you'd need a recursive call to place_block_symbol
on the target before the copy.

Thanks,
Richard

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

* Re: ipa-visibility TLC 2/n
  2014-05-28 22:44   ` David Edelsohn
@ 2014-05-28 23:17     ` Jan Hubicka
  2014-05-29  8:08       ` Richard Sandiford
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-05-28 23:17 UTC (permalink / raw)
  To: David Edelsohn
  Cc: Jan Hubicka, Richard Sandiford, GCC Patches, Richard Henderson, ramrad01

> Richard Sandiford wrote the original section anchors implementation,
> so he would be a good person to comment about the interaction between
> aliases and section anchors.

Thanks! Richard, does this patch seem sane?  AIX gcc now builds for me, so I
will test it on x86_64-linux it and commit if it passes to unbreak bootstraps.

I think I should incrementally make symtab to believe that all functions/vars
in named sections (and perhaps all COMDAT variables with -fdata-sections and
COMDAT functions with -ffunction-sections, too) can be removed at linktime and
thus disable the creation of the local aliases. This will result with worse
code with -fdata-sections but will make it possible to garbage collect tose
sections

Honza
> 
> Thanks, David

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

* Re: ipa-visibility TLC 2/n
  2014-05-28 22:31 ` Jan Hubicka
@ 2014-05-28 22:44   ` David Edelsohn
  2014-05-28 23:17     ` Jan Hubicka
  0 siblings, 1 reply; 44+ messages in thread
From: David Edelsohn @ 2014-05-28 22:44 UTC (permalink / raw)
  To: Jan Hubicka, Richard Sandiford; +Cc: GCC Patches, Richard Henderson, ramrad01

On Wed, May 28, 2014 at 6:31 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> Honza,
>>
>> I'm glad that you're making progress.
>>
>> > David, this looks like a bug in the AIX target output macros. I get:
>> >         .set _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69,_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
>>
>> > (this is correct since localalias is really an alias)
>>
>> > _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69:
>> >         .space 40
>> > _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si:
>> ...
>>
>> > This is wrong, since we should not try to out the variable at least if I read AIX assembly correctly.
>>
>> > varpool has explicit test to not output any aliases, so perhaps this is a bug in wrapup_globals
>> > and AIX output macros.  I will try to track more after my teaching tonight.
>>
>> The AIX support handles AIX XCOFF assembler syntax and chooses
>> appropriate sections, but it would not choose to emit an extra
>> definition. If there are multiple definitions, then the varasm macros
>> are being invoked multiple times for the same symbol.
>
> I now understand what goes wrong: AIX uses section anchors and the code to
> produce them completely ignore the existence of aliases.  It means that we
> get a variable and alias on a different offsets within the anchor.
>
> I think we need to somehow propagate anchros of objects into anchors of aliases.
> The code goes by:
>
> validize_mem
>   that gets SYMBOL_REF for the alias
>   to
> use_anchored_address
>   to
> place_block_symbol
>
> and place_block adds the alias and allocates space for it.
> I suppose we want to walk to alias target there:
>
> Index: varasm.c
> ===================================================================
> --- varasm.c    (revision 211028)
> +++ varasm.c    (working copy)
> @@ -1083,6 +1083,9 @@
>  {
>    addr_space_t as = ADDR_SPACE_GENERIC;
>    int reloc;
> +  symtab_node *snode = symtab_get_node (decl);
> +  if (snode)
> +    decl = symtab_alias_ultimate_target (snode)->decl;
>
>    if (TREE_TYPE (decl) != error_mark_node)
>      as = TYPE_ADDR_SPACE (TREE_TYPE (decl));
> @@ -7084,7 +7087,16 @@
>      }
>    else
>      {
> +      struct symtab_node *snode;
>        decl = SYMBOL_REF_DECL (symbol);
> +
> +      snode = symtab_node (decl);
> +      if (snode->alias)
> +       {
> +         rtx target = DECL_RTL (symtab_alias_ultimate_target (snode)->decl);
> +         SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
> +         return;
> +       }
>        alignment = get_variable_align (decl);
>        size = tree_to_uhwi (DECL_SIZE_UNIT (decl));
>        if ((flag_sanitize & SANITIZE_ADDRESS)
>
> I am testing if that lets me to finish a bootstrap at gcc111

Richard Sandiford wrote the original section anchors implementation,
so he would be a good person to comment about the interaction between
aliases and section anchors.

Thanks, David

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

* Re: ipa-visibility TLC 2/n
  2014-05-28 21:44 David Edelsohn
@ 2014-05-28 22:31 ` Jan Hubicka
  2014-05-28 22:44   ` David Edelsohn
  0 siblings, 1 reply; 44+ messages in thread
From: Jan Hubicka @ 2014-05-28 22:31 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Jan Hubicka, GCC Patches, Richard Henderson, ramrad01

> Honza,
> 
> I'm glad that you're making progress.
> 
> > David, this looks like a bug in the AIX target output macros. I get:
> >         .set _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69,_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
> 
> > (this is correct since localalias is really an alias)
> 
> > _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69:
> >         .space 40
> > _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si:
> ...
> 
> > This is wrong, since we should not try to out the variable at least if I read AIX assembly correctly.
> 
> > varpool has explicit test to not output any aliases, so perhaps this is a bug in wrapup_globals
> > and AIX output macros.  I will try to track more after my teaching tonight.
> 
> The AIX support handles AIX XCOFF assembler syntax and chooses
> appropriate sections, but it would not choose to emit an extra
> definition. If there are multiple definitions, then the varasm macros
> are being invoked multiple times for the same symbol.

I now understand what goes wrong: AIX uses section anchors and the code to
produce them completely ignore the existence of aliases.  It means that we 
get a variable and alias on a different offsets within the anchor.

I think we need to somehow propagate anchros of objects into anchors of aliases.
The code goes by:

validize_mem
  that gets SYMBOL_REF for the alias
  to
use_anchored_address
  to
place_block_symbol

and place_block adds the alias and allocates space for it.
I suppose we want to walk to alias target there:

Index: varasm.c
===================================================================
--- varasm.c	(revision 211028)
+++ varasm.c	(working copy)
@@ -1083,6 +1083,9 @@
 {
   addr_space_t as = ADDR_SPACE_GENERIC;
   int reloc;
+  symtab_node *snode = symtab_get_node (decl);
+  if (snode)
+    decl = symtab_alias_ultimate_target (snode)->decl;
 
   if (TREE_TYPE (decl) != error_mark_node)
     as = TYPE_ADDR_SPACE (TREE_TYPE (decl));
@@ -7084,7 +7087,16 @@
     }
   else
     {
+      struct symtab_node *snode;
       decl = SYMBOL_REF_DECL (symbol);
+
+      snode = symtab_node (decl);
+      if (snode->alias)
+	{
+	  rtx target = DECL_RTL (symtab_alias_ultimate_target (snode)->decl);
+	  SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
+	  return;
+	}
       alignment = get_variable_align (decl);
       size = tree_to_uhwi (DECL_SIZE_UNIT (decl));
       if ((flag_sanitize & SANITIZE_ADDRESS)

I am testing if that lets me to finish a bootstrap at gcc111

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

* Re: ipa-visibility TLC 2/n
@ 2014-05-28 21:44 David Edelsohn
  2014-05-28 22:31 ` Jan Hubicka
  0 siblings, 1 reply; 44+ messages in thread
From: David Edelsohn @ 2014-05-28 21:44 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: GCC Patches, Richard Henderson, ramrad01

Honza,

I'm glad that you're making progress.

> David, this looks like a bug in the AIX target output macros. I get:
>         .set _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69,_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si

> (this is correct since localalias is really an alias)

> _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69:
>         .space 40
> _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si:
...

> This is wrong, since we should not try to out the variable at least if I read AIX assembly correctly.

> varpool has explicit test to not output any aliases, so perhaps this is a bug in wrapup_globals
> and AIX output macros.  I will try to track more after my teaching tonight.

The AIX support handles AIX XCOFF assembler syntax and chooses
appropriate sections, but it would not choose to emit an extra
definition. If there are multiple definitions, then the varasm macros
are being invoked multiple times for the same symbol.


Thanks, David

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

end of thread, other threads:[~2014-06-13  3:22 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-25  5:54 ipa-visibility TLC 2/n Jan Hubicka
2014-05-25 20:45 ` Ramana Radhakrishnan
2014-05-25 22:23   ` Jan Hubicka
2014-05-26  1:04     ` Jan Hubicka
2014-05-26  5:29       ` Ramana Radhakrishnan
2014-05-27 20:06         ` Jan Hubicka
2014-05-27 22:20           ` Jan Hubicka
2014-05-28 17:39             ` Yufeng Zhang
2014-05-28 19:52               ` Jan Hubicka
2014-05-28 21:56               ` Jan Hubicka
2014-05-29 14:17                 ` Yufeng Zhang
2014-05-30 16:18                   ` Ramana Radhakrishnan
2014-05-26 15:39 ` Martin Liška
2014-05-28 21:44 David Edelsohn
2014-05-28 22:31 ` Jan Hubicka
2014-05-28 22:44   ` David Edelsohn
2014-05-28 23:17     ` Jan Hubicka
2014-05-29  8:08       ` Richard Sandiford
2014-05-29 17:12         ` Jan Hubicka
2014-05-30  7:20           ` Richard Sandiford
2014-05-30 15:50             ` David Edelsohn
2014-06-08 16:44               ` Jan Hubicka
2014-06-10  8:51                 ` Richard Biener
2014-06-08 16:49               ` Jan Hubicka
2014-06-08 16:54               ` Jan Hubicka
2014-06-08 16:58                 ` Jan Hubicka
2014-06-10 13:08                   ` David Edelsohn
2014-06-10 18:02                     ` Jan Hubicka
2014-06-10 22:23                       ` David Edelsohn
2014-06-10 22:55                         ` Jan Hubicka
2014-06-11 14:26                           ` Rainer Orth
2014-06-11 17:02                             ` Jan Hubicka
2014-06-12 10:43                               ` Rainer Orth
2014-06-12 13:33                                 ` Rainer Orth
2014-06-13  3:22                                 ` Jan Hubicka
2014-06-11  8:17                         ` Jan Hubicka
2014-05-30 17:24             ` David Edelsohn
2014-05-30 21:02               ` Jan Hubicka
2014-05-31  0:57                 ` David Edelsohn
2014-05-31  7:42                   ` Richard Sandiford
2014-05-31 14:43                     ` David Edelsohn
2014-06-03 13:53               ` David Edelsohn
2014-06-06  7:10                 ` Jan Hubicka
2014-06-06 15:53                   ` David Edelsohn

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