http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58657
Bug ID: 58657 Summary: bootstrapping cross compiler for sh4eb-*.* target wrongly creates a compiler with emulated TLS support instead of native TLS support Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: eladv6 at gmail dot com When building cross compiler for a sh4eb-*.* target (sh4eb-linux-gnu for example) ./gcc/configure detects no TLS assembler for the architecture and chooses TLS emulation (which in turn creates a broken toolchain with GLIBC and/or uclibc, but this is unrelated to GCC). When sh4-*.* is the target, native TLS is correctly used and not the emulation and a working toolchain is produced. The culprit is in ./gcc/configure. The TLS detection script only considers sh-*.* and sh[34]-*.* as SH targets supporting TLS and not target with sheb-*.* or sh[34]eb-*.* . Obviously the only consideration for TLS support is the CPU architecture and not its endianess. I propose the following patch to GCC 4.7.3 (./gcc/configure) : --- ./gcc/configure-buggy 2013-02-06 17:23:55.000000000 +0200 +++ ./gcc/configure 2013-10-06 15:12:16.526961100 +0200 @@ -23554,7 +23554,7 @@ tls_first_minor=14 tls_as_opt="-m64 -Aesame --fatal-warnings" ;; - sh-*-* | sh[34]-*-*) + sh-*-* | sh[34]-*-* | sheb-*-* | sh[34]eb-*-*) conftest_s=' .section ".tdata","awT",@progbits foo: .long 25 The bug also occurs in GCC 4.8.1. Elad.