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;
}

Reply via email to