>>>>> "Oliver" == Oliver Kellogg <oliver.kell...@t-online.de> writes:
Oliver> As mentioned, I'm still struggling with leftovers being carried Oliver> over from compilation 1 to N-1 into compilation N of a compile Oliver> job. gcc_free'ing things (in combination with "configure Oliver> --enable-checking=gc,gcac") helps me track down objects that Oliver> should have been reset. This is ok as an approach to development but probably not ok for a real patch. If you look on the incremental branch you can find various places where I added new functions to clean up modules before a new compilation job is run. This fills a similar need, if I understand your problem correctly. I did this in an ad hoc way, just resetting the modules I needed, so I don't know whether or not the particular changes will be of use to you. Oliver> A next step after that may be to look at Tom Tromey's Oliver> incremental- compiler branch and see whether it is possible to Oliver> integrate my changes there. I would be looking at running the Oliver> incremental compiler in a serverless mode more similar to the Oliver> way GCC works now, where trees are constructed and shared only Oliver> within a single compile job (i.e. the backend is called only Oliver> once but with many files as the argument list, and the trees are Oliver> only reused throughout the compilations of these files but do Oliver> not continue to exist beyond the backend invocation lifetime.) This sounds like the --combine switch on trunk. The incremental compiler work is mostly orthogonal to --combine. The C front end changes improve --combine performance, and I used --combine as a testbed, but I didn't touch the --combine infrastructure itself. (I think these changes would help with LIPO, too, but I haven't really looked into it.) If you wanted your modified compiler to emit separate object files for a --combine run, then yeah, you would need something like a hybrid between the compile server from the incremental branch and --combine. This is doable, maybe even easy. Tom
