Date: Thu, 22 Feb 2007 21:38:02 -0800 From: "Steven Hillis" <evultrole@gmail.com> To: freebsd-sparc64@freebsd.org Subject: Re: good (working) CFLAGS for SPARC64 Message-ID: <340594530702222138t5c42001brb3759fd46b85eb3e@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
>> 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. :-) I actually redid the computer before double checking my old make.conf for the timed make world test and put that flag in as well, spent several minutes actually fixing the problems that came up, then remembered what was happening... >.< >I'm guessing you know that -mcpu and -mtune do *very* different things. Indeed, mcpu sets registers and many other things, mtune simply sets possible register allocation within a broader set without breaking compatibility, however mcpu=ultrasparc seems to be a combination of mcpu=v9 & mtune=ultrasparc, so in many cases the things done are only vastly different in one direction. >> 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. Everything I've ever seen on NetBSD suggests that it defaults to installing the Sparc64 branch with mcpu=v9 flags, so it would follow that Sparc64 on FreeBSD does as well... however, lack of flags anywhere would call that into question. Lack of flags does not imply it is not the case, however, as the default settings of GCC would not show up in any compile lines, being default and all (I don't think -m64 shows up in any lines either). This, and lack of support for anything in the v8 line or lower, draws my conclusion that v9 is already set by default. I will see if I can track down an exact setting over the next 20 minutes (not 100% sure where to look for that, so it will take me awhile) Incidentally, I believe manually setting the -mcpu=v9 flag gave me the same "unknown architecture" crap, but I think it's just using a non-default mcpu flag that is causing the issue somehow. >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. NetBSD also has -m64 as the default flag, as far as I can tell. Yes, I am aware of the problems inherent in this (firefox, cough cough), but (again from NetBSD, circa 1.6) the userland in many 64 bit systems can't properly build anything with the -m32 flag even set. >> 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)? As I said before, I know many people would scold the use of such things. I have had no issues with any program compiles, nor any strange stability issues, but I don't use any really math heavy science programs so my lack of problems does not imply that it is a safe thing to use. >> NO_MODULES=YES >> NO_PROFILE=YES >Why? [2] Why no profile? With profiling enabled many programs build with the -pg flag, which is not compatible with -fomit-frame-pointers (build error) so I just disable them ahead of time to save the hastle. I don't make a point of debugging in my spare time, so I don't really care about it greatly. The no modules I just use because I'm lazy and see no point in the kernel compiling drivers for a scsi card I don't use, own, or even know how/where to find. It's also not necessarily a good flag for common use, it just works well for my purposes. >> .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? I just installed ccache to test how it would affect buildworld speed (someone was asking about time on an ultra 80, so I used ccache to bring it down under 1 hour) >> 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. Anyway, I think (I'm far from a proficient programmer mind you) that the problem goes back to the /usr/src/contrib/gcc/config/sparc.h file, which sets CPP_SPEC to __sparc_v9__ with any mcpu flags, while freebsd works with __sparc64__, but that's after only about 10 seconds of looking at a search for mcpu=v9 in the full source tree, and only doing a key word search in that particular file... I haven't bothered to look back at any other source files to confirm that yet... anyway, I'll see what I can find about it tonight and I'll let you know if that is in fact it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?340594530702222138t5c42001brb3759fd46b85eb3e>