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]

Re: Solaris bootstrap failure


> Date: Tue, 6 Mar 2001 23:27:23 -0500 (EST)
> From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>

> Any other ideas?

The standard technique of binary searching with cvs and full
bootstraps will tell you exactly what triggered it.  Though, as we
might guess now, that probably isn't the real bug.

If you modify the compiler used to be one that squirrels away the
complete environment, and the entire command line, and does -E on the
input file, and squirrels that away too, and a staging process that
stages those intermediate files as well, you might just be able to
observe it in action.

Last time I saw one of these, someone had introduced a bit of non
initialized stack.  :-(

Another way that might allow one to observe this type of problem is to
build on tons of different hosts, and compare the output between the
hosts for the same target, on the same code.  Doing this for a full
range of inputs is best, as often, it will only be a smaller
percentage of files that trip it up.

Bear in mind, binutils can also cause these types of problems, even
with identical .s files.  I've seen that too.  To narrow is done, one
can try a different binutils with a known to fail botstrap.

And my last thought, with some luck, the binary searching for the
first instance of bootstrap failure, might lead to the actual code
that is broken.


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