https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61883
Bug ID: 61883 Summary: [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm target Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tony.wang at arm dot com The trunk will ICE when user declare tls variables with alias name on run-time need to generate emutls variables. How to reproduce: /work/tonwan01/test_alias$ /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/install-native/lib/gcc/arm-none-eabi/4.10.0/cc1 -quiet -v -D_USES_INITFINI_ alias-1-clean.c -quiet -dumpbase alias-1-clean.c -mthumb -mcpu=cortex-m0 -auxbase-strip alias-1.exe -version -o /tmp/cc0AHQ0g.s alias-1.c:24:3: internal compiler error: Segmentation fault _attribute_ ((visibility ("hidden"))); ^ 0xbdde7f crash_signal /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/toplev.c:337 0x78b390 symtab_alias_target /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraph.h:1535 0x78d629 verify_symtab_base(symtab_node*) /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:830 0x78d7bb verify_symtab_node(symtab_node*) /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:863 0x78d823 verify_symtab() /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:881 0x9e6e85 symtab_remove_unreachable_nodes(bool, _IO_FILE*) /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/ipa.c:592 0x7a09f3 ipa_passes /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2065 0x7a0d70 compile() /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2187 0x7a107c finalize_compilation_unit() /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2342 0x60ba71 c_write_global_declarations() /work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/c/c-decl.c:10452 The reason for this bug is that in the tree-emutls.c pass, the code imply a default sequence of tls symbol and its corresponding control symbol. Some patch now move the symtab node generation to a very early stage, so the sequence of the node in varpool changed which leads to the wrong mapping of tls var and control var. For case gcc.dg/tls/alias-1.c Before: tls_vars[0]:bar(alias foo) tls_vars[1]:foo control_vars[0]:_emutls_v.foo control_vars[1]:_emutls_v.bar(alias _emutls_v.foo) So when generate the reference list of main, the actual reference of bar would be _emutls_v.foo which is correct. After: tls_vars[1]:bar(alias foo) tls_vars[0]:foo control_vars[0]:_emutls_v.foo control_vars[1]:_emutls_v.bar(alias _emutls_v.foo) The reference list of main will point to the alias symbol node _emutls_v.bar, which finally cause the segment fault. I also a simpler test case to reproduce this bug, it should be an old bug for the tree-emutls pass. The way this pass mapping the control vars and tls vars hasn't consider that there may more than one alias for a tls var. For run time support tls, the code can compile successfully. struct __res_state { char x[123]; }; __thread struct __res_state foo; extern __thread struct __res_state bar __attribute__ ((alias ("foo"))); extern __thread struct __res_state baz __attribute__ ((alias ("foo"))); int main() { bar.x[0] = 0; baz.x[1] = 1; return 0; }