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: 3.2 PATCH: Fully support parallel gnat1/gnatbind builds


>Why is this dependency on builtin setjmp/longjmp desirable?

The point is that if the compiler compiling itself raises any exceptions
then the dependency will occur. The question is: is it worth having an
odd otherwise unncecessary restriction on the way the compiler is coded,
just so that some odd and in any case non-recommended approach to the
build happens to work.

We made the change to eliminate the exception in the current compiler, 
because in fact it was a symptom of a (harmless) bug, and was desirable
to fix in any case.

It may be that we don't ever introduce exceptions into the normal
bootstrap path, and perhaps that is desirable in any case though
I am hesitant to make it an absolute rule. 

But in general, what if we find other cases where placing some restriction
on the compiler code throughout "fixes" some anomoly caused my mixing
incomaptible compilers.


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