[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2015-06-23 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
Bug 57366 depends on bug 47333, which changed state.

Bug 47333 Summary: [4.8 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with 
SUN as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-09-04 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Jan Hubicka hubicka at gcc dot gnu.org ---
Closing thus.


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-06-03 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE ---
Works fine on i386-pc-solaris2.10 with Sun as.

Thanks.
Rainer


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-06-01 Thread hubicka at ucw dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #14 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
the problems with weakref are bit deeper than I though.  They way RTL rewriting
is done
breaks completely with any symbol renaming that is quite common with LTO.  I am
testing
the following

Index: cgraphunit.c
===
--- cgraphunit.c(revision 199577)
+++ cgraphunit.c(working copy)
@@ -1996,6 +1996,32 @@ compile (void)
   bitmap_obstack_release (NULL);
   mark_functions_to_output ();

+  /* When weakref support is missing, we autmatically translate all
+ references to NODE to references to its ultimate alias target.
+ The renaming mechanizm uses flag IDENTIFIER_TRANSPARENT_ALIAS and
+ TREE_CHAIN.
+
+ Set up this mapping before we output any assembler but once we are sure
+ that all symbol renaming is done.
+
+ FIXME: All this uglyness can go away if we just do renaming at gimple
+ level by physically rewritting the IL.  At the moment we can only
redirect
+ calls, so we need infrastructure for renaming references as well.  */
+#ifndef ASM_OUTPUT_WEAKREF
+  symtab_node node;
+
+  FOR_EACH_SYMBOL (node)
+if (node-symbol.alias
+ lookup_attribute (weakref, DECL_ATTRIBUTES (node-symbol.decl)))
+  {
+IDENTIFIER_TRANSPARENT_ALIAS
+   (DECL_ASSEMBLER_NAME (node-symbol.decl)) = 1;
+TREE_CHAIN (DECL_ASSEMBLER_NAME (node-symbol.decl))
+   = (node-symbol.alias_target ? node-symbol.alias_target
+  : DECL_ASSEMBLER_NAME (symtab_alias_target (node)-symbol.decl));
+  }
+#endif
+
   cgraph_state = CGRAPH_STATE_EXPANSION;
   if (!flag_toplevel_reorder)
 output_in_order ();


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-06-01 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Fixed on darwin at revision 199583.


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-29 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org ---
Indeed, this is generic problem with weakref implementation that for some very
entertaining reason use the CHAIN pointer of identifier nodes in undocumented
way.  I will try to debug today who clears the pointer and why.

Honza


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-27 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE ---
I'd expect that: both the Solaris and Darwin assemblers have no weakref
support, so the results should be the same.

Rainer


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-25 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I see the same failures on x86_64-apple-darwin10. With the patch in comment #9,
I still get

FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=1to1  (internal compiler error)

compared to

FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=1to1  (internal compiler error)
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto
-flto-partition=1to1 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto

without the patch. The ICE is

/opt/gcc/work/gcc/testsuite/gcc.dg/lto/attr-weakref-1_0.c: In function
'callmealias':
/opt/gcc/work/gcc/testsuite/gcc.dg/lto/attr-weakref-1_0.c:9:1: internal
compiler error: in ultimate_transparent_alias_target, at varasm.c:2288

with/without the patch.


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-23 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE ---
 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org ---
 (In reply to Jan Hubicka from comment #1)
 I solved the infinite loop problem on plugin enabled setups with
 http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00847.html
 Are you still seeing the infinite loop?

 My last bootstrap with gld was at rev 199009, i.e. before that patch went in. 
 New ones are currently running (as/ld though, thus it will take a bit to 
 verify
 that the failures with gld are gone).

That gas/gld bootstrap has now completed and the failures are indeed gone.

Thanks.
Rainer


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-23 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org ---
Thanks. Obviously RTL world translates through the weakrefs w/o LTO but not
with LTO.  I will look into it.


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-23 Thread hubicka at ucw dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #9 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
the following patch sets IDENTIFIER_TRANSPARENT_ALIAS correctly from lto-symtab
(correct fix should do the same for variable aliases, too).  Now the testcase
compiles for
me on Linux with weakref disabled.  Does it work for you?
I can not bootstrap with the weakref disabling hack because of some
transational memory issue, but I think it is independent.

Honza

Index: lto-symtab.c
===
--- lto-symtab.c(revision 199251)
+++ lto-symtab.c(working copy)
@@ -623,6 +623,15 @@ lto_symtab_merge_cgraph_nodes (void)
   if ((cnode-thunk.thunk_p || cnode-alias)
cnode-thunk.alias  DECL_P (cnode-thunk.alias))
 cnode-thunk.alias = lto_symtab_prevailing_decl (cnode-thunk.alias);
+#ifndef ASM_OUTPUT_WEAKREF
+  if (lookup_attribute (weakref, DECL_ATTRIBUTES (cnode-symbol.decl)))
+{
+  IDENTIFIER_TRANSPARENT_ALIAS (DECL_ASSEMBLER_NAME (cnode-symbol.decl))
= 1;
+  TREE_CHAIN (DECL_ASSEMBLER_NAME (cnode-symbol.decl))
+  = (DECL_P (cnode-thunk.alias) ? DECL_ASSEMBLER_NAME
(cnode-thunk.alias)
+ : cnode-thunk.alias);
+}
+#endif
   cnode-symbol.aux = NULL;
 }
   FOR_EACH_VARIABLE (vnode)


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-23 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE ---
 --- Comment #9 from Jan Hubicka hubicka at ucw dot cz ---
 Hi,
 the following patch sets IDENTIFIER_TRANSPARENT_ALIAS correctly from 
 lto-symtab
 (correct fix should do the same for variable aliases, too).  Now the testcase
 compiles for
 me on Linux with weakref disabled.  Does it work for you?

It does and is a considerable improvement: it fixes

-FAIL: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o link, -O3
-fl
to (internal compiler error)
-UNRESOLVED: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o
execute
 -O3 -flto

i.e. PR lto/47333 and several of the failures from this PR, but not all
of them:

 UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakr
ef-1_2.o execute -O2 -flto -flto-partition=none 
 FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2
.o link, -O0 -flto -flto-partition=1to1  (internal compiler error)
 UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakr
ef-1_2.o execute -O0 -flto -flto-partition=1to1 
-FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2
.o link, -O2 -flto -flto-partition=1to1 
-UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakr
ef-1_2.o execute -O2 -flto -flto-partition=1to1 
-FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2
.o link, -O0 -flto 
-UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakr
ef-1_2.o execute -O0 -flto 
-FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2
.o link, -O2 -flto
-UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakr
ef-1_2.o execute -O2 -flto

i.e. those failures remain:

FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=none 
UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o execute -O0 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto
-flto-partition=none 
UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o execute -O2 -flto
-flto-partition=none 
FAIL: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto
-flto-partition=1to1  (internal compiler error)
UNRESOLVED: gcc.dg/lto/attr-weakref-1
c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o execute -O0 -flto
-flto-partition=1to1 

Btw., the patch has a few formatting issues: indentation and line
length.

Thanks.
Rainer


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-22 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-22 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-22
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org ---
I solved the infinite loop problem on plugin enabled setups with
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00847.html
Are you still seeing the infinite loop?

What linker are you using? GNU LD with plugin or non-plugin? 

It would be good to know how the ltrans assembly looks for you (i.e. compile
with --save-temps and you should get file *ltrans*.s)  Can you attach it,
please?
Honza


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-22 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #2 from Rainer Orth ro at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #1)
 I solved the infinite loop problem on plugin enabled setups with
 http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00847.html
 Are you still seeing the infinite loop?

My last bootstrap with gld was at rev 199009, i.e. before that patch went in. 
New ones are currently running (as/ld though, thus it will take a bit to verify
that the failures with gld are gone).

 What linker are you using? GNU LD with plugin or non-plugin?

gld 2.23.1 with plugin (the default) for the second failure.

The failures with Sun as (or any assembler without weakref support) happens
with
both Sun ld and gld.

 It would be good to know how the ltrans assembly looks for you (i.e. compile
 with --save-temps and you should get file *ltrans*.s)  Can you attach it,
 please?

I'm attaching the .s files on i386-pc-solaris2.11 with Sun as and gld 2.23.1
for
the -O0 -flto -flto-partition=none -fuse-linker-plugin case.

  Rainer


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-22 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #3 from Rainer Orth ro at gcc dot gnu.org ---
Created attachment 30160
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30160action=edit
-O0 -flto -flto-partition=none -fuse-linker-plugin testcase with Sun as/gld


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-22 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
Thank you. It seems that the weakref is simply not output into the file, so we
end up with undefined call.
What happens when you compile the following manually concatenated testcase w/o
LTO? If it links, can you attach the assembly? I am bit unsure how non-weakref
targets are supposed to behave in situations like this.

I convinced myself that for LTO one needs GNU binutils and thus weakref is
supported, but it is obviously not always the case ;)

Honza

int first = 0;
void abort (void);
int second = 0;
void callmealias (void)
{
  if (!first || !second)
   abort ();
}
void callmefirst (void)
{
  if (first)
abort();
  first = 1;
}
void callmesecond (void)
{
  if (!first)
abort();
  if (second)
abort();
  second = 1;
}
main()
{
  c();
  b();
  return 0;
}
extern void callmesecond();
static void callmealias2() __attribute__((weakref (callmesecond)));

b()
{
  callmealias2();
}
extern void callmefirst();
static void callmealias3() __attribute__((weakref (callmefirst)));

c()
{
  callmealias3();
}


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-22 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE ---
 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
 Thank you. It seems that the weakref is simply not output into the file, so we
 end up with undefined call.

Which may or may not be the same problem as in PR lto/47333.

 What happens when you compile the following manually concatenated testcase w/o
 LTO? If it links, can you attach the assembly? I am bit unsure how non-weakref
 targets are supposed to behave in situations like this.

It links without problems.

 I convinced myself that for LTO one needs GNU binutils and thus weakref is
 supported, but it is obviously not always the case ;)

All other LTO testcases have long worked with Solaris as and ld
(i.e. without weakref and linker plugin), and until the 4.7 branch with
gas and IRIX ld.

Rainer


[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs

2013-05-22 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366

--- Comment #6 from Rainer Orth ro at gcc dot gnu.org ---
Created attachment 30163
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30163action=edit
assembler output from testcase