Re: GCC 3.0 Release Criteria

[Chip Salzenberg <chip at perlsupport dot com>]

According to Richard Henderson:
> On Thu, Apr 27, 2000 at 06:42:57PM -0700, Chip Salzenberg wrote:
> > Is this a serious question?  Surely you can't make a serious plan
> > that depends on never having to make an incompatible change?!
> 
> If it means "user visible bug fix", no I don't expect never
> to have to make such a thing.

OK, that's obvious.

> If it means "change an interface without providing a different
> function name" then, no, I don't expect to have to make such a
> change.

But isn't there a third case?  Isn't it possible that an old function
with an old name cannot be provided any longer because it depends on
assumptions that have changed?

For example, stack unwinding for exceptions may not work any longer if
the compiler's definition of the number of hard regs changes.  The x86
target got bit by this a few months ago.  The "fix" was to separate
the number of regs saved from the number of hard regs in the processor
definition.  That happens to work for the x86, but what if it didn't?
Then, if I understand how stack unwinding works, we would be unable to
provide the old interface and make it work.

I can see libgcc.so being like ld.so -- staying compatible for a very
long time, then needing to be upgraded to a new version.
-- 
Chip Salzenberg              - a.k.a. -              <chip@valinux.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K