This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: default EH to being on for cleanups
- To: mrs at wrs dot com
- Subject: Re: default EH to being on for cleanups
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Fri, 18 Dec 98 19:49:46 EST
- Cc: egcs-patches at cygnus dot com, gcc2 at gnu dot org
This is too general. I prefer to think of it as, old front ends that
have exception handling that don't use EH from gcc. And my answer is,
well, they are broken and need to switch to use EH from gcc.
Why? If the language doesn't use exceptions, why should the front end
need to be modified for a newer gcc?
Your question when reworded is, what is the point of putting in EH in
the backend, if the sole purpose appears to require every front end
developer to have to recode their existing front end to use the
backend?
No, the purpose is to provide a common code base for supporting EH in
languages that support it. From the point of view of GCC, Ada is a
language that doesn't support exceptions. In that case, it should
continue to work. If we have a language that *does* support exceptions,
that language needs to contain the code to implement exceptions by
making the appropriate EH calls to the core compiler. One of those calls
is an initialization call that says "I'm EH-aware".
The question is why should we force every new language being developed
in the correct way to have to put in obsure calls to obsure functions
that they can't guess at for their langauge to work.
I have no problem documenting the call.
This is too much work, I don't want to complicate the job of writing a
new language front end, do you?
By adding *one line* of code?
I accept the slam of complicating our lives by requiring Chill and Ada
to call one function, so that other don't have to. I stand by the
tradeoff.
You miss the point. The major problem in your suggestion is that that
function doesn't exist in current versions of either EGCS or GCC2.
That means that you can't have a front end that will work with both
the current and the next versions of those compilers: you'll need a
different one for each core compiler version. And that produces a
very serious compatibility issue between the core compiler and front
end versions.