This is the mail archive of the
mailing list for the GCC project.
Re: gcc on Mac OS X
- To: toa at pop dot agri dot ch
- Subject: Re: gcc on Mac OS X
- From: Stan Shebs <shebs at apple dot com>
- Date: Fri, 31 Aug 2001 14:28:10 -0700
- CC: Aurelien <aurelien at fractals dot be>, gcc at gcc dot gnu dot org
- References: <200108311422.f7VEMSg27675@mail-in1.apple.com> <3B8FC072.6D7EEB87@apple.com> <3B8FF7A8.3BF32C10@pop.agri.ch>
Andreas Tobler wrote:
> Stan Shebs wrote:
> > Yes, Apple's cc is based on 2.95.2, but we're working on getting
> > what will be 3.1 working, in expectation of using it in a future
> > release of Mac OS X. The basic compiler, as checked out from the
> > FSF sources, works now (modulo bootstrap-breaking checkins), and
> IOW, still not possible to bootstrap? Well, I wasn't until thiss evening MEST.
I was making a feeble joke. The FSF CVS sources are supposed to
stay in a working state, but in practice, builds break on one or
another platform regularly. I generally try a bootstrap on the
sources every 2-3 days, in hopes of catching bad checkins quickly;
eventually I want to have an Apple machine reporting results to
> I ask again, maybe a person reading this on gcc could help.
> How is it possible to use gdb to track down gcc bootstrap errors?
> Is there a how to around? I searched the gcc side with no luck.
There's no single way to do it, depends on the kind of failure that
occurs. For instance, an internal compiler error (ICE) is simple
to pinpoint, I just cut-n-paste the compile command that failed,
then rerun with -save-temps and -v added. Then I can do "gdb cc1"
(or whichever executable is failing), cut-n-pasting the cc1 args
into the "run" command. Once you've stopped somewhere in GCC, you
can call the functions debug_tree() and debug_rtx() to print out
trees and RTL.
On the other hand, compare failures are hard, because there's
no single failure point. With some dinking with -save-temps,
you can collect the assembly for a file that is different between
stage 2 and 3, then diff the assembly files. After that it's
guesswork to find a GCC routine associated with the differences
in the assembly code. The -da option to dump intermediate
results can be helpful to identify an optimization phase where
the two stages diverge from each other.
I don't know if this is what the GCC bigshots do, but this is the
kind of thing that works for me.