[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #25 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Created attachment 34695 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34695action=edit Assembly file showing the duplicate label
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #24 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Apparently the test still fails, so I'm re-opening it as wrongly closed, since it still fails for arm-eabi and cris-elf (same as in comment #23) and according to https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00812.html also for hppa64-hp-hpux11.11. The error changed from ICE to something else but that is not a reason to close the PR. Comment #23 isn't clear that the assembler complains and that the relevant part of gcc.log is: output is: /tmp/ccDUW6dB.s: Assembler messages: /tmp/ccDUW6dB.s:37: Error: symbol `___emutls_v.foo' is already defined Assembler code will be attached.
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #23 from ktkachov at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #22) Trevor, seems I missed your patch. Sorry for that :( I committed the last part then and lets close the PR Thanks! The testcase doesn't ICE anymore, but on arm-none-eabi I'm seeing it fail with: Error: symbol `__emutls_v.foo' is already defined
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #18 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Thu Feb 5 03:57:32 2015 New Revision: 220432 URL: https://gcc.gnu.org/viewcvs?rev=220432root=gccview=rev Log: PR ipa/61548 * varpool.c (varpool_node::remove): Fix order of variables. Modified: trunk/gcc/ChangeLog trunk/gcc/varpool.c
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #19 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Thu Feb 5 04:01:25 2015 New Revision: 220433 URL: https://gcc.gnu.org/viewcvs?rev=220433root=gccview=rev Log: PR ipa/61548 * ipa.c (symbol_table::remove_unreachable_nodes): Fix ordering issue when removing varpool nodes. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #17 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 34673 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34673action=edit Proposed fix Ok, there seems to be 3 issues ;) First is that emutls does not resolve alias after introducing it. Second is that we may end up removing alias target before alias in ipa.c and third is that vaprool_node::remove actually removes the reference before attempting to use it. I would welcome if someone tests this on one of the targets reproducing the problem
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Jan Hubicka hubicka at gcc dot gnu.org --- Trevor, seems I missed your patch. Sorry for that :( I committed the last part then and lets close the PR Thanks!
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #21 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Thu Feb 5 04:45:41 2015 New Revision: 220434 URL: https://gcc.gnu.org/viewcvs?rev=220434root=gccview=rev Log: PR ipa/61548 * tree-emultls.c (new_emutls_decl): Resolve alias after creating it. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-emutls.c
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #20 from tbsaunde at tbsaunde dot org --- Created attachment 34673 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34673action=edit Proposed fix Ok, there seems to be 3 issues ;) First is that emutls does not resolve alias after introducing it. Second is that we may end up removing alias target before alias in ipa.c and third is that vaprool_node::remove actually removes the reference before attempting to use it. I would welcome if someone tests this on one of the targets reproducing the problem Well, the patch I sent did 1 and 3, and that fixed the crash, so I expect adding 2 won't really hurt, but I can test that theory tomorrow. Trev
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #16 from tbsaunde at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #15) I think it is best to modify the remove_unreachable_nodes loop to first remove aliases before removing their target... how is this related? the target isn't removed at all in this case only the alias.
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org --- I think it is best to modify the remove_unreachable_nodes loop to first remove aliases before removing their target...
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #14 from tbsaunde+mozilla at tbsaunde dot org --- On Mon, Jan 26, 2015 at 03:56:05AM +, hubicka at ucw dot cz wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #13 from Jan Hubicka hubicka at ucw dot cz --- So, what is here is: emutls calls varpool_node::create_alias(decl(emutls_v.bar), decl(emutls_v.foo)) which sets alias = true and alias_target = node(emutls_v.foo) on the node for emutls_v.bar, however it does not set up ref_list.references on node(emutls_v.bar) to point at node(emutls_v.foo). Then during varification we call symtab_node::get_alias_target() which gets the alias from node(emutls_v.bar).ref_list.references but that crashes becauses references doesn't contain an element for the alias target. The way to get the references for alias is to call alias-resolve_alias. The resolution normally happens at the end of parsing but if someone introduces new alias late, he needs to cal the resolve_alias manually. With that fixed things get a little farther, but there's still a problem. symbol_table::remove_unreachable_node () decides to remove one of the tls aliases. When varpool_node::remove () is called it first clears ref_list with a call to symtab_node::unregister () and then calls varpool_node::cdtor_usable_for_folding () which tries to get the alias target, and so crashes because ref_list has been cleared. I guess the simplest thing is to call cdtor_usable_for_folding earlier, but I don't know if there's something better. Trev
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #13 from Jan Hubicka hubicka at ucw dot cz --- So, what is here is: emutls calls varpool_node::create_alias(decl(emutls_v.bar), decl(emutls_v.foo)) which sets alias = true and alias_target = node(emutls_v.foo) on the node for emutls_v.bar, however it does not set up ref_list.references on node(emutls_v.bar) to point at node(emutls_v.foo). Then during varification we call symtab_node::get_alias_target() which gets the alias from node(emutls_v.bar).ref_list.references but that crashes becauses references doesn't contain an element for the alias target. The way to get the references for alias is to call alias-resolve_alias. The resolution normally happens at the end of parsing but if someone introduces new alias late, he needs to cal the resolve_alias manually. Honza
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #12 from tbsaunde at gcc dot gnu.org --- So, what is here is: emutls calls varpool_node::create_alias(decl(emutls_v.bar), decl(emutls_v.foo)) which sets alias = true and alias_target = node(emutls_v.foo) on the node for emutls_v.bar, however it does not set up ref_list.references on node(emutls_v.bar) to point at node(emutls_v.foo). Then during varification we call symtab_node::get_alias_target() which gets the alias from node(emutls_v.bar).ref_list.references but that crashes becauses references doesn't contain an element for the alias target.
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #11 from ktkachov at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #10) I believe this is also fixed by the ipa-inline alias handling fix. I still see the ICE on ARM at least as of r219714: $TOP/gcc/gcc/testsuite/gcc.dg/tls/alias-1.c:24:3: internal compiler error: Segmentation fault 0xa61df5 crash_signal $TOP/gcc/gcc/toplev.c:381 0x6a05d8 symtab_node::get_alias_target() $TOP/gcc/gcc/cgraph.h:2271 0x6a05d8 symtab_node::verify_base() $TOP/gcc/gcc/symtab.c:1130 0x6a0983 symtab_node::verify() $TOP/gcc/gcc/symtab.c:1163 0x6a19af symtab_node::verify_symtab_nodes() $TOP/gcc/gcc/symtab.c:1181 0x8dabd6 symbol_table::remove_unreachable_nodes(_IO_FILE*) $TOP/gcc/gcc/ipa.c:662 0x6b1fa4 ipa_passes $TOP/gcc/gcc/cgraphunit.c:2087 0x6b1fa4 symbol_table::compile() $TOP/gcc/gcc/cgraphunit.c:2221 0x6b3c71 symbol_table::finalize_compilation_unit() $TOP/gcc/gcc/cgraphunit.c:2370 0x54d083 c_write_global_declarations() $TOP/gcc/gcc/c/c-decl.c:10787 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org --- I believe this is also fixed by the ipa-inline alias handling fix.
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||ramana at gcc dot gnu.org
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING Component|regression |ipa Known to fail|4.10.0 |5.0 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Is this still broken?
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #9 from ktkachov at gcc dot gnu.org --- Yes. I still get the ICE on aarch64-none-elf and arm-none-eabi as of r217750
