On Fri, Apr 29, 2005 at 12:05:03PM -0400, Ian Lance Taylor wrote: > The way to help this process along is to report bugs at > http://gcc.gnu.org/bugzilla. > > In particular, if you provide a set of preprocessed .i files, > from, say, sys, libc, or libcrypto, whichever seems worst, and > open a gcc PR about them, that would be a great baseline for > measuring speed of compilation, in a way that particularly > matters to NetBSD developers. > Yes, .i/.ii files in bugzilla help enormously. What I and other have done is harvest these pre-processed files from bugzilla and stick them in our local test directories.
When I add new features or fix bugs, I will run the clean and patched compiler through those files to make sure nothing has regressed significantly (or even better, it's progressed). That's at least a good smoke screen test. But having preprocessed code attached to a bugzilla PR is of absolutely essential. Without that, we won't be able to fix the problem. This is essentially how we fixed all the memory and performance problems in DLV (PR 8361). Gerald is also kind enough to poke us every time we make 8361 rear its ugly head again. Diego.
