From owner-freebsd-questions@FreeBSD.ORG Tue Feb 17 10:35:44 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7AD416A4CE for ; Tue, 17 Feb 2004 10:35:44 -0800 (PST) Received: from odot.okladot.state.ok.us (odot.okladot.state.ok.us [192.149.244.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E53F43D1D for ; Tue, 17 Feb 2004 10:35:44 -0800 (PST) (envelope-from root@techpc04.okladot.state.ok.us) Received: from notes9c.okladot.state.ok.us (notes9a.okladot.state.ok.us [10.36.36.31])MAA70602; Tue, 17 Feb 2004 12:35:43 -0600 Received: from techpc04.okladot.state.ok.us ([199.27.9.37]) by notes9c.okladot.state.ok.us (Lotus Domino Release 5.0.12) with ESMTP id 2004021712354924:26849 ; Tue, 17 Feb 2004 12:35:49 -0600 Received: by techpc04.okladot.state.ok.us (Postfix, from userid 0) id E65B95C22; Tue, 17 Feb 2004 12:35:45 -0600 (CST) To: "Chuck Swiger" From: "Paul Seniura" In-Reply-To: <402D070D.90506@mac.com> References: <20040213001703.616C75C3B@techpc04.okladot.state.ok.us><20040213011324.GA55948@xor.obsecurity.org><20040213035608.3AA11A38EA@scifi.homeip.net><402D070D.90506@mac.com> Message-Id: <20040217183545.E65B95C22@techpc04.okladot.state.ok.us> Date: Tue, 17 Feb 2004 12:35:45 -0600 (CST) X-MIMETrack: Itemize by SMTP Server on Notes9c/ODOT(Release 5.0.12 |February 13, 2003) at 02/17/2004 12:35:49 PM,2003) at 02/17/2004 12:35:50 PM, Serialize complete at 02/17/2004 12:35:50 PM cc: freebsd-questions@freebsd.org cc: Paul Seniura Subject: Re: need help on CFLAGS in /etc/make.conf please X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Paul Seniura List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 18:35:44 -0000 Hi Chuck, The delay in my response here was due to pest control in our building and the three-day weekend (I have no li'l-endians at home ;) . Chuck Swiger wrote: > Hi, Paul-- > > There is little point to crossposting between -questions and -hackers; > dropping the latter. Actually, is probably the most > appropriate place... As I look at it more & more, it'll probably be a hack job to get it to do what I'm suggesting. ;) I've responded to Kris with further contemplations, if you have time and would like to chime-in, please do. > Paul Seniura wrote: > > My question for this discussion is specifically how to prevent > > overriding a port's own setting for that parm, and to provide a > > default setting -O[1] when the port does not set it at all? > > Well-behaved ports respect CFLAGS, meaning that you can define that variable > in /etc/make.conf (or on the command line when you invoke make), and the port > should use that value when building the software. Sorry to say, I don't think you're getting my gist here. ;) I want a default setting -O "iff"=="if and only if" the original does not provide it. That's what "default setting" means. ;) Also, I do not want to override the original's optimization settings either if there was one provided -- my "default setting" isn't used in this case. See what I mean? And as far as i386 is concerned, it is looking like -O2 is the "maximum" that should be attempted. Other platforms, e.g. -march=7450 I use at home, can go -O5 without problems. At any rate, I certainly want to cut-down anything like what Kris mentions e.g. -O999! > If you tell us which port is broken, someone will fix it. For example, one of > the ports I maintain the author explicitly sets -O2, but the port Makefile > patches that via: > > post-patch: > ${REINPLACE_CMD} -e 's/-O2//' ${WRKSRC}/Makefile A msg from Richard Coleman, taken together with the GCC 3.x Known Bugs site, is leading me to believe any bugs solely due to higher -O levels need to be fixed by the author(s) of the software. ISTM many 'enterprising' companies are relying on the integrity of GCC in this manner. GCC has come a long way to earn that kind of trust. And so I would like to be able to trust the author's settings in this regard, if I so choose (putting on my system admin's hat). You're changing what the author sets-up before any hack-job I invent will even see it. Why? If I interpret what Kris said correctly, he wants you to think GCC 3.x is the source of the bugs at -O2+. My response to him was, essentially, to read-up on GNU's GCC 3.x Known Bugs webpage, where they clearly state any -O bugs are much more likely to be non-ISO-compliant source code style. The author would need to fix the source code and/or logic in these cases so -O2 will work properly. If my hack-job sees the result of your hack-job, it will reinsert a -O (effectively -O1) back into the compiler options. But clearly the original author wants -O2 here, so it ought to override my -O default, if I allow it to. I reiterate the notion of other platforms working fine with optimizations and FBSD is slowing down because IMHO of some age-old assumptions about GCC itself. As a specific example: If GCC 3.3.3 generates really fast code on a Linux/i386 app *and* it's proven to work well, then FBSD/i386's code should fly just as fast at the same level with no problem. Oh but y'all are hacking the guts out of the optimization settings coming from the author, so FBSD/i386 will never see the same end-results here. Also I'm fussin' because I've read several KDE users's msgs about its new slowness with 3.2. The higher-ups here would love to see this project fail (they already ignore my ideas on getting Macs, but I digress...). We need some _working_ performance-boosting options on i386 if we're going to show FreeBSD in its best light. As an aside, I volunteered to get net/tn3270 working again. Its src has numerous violations, because no one has maintained it. On top of that, it copies parts of /usr/src (telnet) and patches it to hopefully follow IBM's RFCs for mainframe environments. I *really* hope to cut out these ugly hacks once & for all. Guess how long this Puny Pentium2 takes to compile anything... it's all 'they' will let me use here... *any* improvements in optimized code will go a long way on these slow boxes (yes I've read the on-line manuals on 'tuning' etc. and have already implemented as many of those ideas as I can [am permitted] here). Thank you, -- Paul Seniura System Specialist (z/OS mainly, where we have only 16 registers!) State of Okla. D.O.T.