This is not true (or outdated) see below. -O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.
I thinks only on VAX -fomit-frame-pointer does not affect debugging (I know nothing about VAX, just follow the gcc docs), so basically on all other ARCH -O, -O1 and -O2 (and -O3 ans -Os) do not imply -fomit-frame-pointer Taken from: http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Optimize-Options.html#Optimize%20Options -O1 Optimize. Optimizing compilation takes somewhat more time, and a lot more memory for a large function. With -O, the compiler tries to reduce code size and execution time, without performing any optimizations that take a great deal of compilation time. -O turns on the following optimization flags: -fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize -fcrossjumping -fif-conversion -fif-conversion2 -fdelayed-branch -fguess-branch-probability -fcprop-registers -O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging. -O2 Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. The compiler does not perform loop unrolling or function inlining when you specify -O2. As compared to -O, this option increases both compilation time and the performance of the generated code. -O2 turns on all optimization flags specified by -O. It also turns on the following optimization flags: -fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm -fgcse-sm -fdelete-null-pointer-checks -fexpensive-optimizations -fregmove -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fcaller-saves -fpeephole2 -freorder-blocks -freorder-functions -fstrict-aliasing -falign-functions -falign-jumps -falign-loops -falign-labels > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf > Of Eelco van Beek - IC&S > Sent: Tuesday, October 28, 2003 12:34 PM > To: [email protected] > Subject: Re: [Dbmail] 100% cpu usage with dbmail-pop3d -- > SOLVED, for me > at least > > > > -fomit-frame-pointer > Don't keep the frame pointer in a register for functions that don't > need one. This avoids the instructions to save, set up and restore > frame pointers; it also makes an extra register available in many > functions. It also makes debugging impossible on some machines. > > On some machines, such as the VAX, this flag has no effect, > because the > standard calling sequence automatically handles the frame pointer and > nothing is saved by pretending it doesn't exist. The > machine-description macro FRAME_POINTER_REQUIRED controls whether a > target machine supports this flag. See Register Usage. > > Enabled at levels -O, -O2, -O3, -Os. > > As being told in the gcc man :) > > Eelco > > > On 28-okt-03, at 10:20, Shih Ming-Wei wrote: > > > I don't think -O -O1 and -O2 impliciet -fomit-fram-pointer > > not sure about -O3 > > > > Ming-Wei > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf > > > Of Eelco van Beek - IC&S > > > Sent: Tuesday, October 28, 2003 9:37 AM > > > To: [email protected] > > > Subject: Re: [Dbmail] 100% cpu usage with dbmail-pop3d -- > > > SOLVED, for me > > > at least > > > > > > > > > I thought the stable version was compiled with -O which > automatically > > > enables the omission of frame pointer usage? > > > > > > Best regards, > > > > > > Eelco > > > > > > On 27-okt-03, at 23:08, Bret Baptist wrote: > > > > > > > On Friday 24 October 2003 5:35 am, Shih Ming-Wei wrote: > > > >> hi, > > > >> > > > >> I have solve the 99% CPU usage on Linux/sparc systems that > > > >> we are using, apparently changing CFLAGS from "-O2 -pipe" to > > > >> "-march=v8 -mtune=v9 -O2 -pipe -fomit-frame-pointer" cahnges > > > >> the CPU usage from 99% to max 1.8% (avg 0.4 %). So my > > > >> conclusion is this is not a dbmail bug but dbmail must trigger > > > >> some bug in platform/compiler/glibc, > > > >> > > > >> Just my 2 cents > > > >> > > > >> > > > >> Hope this might help someone else > > > >> > > > >> Ming-Wei > > > > > > > > After more testing I have found that the important bit > here is the > > > > -fomit-frame-pointer. If I define that I don't get the > > > excessive CPU > > > > usage. > > > > Is there any reason for not making this a standard compile flag? > > > > > > > > I am running debian testing (sarge): > > > > > > > > Which has: > > > > > > > > gcc-3.3.1-2 > > > > kernel: 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 > > GNU/Linux > > > > libc6-2.3.2-7 > > > > mysql-client-4.0.13-3 > > > > > > > > Anything else relevant? > > > > > > > > -- > > > > Bret Baptist > > > > Systems and Technical Support Specialist > > > > [EMAIL PROTECTED] > > > > Internet Exposure, Inc. > > > >http://www.iexposure.com > > > > > > > > (612)676-1946 x17 > > > > Web Development-Web Marketing-ISP Services > > > > ------------------------------------------ > > > > > > > > > > > > Today is the tomorrow you worried about yesterday. > > > > > > > > _______________________________________________ > > > > Dbmail mailing list > > > > [email protected] > > > >https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > > > > _________________________ > > > E.J.A. van Beek > > > ICT Manager > > > IC&S > > > T: +31 30 2322878 > > > F: +31 30 2322305 > > > > > > PGP-key: > > > www.ic-s.nl/keys/eelco.txt > > > > > > _______________________________________________ > > > Dbmail mailing list > > > [email protected] > > >https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > > > _________________________ > E.J.A. van Beek > ICT Manager > IC&S > T: +31 30 2322878 > F: +31 30 2322305 > > PGP-key: > www.ic-s.nl/keys/eelco.txt > > _______________________________________________ > Dbmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail >
