* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
@ 2013-05-22 10:08 ` ro at gcc dot gnu.org
2013-05-22 11:25 ` hubicka at gcc dot gnu.org
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ro at gcc dot gnu.org @ 2013-05-22 10:08 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
2013-05-22 10:08 ` [Bug middle-end/57366] " ro at gcc dot gnu.org
@ 2013-05-22 11:25 ` hubicka at gcc dot gnu.org
2013-05-22 12:30 ` ro at gcc dot gnu.org
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-05-22 11:25 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
2013-05-22 10:08 ` [Bug middle-end/57366] " ro at gcc dot gnu.org
2013-05-22 11:25 ` hubicka at gcc dot gnu.org
@ 2013-05-22 12:30 ` ro at gcc dot gnu.org
2013-05-22 12:31 ` ro at gcc dot gnu.org
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ro at gcc dot gnu.org @ 2013-05-22 12:30 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (2 preceding siblings ...)
2013-05-22 12:30 ` ro at gcc dot gnu.org
@ 2013-05-22 12:31 ` ro at gcc dot gnu.org
2013-05-22 13:59 ` hubicka at gcc dot gnu.org
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ro at gcc dot gnu.org @ 2013-05-22 12:31 UTC (permalink / raw)
To: gcc-bugs
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=30160&action=edit
-O0 -flto -flto-partition=none -fuse-linker-plugin testcase with Sun as/gld
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (3 preceding siblings ...)
2013-05-22 12:31 ` ro at gcc dot gnu.org
@ 2013-05-22 13:59 ` hubicka at gcc dot gnu.org
2013-05-22 14:44 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-05-22 13:59 UTC (permalink / raw)
To: gcc-bugs
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();
}
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (4 preceding siblings ...)
2013-05-22 13:59 ` hubicka at gcc dot gnu.org
@ 2013-05-22 14:44 ` ro at CeBiTec dot Uni-Bielefeld.DE
2013-05-22 14:46 ` ro at gcc dot gnu.org
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2013-05-22 14:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (5 preceding siblings ...)
2013-05-22 14:44 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2013-05-22 14:46 ` ro at gcc dot gnu.org
2013-05-23 10:01 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ro at gcc dot gnu.org @ 2013-05-22 14:46 UTC (permalink / raw)
To: gcc-bugs
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=30163&action=edit
assembler output from testcase
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (6 preceding siblings ...)
2013-05-22 14:46 ` ro at gcc dot gnu.org
@ 2013-05-23 10:01 ` ro at CeBiTec dot Uni-Bielefeld.DE
2013-05-23 11:37 ` hubicka at gcc dot gnu.org
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2013-05-23 10:01 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (7 preceding siblings ...)
2013-05-23 10:01 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2013-05-23 11:37 ` hubicka at gcc dot gnu.org
2013-05-23 13:41 ` hubicka at ucw dot cz
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-05-23 11:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (8 preceding siblings ...)
2013-05-23 11:37 ` hubicka at gcc dot gnu.org
@ 2013-05-23 13:41 ` hubicka at ucw dot cz
2013-05-23 18:30 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hubicka at ucw dot cz @ 2013-05-23 13:41 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (9 preceding siblings ...)
2013-05-23 13:41 ` hubicka at ucw dot cz
@ 2013-05-23 18:30 ` ro at CeBiTec dot Uni-Bielefeld.DE
2013-05-25 10:26 ` dominiq at lps dot ens.fr
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2013-05-23 18:30 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (10 preceding siblings ...)
2013-05-23 18:30 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2013-05-25 10:26 ` dominiq at lps dot ens.fr
2013-05-27 15:22 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-05-25 10:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (11 preceding siblings ...)
2013-05-25 10:26 ` dominiq at lps dot ens.fr
@ 2013-05-27 15:22 ` ro at CeBiTec dot Uni-Bielefeld.DE
2013-05-29 13:05 ` hubicka at gcc dot gnu.org
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2013-05-27 15:22 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (12 preceding siblings ...)
2013-05-27 15:22 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2013-05-29 13:05 ` hubicka at gcc dot gnu.org
2013-06-01 14:57 ` hubicka at ucw dot cz
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-05-29 13:05 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (13 preceding siblings ...)
2013-05-29 13:05 ` hubicka at gcc dot gnu.org
@ 2013-06-01 14:57 ` hubicka at ucw dot cz
2013-06-03 9:11 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hubicka at ucw dot cz @ 2013-06-01 14:57 UTC (permalink / raw)
To: gcc-bugs
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 ();
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (14 preceding siblings ...)
2013-06-01 14:57 ` hubicka at ucw dot cz
@ 2013-06-03 9:11 ` ro at CeBiTec dot Uni-Bielefeld.DE
2013-09-04 17:00 ` hubicka at gcc dot gnu.org
2015-06-23 8:47 ` rguenth at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2013-06-03 9:11 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (15 preceding siblings ...)
2013-06-03 9:11 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2013-09-04 17:00 ` hubicka at gcc dot gnu.org
2015-06-23 8:47 ` rguenth at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-09-04 17:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
2013-05-22 10:07 [Bug middle-end/57366] New: gcc.dg/lto/attr-weakref-1 FAILs ro at gcc dot gnu.org
` (16 preceding siblings ...)
2013-09-04 17:00 ` hubicka at gcc dot gnu.org
@ 2015-06-23 8:47 ` rguenth at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-06-23 8:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread