Date: Thu, 29 Jul 2004 15:44:14 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Paul Seniura <pdseniura@techie.com> Cc: Scott Long <scottl@freebsd.org> Subject: Re: about the gcc 3.4.x problems Message-ID: <20040729204413.GA5313@dan.emsphone.com> In-Reply-To: <20040729193724.E8CC95C11@techpc04.okladot.state.ok.us> References: <20040729174420.GA9911@dan.emsphone.com> <20040729193724.E8CC95C11@techpc04.okladot.state.ok.us>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jul 29), Paul Seniura said: > I've been building kernel+world and most apps with -Os and the > -Current system gcc for many months and continuing even today (if/when I > can kick off another system build, too). > > After backing off the tests with lang/gcc34, we discovered a bug with > system gcc -Os and XFree86 libs. I have a CFLAGS+=-O2 override in that > Makefile now. ;) Filed a PR? Developers can't fix bugs they don't know about. PRs are also a lot easier to find later on than a mailinglist post. > Yesterday right here on this list someone said he hit a -Os bug after he'd > CVSup'd and used the new system gcc. So my mind is going "oh no here we > go again... it should've been fixed." That one is caused by gcc 3.4 optimizing out the weak pthread symbol references. It had no idea they were there because they were inside an asm() block. The gcc 3.4 release notes explicitly mention this and provide __attribute__((used)) to force symbols to be kept even if unreferenced from C code. It doesn't happen with -O because 3.4 doesn't eliminate unused symbols at that optimization level, so it's not a high-prority problem. > That earlier point-release of lang/gcc34 went final, but we never got a > final version of it. -Os was a hot item at the GCC site such that it > should've been fixed on that final point-release (3.4.1 IIRC). > > Instead our lang/gcc34 port today is _another_ later point-release snaphot > (3.4.2). BTW I can't start building kernel+world just yet to see what the > new system gcc says. > > Now today I am completely perplexed: did the GCC team actually ever fix > that known bug, do _we_ have that fix in any of the three gcc (system & > two ports), or did the "FreeBSD system gcc custom patches" break it? If it's a known gcc bug, chances are it's in gcc's bugzilla database and you can just look it up and find out. > It's making me paranoid, not being able to trust our most basic tools. > I'm so nervous this time 'round that I'm doing full system backups before > even starting the buildworld. ;) I've sweated thru a lot of -Current > changes since last October, but this one really has me worried. Not that > it might break, but that we had actively tried to test it way in advance, > and be seemingly ignored in our reports here, because yesterday's post > mentioned hitting a -Os bug again after CVSup'ing the new gcc. "Oh no > here we go again..." If you mean "here we go again, people reporting problems with unsupported compiler options", then yes :) Stick with -O unless you want to submit patches to fix the places in our code that need to be cleaned up for higher -O levels. > >I also suspect it's just a timing thing. Apple is intensly interested in > > precompiled headers and other compiler speedups because their system > > uses a lots of complex templates. 3.5 is supposed to be the "go-faster" > > release. > > Yes Apple did say Tiger will be available in the first half of next year. > They got 11 more months. ;) > > The speedups were felt everywhere when upgrading from Jaguar to Panther. > I'm on record here surmizing part of the speedup could be due to -Os, as > that will tighten loops to fit inside L1/L2 caches (G4 Sawtooth at home). > -Os definitely helps this puny pentium2, too, more than -O2. > > For other apps esp. mplayer, I will make sure they get -O3 and the -f > tweaks. Both here & at home. I'm talking about speedups to the compiler itself. If you compare the compile time of gcc vs icc (or the native compiler on most other platforms), it's a lot slower. Things like precompiled headers do absolutely nothing to the speed of the resulting executable, but when a source tree has a thousand C++ files, all of them using the same set of C++ templates, it's a big win. If you want fast executables, use icc :) -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040729204413.GA5313>