search for: gt_gcc

...rash building something that's part of MacOS, and yes, that's more important than Fortran. But it should be possible to get Fortran to build. I would think the right idea is to change the build so that either darwin-c.o gets linked in (theoretically wrong but it should work), or (better) gt_gcc–r_gt_darwin_c_h is not referenced in Fortran. It appears to be configured into gtype-fortran.h, which is generated during the build, so the thing would be to get it not to go in there....I'm not that expert with the GC mechanism, but I can play around a little.... > On Apr 8, 2010, at 6:25...

[CCing Dale since this was his change, not mine] The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets

On Wed, Apr 07, 2010 at 09:54:36PM -0700, Chris Lattner wrote: > > On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote: > > > Building the current release 2.7 branch on x86_64-apple-darwin10 > > with r81455 reverted, I get the following Polyhedron 2005 benchmark > > results (with no test failures)... > > Very nice! A 14% speedup on a benchmark we don't tune for