From owner-freebsd-stable Mon Jul 24 10:33:47 2000 Delivered-To: freebsd-stable@freebsd.org Received: from privatecube.privatelabs.com (privatecube.privatelabs.com [198.143.31.30]) by hub.freebsd.org (Postfix) with ESMTP id 7FC6E37BB31 for ; Mon, 24 Jul 2000 10:33:39 -0700 (PDT) (envelope-from mi@virtual-estates.net) Received: from misha.privatelabs.com (misha.privatelabs.com [198.143.31.6]) by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id MAA21941; Mon, 24 Jul 2000 12:32:41 -0400 Received: from virtual-estates.net (localhost [127.0.0.1]) by misha.privatelabs.com (8.9.3/8.9.3) with ESMTP id NAA34094; Mon, 24 Jul 2000 13:29:14 -0400 (EDT) (envelope-from mi@virtual-estates.net) Message-Id: <200007241729.NAA34094@misha.privatelabs.com> Date: Mon, 24 Jul 2000 13:29:11 -0400 (EDT) From: mi@aldan.algebra.com Subject: Re: Recommended compilation optimizations To: John Baldwin Cc: stable@freebsd.org In-Reply-To: <200007241707.KAA49181@pike.osd.bsdi.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24 Jul, John Baldwin wrote: = > = -O -pipe = > = = > = AFAIK that's the only optimization that is more or less guaranteed = > = to work. = > = > I've seen '-fexpensive-optimizations' break havoc in the squid = > binary, so I no longer use it for anything, but '-mcpu=i686 = > -march=i686' seems fine to me and tells the compiler that your only = > target processor is of the 686 class. If you are not planning to = > debug the thing, add '-fomit-frame-pointer'. = > = > -mi (who gets annoyed every once in a while when he sees = > people discouraging optimization as dangerous instead of = > fixing the compiler) = = Uh, have you actually _looked_ at the gcc source? Making such a = statement is rather arrogant if you aren't willing to put some work = into the compiler yourself. gcc is not an easy program to fix, it is = rather large and complex. I was not blaming you, neccessarily. As for me, I did file a few PRs with FreeBSD and/or with GCC people, providing the exact C-code, that breaks and more details. I think, it is important for everyone bitten by some brokennes of some aggressive optimization in GCC to investigate and file the bug reports... This is actually, true about any brokenness :) In the above mentioned case of squid, the reduced C-code snippet, that continued to brake on FreeBSD was compiled properly on Mandrake (by the same version of EGCS), so it looks like a FreeBSD-specific problem. Instead of encouraging bug-reports, the attitude has so far been: "well, if you use high optimization -- you are on your own", as exemplified in the follow-up to my i386/19245 . As a result, at least, in this example, the same thing works on Linux, that does not on FreeBSD. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message