Date: Thu, 22 Feb 2007 11:52:53 +0100 (CET) From: Christian Baer <christian.baer@uni-dortmund.de> To: freebsd-sparc64@freebsd.org Subject: Re: good (working) CFLAGS for SPARC64 (Christian Baer) Message-ID: <erjsm5$1c9l$1@nermal.rz1.convenimus.net> References: <340594530702211358g37430181nf783803ad41f14de@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)? > NO_MODULES=YES > NO_PROFILE=YES 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 time. Regards Chris [1] At least here in Germany it is. :-) [2] Trying to learn something here, not meant critically.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?erjsm5$1c9l$1>