AHA! why SH big-endian builds lose __thread support

["Robert P. J. Day" <rpjday at mindspring dot com>]

  (wild guess on my part, so i'm open to comments.)

gcc-4.0.2/gcc/configure:

...
if test -z "$tls_first_major"; then
  : # If we don't have a check, assume no support.
else
  echo "$as_me:$LINENO: checking assembler for thread-local storage
support" >&5
echo $ECHO_N "checking assembler for thread-local storage support...
$ECHO_C" >&6
...

  note how the sh3eb build doesn't even *check* for thread-local
storage support, so it's clear that $tls_first_major is null.  and why
is it null?  look a bit further up the configure script:

# Thread-local storage - the check is heavily parametrized.
conftest_s=
tls_first_major=
tls_first_minor=
tls_as_opt=
case "$target" in
...
  sh-*-* | sh[34]-*-*)
    conftest_s='
        .section ".tdata","awT",@progbits
foo:    .long   25
        .text
        .long   foo@TLSGD
        .long   foo@TLSLDM
        .long   foo@DTPOFF
        .long   foo@GOTTPOFF
        .long   foo@TPOFF'
        tls_first_major=2
        tls_first_minor=13
        tls_as_opt=--fatal-warnings
        ;;

uh huh.  that case pattern doesn't accept a big-endian target pattern
of sh3eb or sh4eb, does it?

  thoughts?  is this an actual problem that should be bugzilla'ed?

rday



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com