* 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
* Re: ipa-visibility TLC 2/n 2014-05-28 21:44 ipa-visibility TLC 2/n 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 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 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 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-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-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-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-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-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-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-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-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-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-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-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 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 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-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-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-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-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-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-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 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 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-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-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-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-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-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
* 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 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-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-05-25 5:54 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
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-28 21:44 ipa-visibility TLC 2/n 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 -- strict thread matches above, loose matches on Subject: below -- 2014-05-25 5:54 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
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).