From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 15 10:41:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A8BB16A4CE for ; Mon, 15 Mar 2004 10:41:55 -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 B969B43D3F for ; Mon, 15 Mar 2004 10:41:54 -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])MAA06776; Mon, 15 Mar 2004 12:41:14 -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 2004031512420373:139 ; Mon, 15 Mar 2004 12:42:03 -0600 Received: by techpc04.okladot.state.ok.us (Postfix, from userid 0) id 7D59D5C29; Mon, 15 Mar 2004 12:16:25 -0600 (CST) To: "Nikos Ntarmos" From: "Paul Seniura" Errors-To: "Paul Seniura" In-Reply-To: <20040313192357.GA10778@diogenis.ceid.upatras.gr> References: <20040315001052.GA20921@diogenis.ceid.upatras.gr> <20040313192357.GA10778@diogenis.ceid.upatras.gr> Message-Id: <20040315181625.7D59D5C29@techpc04.okladot.state.ok.us> Date: Mon, 15 Mar 2004 12:16:25 -0600 (CST) X-MIMETrack: Itemize by SMTP Server on Notes9c/ODOT(Release 5.0.12 |February 13, 2003) at 03/15/2004 12:42:03 PM,2003) at 03/15/2004 12:42:05 PM, Serialize complete at 03/15/2004 12:42:05 PM cc: freebsd-hackers@freebsd.org cc: Paul Seniura Subject: re: GCC optimization bugs -- still there or a historic artifact? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Paul Seniura List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 18:41:55 -0000 Hi, I was the one starting that question. ;) I'd like to mention what I've done and found so far. Please remember I can only vouch for the Puny Pentium2, since I have no other machine to use here on li'l-endian models. Also I can vouch for GCC-3.3x on my G4 at home, but it is a totally *totally* different system altogether. My earlier question got splintered into several points. My main point was dealing with FreeBSD's ports system Makefiles overriding the author's settings in the original app's Makefile. If the original app's Makefile had set a high -O level, I want FreeBSD to compile it at that same level, stop lowering it, because we are not getting the full benefit that the original author has intended. Another point I want to do: If an app does not have any -O set at all, I want to set it to a default level. Or, to lower it if it is too high (although I have not seen this case). The simple way of setting any CFLAGS in /etc/make.conf is not sufficient. CFLAGS is something that you can put anything into it in a 'free form' way. The simple make.conf can override it or "add to" it, but that's all. I need to be able to scan it to see if there was any -O at all, then be able to change it if it's too high, or to add a default -O if none found to begin with. This needs to be done "very late" before gcc is invoked for each module. Exactly where the Makefile will add your own CFLAGS -- either before or after its own -- is dependent on how other parts of the Makefiles handle it. So yours may override theirs, or theirs take precidence over yours; nothing is predictable. My hack, tho, if ever it will work properly, would scan CFLAGS late enough but before gcc is invoked, and thus ensure predictable settings no matter what. This comes full circle to my first point, that some FreeBSD ports system Makefiles are altering the original settings. If I can get my hack working, their changes would come through *before* I could 'see' the *original* settings. So I wanted the maintainers to stop altering these settings. I did not want the discussion to delve into issues with gcc doing bad things, and I showed that the GNU GCC website does have documentation to help authors deal with known bugs here. If the app runs on i386 using gcc-3.3.3 at a higher -O level under Linux, say, then it ought to work under FreeBSD/i386 as well. You can assume those high -O levels were tested. So I wanted the FreeBSD maintainers to stop altering these settings, to use what the original author has tested. I mentioned in that earlier discussion that I will test MPlayer at -O3, which is the setting of the original author. I can now with certainly say -O3 made a WHOLE LOTTA DIFFERENCE on this Puny Pentium2 PC: it is actually usable now! (at least) I haven't found a way to do my hack yet, though. For the time being, I am sort-of 'forcing' -O2 and -march=pentium2 in the kernel and world builds -- which does help speed them up on this Puny Pentium2. A higher -O3 seems to make some modules get stuck during the gcc compile phase, so that's why I said anything higher can't be trusted on the Pentium platform. As for building ports, if I see an app wanting to build higher than -O2, I will remove my settings and restart the portupgrade to let it use those settings for a trial run. For other ports, they usually have -O set, others have -O2, and many have nothing. I make a judgement: if the app is used very often, or it makes libs that are used a lot, I will try forcing -O2 even if the original makefile is lower. I can say letting KDE use its own settings at -O2, and forcing other pieces to use -O2, makes it run much better overall. I just wish the maintainers would stop changing these settings coming from the original projects, so we system admins can have control over how things are compiled. N.B. This is good for the Puny Pentium2 machine "they" let me use here at work. ;) I have no idea on other/higher versions of the Pentium. And as for PPC, I've compiled things as high as -O5, which is its limit I believe. ;) Since the G4 is an entirely different animal, tho, you cannot compare it to other such vastly different platforms. -- thx, Paul Seniura. >--- Original message ---< Hi all. There was a thread on the CFLAGS knob in make.conf in early Feb.'04 (the exact subject was "need help on CFLAGS in /etc/make.conf please"), where some posters raised the issue of gcc optimization bugs that supposedly manifest in optimization levels above -O2. The last post on this subject was on Feb. 13th, though, and nothing has come up ever since. AFAIK 5.2.1+ and -CURRENT have moved to gcc-3.3.3. Are these issues still there? I've been making my way around FreeBSD's and GCC's gnat and couldn't find anything relevant. Ummm... Actually almost all relevant entries in our gnat end with something like "bug the gcc guys for we're too overwhelmed to look into gcc issues". The funny thing is there is no entry in the gcc's gnat about optimization bugs in 3.3.3. As some very specific person noted, "-O gets about an order of magnitude less testing than -O2" by the gcc community. This whole thing came up in the port-alpha@netbsd list, in a thread about Compaq's C compiler (aka ccc) for linux/alpha (lang/compaq-cc in our ports tree) and its status in NetBSD. The manpage for make.conf states that the issues with levels >1 are even worse on alpha. Well, gcc-3.3.3 is as fast as (if not faster than) ccc for optimization levels above -O2, and can be used for a much wider part of the C/C++ source available out there. So the question is: are these gcc issues still there or just a historic artifact left lurking around manpages "just to be sure"? \n\n -- Nikos "Noth" Ntarmos | < ntarmos at ceid dot upatras dot gr > NetCINS Lab. @ C.E.I.D. | [ http://{noth,p2p}.ceid.upatras.gr/ ] U. of Patras - Greece | ( 38.2594N, 21.7428E ) ( 1024D / CF95160A )