This is the mail archive of the gcc-patches@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: default EH to being on for cleanups


    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.


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