This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)


    So the stage1 compiler is built as a 32-bit object, from the second 
    stage on they're built as 64-bit objects.

Very bad idea!  I don't think we should support that.

The whole point of bootstrapping is that all of the stageN compilers should
behave identically and GCC simply doesn't do that if one is built with 32-
and 64-bit (we come close if HOST_WIDE_INT is 64, but we don't guarantee
that) and a critical key to debugging bootstrap problems is to be able to run
the debugger on each of the stages and see where they differ.  If they're
*supposed* to differ, that process stops working.

    Why can't you execute make bootstrap in the toplevel?

Because it does more than I want!

    What I do is working on a fix in the stage1 directory, and then doing 
    (depending on the kind of bug and fix) "make unstage1; make restrap" or 
    "make bubblestrap".

I'm not familiar with the "restrap" or "bubblestrap" targets.

    Are you doing things differently?  (This is not kidding; maybe there's 
    some fundamental misunderstanding).

I build the stage1 compiler and run my test cases there, working in the gcc/
directory.  Then, when I think things are looking good, I do a "make
bootstrap".  If that succeeds, I go on ("make gnatlib_and_tools", "make
check", etc.).  If not, I find a testcase that the bootstrap showed is
broken, "make unstage1" and work on getting that testcase to pass.  Then I
"make bootstrap" again.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]