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.
