good (working) CFLAGS for SPARC64

Steven Hillis evultrole at gmail.com
Sun Feb 25 01:58:03 UTC 2007


Christian,

I've spent a little more time on this today (waiting on source compiles each
time I changed something took forever, so it took far longer than I would
have liked). The following lines are what I was talking about before (found
in contrib/gcc/config/sparc/sparc.h):

/* Note that TARGET_CPU_v9 is assumed to start the list of 64-bit
   capable cpu's.  */
#define TARGET_CPU_sparc        0
#define TARGET_CPU_v7           0       /* alias for previous */
#define TARGET_CPU_sparclet     1
#define TARGET_CPU_sparclite    2
#define TARGET_CPU_v8           3       /* generic v8 implementation */
#define TARGET_CPU_supersparc   4
#define TARGET_CPU_hypersparc   5
#define TARGET_CPU_sparc86x     6
#define TARGET_CPU_sparclite86x 6
#define TARGET_CPU_v9           7       /* generic v9 implementation */
#define TARGET_CPU_sparcv9      7       /* alias */
#define TARGET_CPU_sparc64      7       /* alias */
#define TARGET_CPU_ultrasparc   8
#define TARGET_CPU_ultrasparc3  9


Basically, in order for any sparc system to be 64-bit enabled it has to be
at least v9 compiled, hence FreeBSD/Sparc64, NetBSD/Sparc64, and
OpenBSD/Sparc64 must all be v9 compiled... which is what I was trying to get
at earlier.

Now, that aside, -mtune=ultrasparc -mcpu=ultrasparc didn't change the speed
of anything in any significant way (if there was a change in the programs I
tested it was too small to be noticable), whereas the change from just -pipe
to -pipe -O2 gave a 275% increase in speed in things like lame... so, you
can use my fix for mcpu if you want, but since it defaults to v9 (has to for
64 bit support) and there isn't really any difference between generic v9 and
ultrasparc (first v9) you won't gain much, if anything (I honestly noticed
no difference at all).

Anyway, I fixed the errors in three different ways, one was about 5 files
changed, one 91 files changed, then bothered to actually look at the
difference between the OpenBSD/NetBSD and FreeBSD implementation. For
whatever reason the freebsd config goes with CPP_CPU64_DEFAULT_SPEC with
many options, whereas the others go with a TARGET_CPP_BUILTIN... now, you'd
assume they would be two ways to reach the same end, but they aren't.... the
freebsd way of doing it allows the __sparc64__ spec to be overwritten with
mcpu flags, while the others don't as the __sparc64__ is builtin and present
in all possible sparc configurations (as I understand it).

So, the basic fix was just updating the
/usr/src/contrib/gcc/config/sparc/freebsd.h file with this (diff output):


*** contrib/gcc/config/sparc/freebsd.h  Tue Jul 27 22:00:13 2004
--- contrib/gcc/config/sparc/temp/freebsd.h     Sat Feb 24 16:56:33 2007
***************
*** 34,44 ****
  #undef  FBSD_TARGET_CPU_CPP_BUILTINS
  #define FBSD_TARGET_CPU_CPP_BUILTINS()                \
    do                                          \
      {                                         \
        builtin_define ("__LP64__");            \
!     }                                         \
    while (0)

  #define LINK_SPEC
"%(link_arch)                                               \
    %{!mno-relax:%{!r:-relax}}                                          \
    %{p:%nconsider using `-pg' instead of `-p' with
gprof(1)}                           \
--- 34,48 ----
  #undef  FBSD_TARGET_CPU_CPP_BUILTINS
  #define FBSD_TARGET_CPU_CPP_BUILTINS()                \
    do                                          \
      {                                         \
        builtin_define ("__LP64__");            \
!       builtin_define ("__sparc64__");               \
!       builtin_define ("__sparc_v9__");              \
!       builtin_define ("__sparcv9");                 \
!       builtin_define ("__arch64__");          \
!      }                                                \
    while (0)

  #define LINK_SPEC
"%(link_arch)                                               \
    %{!mno-relax:%{!r:-relax}}                                          \
    %{p:%nconsider using `-pg' instead of `-p' with
gprof(1)}                           \



Now, unless there is some super important reason those are not in the
freebsd config file (like breaking compatibility with the new T1s) they
really should be put in. Even if it breaks the new sparc cpus, at least
builtin_define ("__sparc64__"); should be there at the least, that won't
break anything (from what I can tell) and would solve any problems like
this. Even if the mcpu flags are unneeded because it defaults to v9 support
it doesn't make any sense to leave the system in a state where adding a
duplicate flag breaks things.

So, Chris, drop those into the file it should fix it, and I'm going to go
ahead and file a bug report on this along with the fix, the maintainers can
decide what to do with it from there I guess...
-------------- next part --------------
*** contrib/gcc/config/sparc/freebsd.h	Tue Jul 27 22:00:13 2004
--- contrib/gcc/config/sparc/temp/freebsd.h	Sat Feb 24 16:56:33 2007
***************
*** 34,44 ****
  #undef  FBSD_TARGET_CPU_CPP_BUILTINS
  #define FBSD_TARGET_CPU_CPP_BUILTINS()		\
    do						\
      {						\
        builtin_define ("__LP64__");		\
!     }						\
    while (0)
  
  #define LINK_SPEC "%(link_arch)						\
    %{!mno-relax:%{!r:-relax}}						\
    %{p:%nconsider using `-pg' instead of `-p' with gprof(1)}				\
--- 34,48 ----
  #undef  FBSD_TARGET_CPU_CPP_BUILTINS
  #define FBSD_TARGET_CPU_CPP_BUILTINS()		\
    do						\
      {						\
        builtin_define ("__LP64__");		\
!       builtin_define ("__sparc64__");               \
!       builtin_define ("__sparc_v9__");              \
!       builtin_define ("__sparcv9");                 \
!       builtin_define ("__arch64__");          \
!      }						\
    while (0)
  
  #define LINK_SPEC "%(link_arch)						\
    %{!mno-relax:%{!r:-relax}}						\
    %{p:%nconsider using `-pg' instead of `-p' with gprof(1)}				\


More information about the freebsd-sparc64 mailing list