This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 3.2 PATCH: Fully support parallel gnat1/gnatbind builds
- From: dewar at gnat dot com (Robert Dewar)
- To: fw at deneb dot enyo dot de, kenner at vlsi1 dot ultra dot nyu dot edu
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 23 May 2002 21:41:32 -0400 (EDT)
- Subject: 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.