Date: Sat, 28 Oct 2000 11:37:53 -0500 From: "Jeffrey J. Mountin" <jeff-ml@mountin.net> To: Donn Miller <dmmiller@cvzoom.net> Cc: stable@FreeBSD.ORG Subject: Re: "Malloc type lacks magic" show-stopper solved Message-ID: <4.3.2.20001028101053.00dbc960@207.227.119.2> In-Reply-To: <Pine.BSF.4.21.0010280302510.71973-100000@lcl12.cvzoom.net> References: <4.3.2.20001027114057.00b91100@207.227.119.2>
next in thread | previous in thread | raw e-mail | index | archive | help
At 03:22 AM 10/28/00 -0400, Donn Miller wrote: >On Fri, 27 Oct 2000, Jeffrey J. Mountin wrote: > > > At 02:24 AM 10/27/00 -0400, Donn Miller wrote: > > > What is interesting is that -march will produce a slightly larger binary > > than -mcpu. Would expect the opposite, since the code is compiled to run > > *only* on one CPU class with -march, rather than just a scheduling change. > >Well, I believe the "default" instruction set generated by gcc/gas is >i386. If you specifify -march=486, you will get i386+i486 instructions >generated, because i486 contains i386 instructions as a subset. But if >one specifies gcc -march=pentium, you will get i586 instructions, which >includes 586+486+386 machine code. The first part is correct, but you mixed up -march with -mcpu. Specifying -march means the code generated will run only on that CPU class. > > Also should clarify in my previous message that using anything other than > > -O (ie -Os or => -O2) with -march tends to make compiling problematic. > >I hear that. I think that the world+kernel should be compiled with >nothing but -O. I've seen beta versions of gcc 2.96 bomb out with an >"internal compiler error" when using -Os => -O3. It should be allowable >to build kernel and world with -march=ARCH, though. Also, I consider gcc Perhaps you missed the point of my clarification. There have been more times when you can get away with either '-O2' or '-march', but '-O2 -march' blows up more often. I agree that -march should work and be allowed. No longer have anything less than a Pentium around and see no reason to generate code that will work on anything less or not be optimized for newer generations. However, we are at the mercy of the gcc developers. >to be a mission-critical app, and I've noticed that when I built gcc with >-Os, gcc sometimes develops some severe memory leaks that aren't there >when you build gcc with -O. For example, when I built gcc with -Os, I ran >out of swapspace when trying to build kdelibs-1.96. I believe the source >file was dcop*.cpp or something or other. I didn't see this gcc memory >leak after I rebuilt the world with -O. By all means, -O should be the >only allowable flag for building world. memory leak != higher memory usage, you should have tried more swap space to be sure before crying "leak!" 8-) >Also, I compared building world with -Os and with -O. A world built with >-O actually used slightly less disk space than with -Os. I think there >are cases when -O3 is desirable, though. I built XFree86 with both -Os >and -O3. The -Os version seemed significantly more sluggish than with >-O3. -O3 seems the best choice for things like mpg123, xanim, and >XFree86. -Os seems like it's more trouble than it's worth, as it doesn't >really reduce the size of the executable significantly more than >-O. Plus, the speed you gain from using -O probably far outweighs the >little disk space/memory usage savings from -Os. I've seen this before when others were comparing various levels. Didn't look in depth at the code for -Os, but it set's optimize_size=1 and according to man page it sets -02 (toplev.c shows this), but leaves out flags that would bloat the size. Didn't dig out which or if in truth it does it (care little about size ;). While egcs was the system compiler, optimizations seem to have worked "as advertised" ( dug up the other messages I was looking for) and -Os worked well. Been a year, since it was in the tree and only spent 7 months there. In short, '-O -pipe' is the only thing worth the time or trouble for the world and kernel. Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.2.20001028101053.00dbc960>