good (working) CFLAGS for SPARC64 (Christian Baer)

Christian Baer christian.baer at
Thu Feb 22 10:53:00 UTC 2007

On Wed, 21 Feb 2007 13:58:47 -0800 Steven Hillis wrote:

Good morning[1] Steve!

> Apologies for the confusion, I gave you working tags from memory, not my
> make.conf file (i've been jockeying back and forth between a FreeBSD and a
> gentoo box, and use the same tags on them both, -mcpu on gentoo, -mtune on
> freebsd).

You had me going there for a moment - actually for quite a while. :-) I
sat at my computer for hours on end trying to figure out why the heck
those flags worked on you machine an not on mine. I don't think you need
to apologise for anything though. I read a lot of stuff and bookmarked a
lot of new pages that may prove helpful at some time in the future.
Mistakes are quite normal for human beings and this one made me do
somthing productive for a change. :-)

Back to the issue:

I'm guessing you know that -mcpu and -mtune do *very* different things.

> FreeBSD sparc64 only supports ultrasparc and ultrasparcII cpus, so far as I
> know, so -mcpu=ultrasparc is superfluous. I in fact have -mtune=ultrasparc,
> since they likely use the v9 standard for FreeBSD since they seem to be
> attempting Ultrasparc III support. Again, I'm sorry about my bad memory.
> -mcpu=ultrasparc and -m64 should both be useless options under Sparc64, as
> far as I can tell.

Since I wasn't doing anthing special last night :-) I compiled a new
world and stuffed the output info a file instead of stdout. I greped
though that and didn't find any -mcpu flags in that. So it is quite
likely that the whole thing is being compiled as v7 code - which BTW
doesn't mean that it really has to run on an SS20. I'm not sure if this
really is the case but it is quite likely that there is no mcpu set.

During my research I have found several sites claiming that usually
there is not mcpu set - on most operating systems. NetBSD was often used
as an example. Ok, unlike FreeBSD that also has a branch for SPARC32,
but especially in *that* case you'd think that this flag *should* be set
in the SPARC64 branch.

All of these sites I found didn't actually go into compiling the OS
itself but usually went for some apps running under the OS, usually
OpenSSL or OpenSSH.

Creating 64bit code (the -m64 flag) should *not* be set globally (IMHO).
This really only sets the pointer and long to 64 bits. It could cause
problems with some software that rely on a long with 32 bits only (if
there is any out there). -m64 isn't faster per definition. Only programs
using a lot of pointers (like chess programs) may profit from this
setting. AFAIK even under Solaris the default is -m32. Is many cases -m64
is slower than -m32.

> My actual make.conf file is as follows:
> CFLAGS=-O2 -pipe -mtune=ultrasparc -mvis -mapp-regs -fomit-frame-pointer
> -ffast-math -fweb -frename-registers
> COPTFLAGS=-O2 -pipe -mtune=ultrasparc -mvis -mapp-regs -fomit-frame-pointer
> -ffast-math -fweb -frename-registers

I must admit that I'd be a bit to chicken to enable all of those. The
ffast-math can cause some "strange" results in some programs and if it
does it may take ages to track down where the problem comes from.

Have you had any problems with these at all? I believe that buildworld
compiles with these settings but have you ever had any problems with
other software (compiling and/or running)?


Why? [2]

> .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) &&
> !defined(NOCCACHE)
> CC=/usr/local/libexec/ccache/world-cc
> CXX=/usr/local/libexec/ccache/world-c++
> .endif

I can read this script, but I don't quite see what it does for you. Have
you replaced the default cc with something else like a newer gcc?

> Those flags compile without a hitch. Again, Sparc64 is only for ultrasparc
> CPUs, so that's not really needed.
> The question is (this is aimed at Marius, et al), why does setting the -mcpu
> flag unset the __sparc64__ definition in so many places? This is what your
> errors came from, there are about 20 files that will do that.

Setting the mcpu flag at all will actually cause that. So it doesn't
matter if I set it so ultrasparc or v9, this effect kicks in all the


[1] At least here in Germany it is. :-)
[2] Trying to learn something here, not meant critically.

More information about the freebsd-sparc64 mailing list