From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 25 01:58:03 2007 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EA3216A402 for ; Sun, 25 Feb 2007 01:58:03 +0000 (UTC) (envelope-from evultrole@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2616413C441 for ; Sun, 25 Feb 2007 01:58:02 +0000 (UTC) (envelope-from evultrole@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so1090531nfc for ; Sat, 24 Feb 2007 17:58:02 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=rzsY29OWDP2xyVHAbm6BaszlYgg7LCO5LWDupIJGdb63jlIAdDVTGddNXimfWsuXUu+sXgWCJ+6Rf+DR2fP1AD3UtggTRW3VhO6eFgSXw/178Am7Fzf7sBYbVY4Tt0WLtOrVRxCA+w4VV8r+YlC7xG0OxrUlDEvO7xsD3+XHtmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Fugz7vudKPcQcwEQlTWtvCp9HTW0roLWj/rTaj3G6IjP8P3/ESbo8wDu/3EzHrrLDrroneD31Soh4LS5E17CswVSpFGHf29T5IgcH/6ygfb7ZrH5FUIUm5RMjNIdlAqSzIkS7ppGaDcQ4P/j0SB+EqPICW7arCaZpp8usXlR4sI= Received: by 10.78.160.2 with SMTP id i2mr320539hue.1172368681780; Sat, 24 Feb 2007 17:58:01 -0800 (PST) Received: by 10.78.178.6 with HTTP; Sat, 24 Feb 2007 17:58:01 -0800 (PST) Message-ID: <340594530702241758t422d9332u1dc0cc34c5047006@mail.gmail.com> Date: Sat, 24 Feb 2007 17:58:01 -0800 From: "Steven Hillis" To: freebsd-sparc64@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_51376_26925194.1172368681742" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: good (working) CFLAGS for SPARC64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 01:58:03 -0000 ------=_Part_51376_26925194.1172368681742 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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... ------=_Part_51376_26925194.1172368681742 Content-Type: text/plain; name=freebsd.h.diff.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_eyku42v9 Content-Disposition: attachment; filename="freebsd.h.diff.txt" KioqIGNvbnRyaWIvZ2NjL2NvbmZpZy9zcGFyYy9mcmVlYnNkLmgJVHVlIEp1bCAyNyAyMjowMDox MyAyMDA0Ci0tLSBjb250cmliL2djYy9jb25maWcvc3BhcmMvdGVtcC9mcmVlYnNkLmgJU2F0IEZl YiAyNCAxNjo1NjozMyAyMDA3CioqKioqKioqKioqKioqKgoqKiogMzQsNDQgKioqKgogICN1bmRl ZiAgRkJTRF9UQVJHRVRfQ1BVX0NQUF9CVUlMVElOUwogICNkZWZpbmUgRkJTRF9UQVJHRVRfQ1BV X0NQUF9CVUlMVElOUygpCQlcCiAgICBkbwkJCQkJCVwKICAgICAgewkJCQkJCVwKICAgICAgICBi dWlsdGluX2RlZmluZSAoIl9fTFA2NF9fIik7CQlcCiEgICAgIH0JCQkJCQlcCiAgICB3aGlsZSAo MCkKICAKICAjZGVmaW5lIExJTktfU1BFQyAiJShsaW5rX2FyY2gpCQkJCQkJXAogICAgJXshbW5v LXJlbGF4OiV7IXI6LXJlbGF4fX0JCQkJCQlcCiAgICAle3A6JW5jb25zaWRlciB1c2luZyBgLXBn JyBpbnN0ZWFkIG9mIGAtcCcgd2l0aCBncHJvZigxKX0JCQkJXAotLS0gMzQsNDggLS0tLQogICN1 bmRlZiAgRkJTRF9UQVJHRVRfQ1BVX0NQUF9CVUlMVElOUwogICNkZWZpbmUgRkJTRF9UQVJHRVRf Q1BVX0NQUF9CVUlMVElOUygpCQlcCiAgICBkbwkJCQkJCVwKICAgICAgewkJCQkJCVwKICAgICAg ICBidWlsdGluX2RlZmluZSAoIl9fTFA2NF9fIik7CQlcCiEgICAgICAgYnVpbHRpbl9kZWZpbmUg KCJfX3NwYXJjNjRfXyIpOyAgICAgICAgICAgICAgIFwKISAgICAgICBidWlsdGluX2RlZmluZSAo Il9fc3BhcmNfdjlfXyIpOyAgICAgICAgICAgICAgXAohICAgICAgIGJ1aWx0aW5fZGVmaW5lICgi X19zcGFyY3Y5Iik7ICAgICAgICAgICAgICAgICBcCiEgICAgICAgYnVpbHRpbl9kZWZpbmUgKCJf X2FyY2g2NF9fIik7ICAgICAgICAgIFwKISAgICAgIH0JCQkJCQlcCiAgICB3aGlsZSAoMCkKICAK ICAjZGVmaW5lIExJTktfU1BFQyAiJShsaW5rX2FyY2gpCQkJCQkJXAogICAgJXshbW5vLXJlbGF4 OiV7IXI6LXJlbGF4fX0JCQkJCQlcCiAgICAle3A6JW5jb25zaWRlciB1c2luZyBgLXBnJyBpbnN0 ZWFkIG9mIGAtcCcgd2l0aCBncHJvZigxKX0JCQkJXAo= ------=_Part_51376_26925194.1172368681742--