Bug 24836 - gcc/configure doesn't handle all possible SH architectures
Summary: gcc/configure doesn't handle all possible SH architectures
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.0.2
: P5 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-13 21:16 UTC by Robert P. J. Day
Modified: 2009-03-31 01:15 UTC (History)
3 users (show)

See Also:
Host: i686-unknown-linux
Target: sh3eb-unknown-linux
Build:
Known to work:
Known to fail: 3.4.4 4.0.2 4.1.0
Last reconfirmed: 2009-03-30 23:03:28


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert P. J. Day 2005-11-13 21:16:37 UTC
gcc-4.0.2/gcc/configure, line 13879:

sh-*-* | sh[34]-*-*)
        ...
        tls_first_major=2
        tls_first_minor=13
        tls_as_opt=--fatal-warnings
        ;;

note that this case doesn't consider the possibilities of sh[34]eb for big-endian architectures and so fails to set the variable tls_first_major, among others.

  this causes all kinds of grief further down in that script, line 13956:

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 that, since $tls_first_major is unset, there is no check for thread-local storage support in the big-endian case, even if you've configured for NPTL support.

  at a minimum, that case should add the pattern "sh[34]eb-*-*" and perhaps several more variations, but i don't know all of those possibilities.  at the very least, i would add that pattern above to fix the case of building for big-endian and NPTL on sh3 and sh4.
Comment 1 Laurent GUERBY 2009-03-30 15:58:40 UTC
Kaz, do you know if this problem fixed in 4.2/4.3/4.4?
Comment 2 Kazumoto Kojima 2009-03-30 23:03:28 UTC
Not fixed yet.  The real problem isn't a GCC problem, though.
NPTL in glibc works only with the little endian and would be
broken for the big endian.  I've heard no news about it.
Supporting sh[34]eb here doesn't make sense ATM.  Of course,
I'll approve the patch to permit possible configurations
if someone propose an appropriate one to gcc-patches, though
I won't do it myself.
Comment 3 Mike Frysinger 2009-03-31 00:02:16 UTC
well, as you certainly know, glibc isnt the only C library on the block ...
Comment 4 Kazumoto Kojima 2009-03-31 00:44:07 UTC
(In reply to comment #3)
> well, as you certainly know, glibc isnt the only C library on the block ...

Sure.  If uclibc folks, for example, have made NPTL work on
sh[34]eb already and someone will propose a gcc patch, I'll be happy.


Comment 5 Mike Frysinger 2009-03-31 01:15:33 UTC
mmm, i was thinking this was common SH code rather than TLS specific.  i doubt uClibc will get NPTL support faster than glibc ;).