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: Ada policy


Zack Weinberg wrote:

This discussion is about appearances as well as actuality. Can you at
least agree that a reasonable person could reach my position?

What? Your position that we said we intended to deliberately break things? No, I don't see how anyone could reach that conclusion. Sorry. If you are simply saying that the message says we do not guarantee to boostrap with arbitrary old versions of GNAT, yes, that's the case.

The interesting thing here is that we have virtually no reports
of people having difficulty in practice bootstrapping Ada on all
sorts of targets where the difficulty arises from this consideration.
Seems a bit of a tempest in a teapot to me.

Yes, there was the discussion of trying to use incompatible
versions with different exception handling. That's an unsolvable
case, or at least the solution would require a lot of recoding and
introduction of inefficiencies to no very good purpose.

That is,
maybe ACT has never actually broken using an older GCC to bootstrap
the Ada front end, but can you understand how I and others have come
to the conclusion that your policy was not to keep it working?

There is a BIG difference between your unjustified claim that we deliberately break things, and our position that we try to keep the bootstrap working with old versions of the compiler, but do not guarantee to do so.

It is *certainly* not the case that any old arbitrary GNAT can be
used (there are dozens of versions stretching back over 13 years
after all!)

A further step forward would be to state which older versions those
are, what your policies are for selecting those older versions, and
when the set might change.

Please answer this question.

I will answer this later, I don't have this info at hand right now. Basically the policy is to try to keep compatibility to the greatest extent possible, but if it is necessary to fix some bug in the compiler to break an old version, we may do so. A possible case is when fixing a bug changes the compiler sources in a way that aggravates some other bug in an earlier version of the compiler, and no work around can be easily found. This is very rare, but has happened at least once in the last decade.

You did not reply about your pragma Unreferenced misunderstanding.
I trust you are clear on this issue, and your mistake here???

You responded to the pragma Unreferenced citation by stating that
pragma Unreferenced was not actually used in the compiler proper.
That is new information.  It was not in the message I cited.  Can you
understand how a reasonable person, working from the information in
that message, could have thought that the Ada maintainers planned to
introduce uses of pragma Unreferenced into the compiler proper?

Possibly so, but I was reacting to your claim that you had examined the sources and found deliberate violations of the rule, which is quite wrong and represented a misunderstanding of the technical situation. I suggest you review the way Ada is built so that you can understand this point in more detail. Basically the point is that the run time (*) and tools are always built with the newly constructed compiler, so bootstrap path problems do not apply to these components. When you scanned the compiler sources for pragma Unreferenced, you found a long list of uses, but all in the run time and tools. You then jumped to a conclusion that this was proof of our deliberately breaking things. That was a bit too rapid a jump :-)

(*) That's not quite complete, since some run-time components (see
makefile) are in fact used in the compiler, and these have to be
treated with special care, since they have to be compatible with
both the starting and ending versions of the compiler (this is
why we severely limit the set of run time units used).



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