This is the mail archive of the 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] Patch to fix bug reporting instructions (3.1 branch)

On Thu, 2 May 2002, Robert Dewar wrote:

> To me these cases are a little bit similar, and it seems a mistake not to
> recompile libiberty with a consistent compiler.

Bootstrapping libiberty would be desirable (once bootstrap has been moved
out to the top level) - the point is that, though there are occasional
problems with it not being done, mostly it works.

> Joseph, I assume you are an Ada user (otherwise I have trouble understanding
> this intense interest in this one issue, can you be more clear as to why you
> think this is such an important issue?)

I think that having language front ends included with GCC is generally
desirable for improving the core compiler quality - and when there's an
Ada testsuite included, that will increase the usefulness of having Ada
there.  For this to achieve its maximum value, all the front ends should
be routinely built and tested by people (and automated regression testers)
without a specific interest in all the languages.  For people without a
special interest in Ada to build and test it anyway, additional special
requirements to build it should be avoided where possible in favour of
building on out-of-the-box operating system installs (where someone need
only, perhaps, install a GNAT package with their usual package management
system).  (For example, it's been said that automated regression testers
should generally be a well-defined, documented, reproducable
out-of-the-box install.)  To get the maximum number of people building and
testing the compiler, and routinely including all languages (and then
possibly trying the various languages, now that they have compilers for
them installed), I don't think *artificial* constraints should be placed
on the build environment.  Disallowing environments where there's a known 
technical reason why they won't work is one thing, disallowing widely used 
environments that work for many people based on a supposition that perhaps 
they might not produce a working compiler is another.  The only known 
technical issue with gnatgcc has been dealt with.  Could someone who 
believes gnatgcc is a bad way to bootstrap 3.1 please produce some 
evidence to support this?  That is:

* On an install of such-and-such version of such-and-such free operating 
system, building with the provided bootstrap binaries for both C and Ada 
yields an Ada compiler with such-and-such test results.

* On an install of the same system, but with the system GNAT package 
gnatgcc used for Ada and the system gcc used for C, an Ada compiler is 
yielded with such-and-such (worse) results.

Without such evidence, claims that it *might* be bad, that there *might*
be ABI incompatibilities, seem like FUD, and don't seem to me a good
reason to undocument use of gnatgcc or remove configure support for it.  
Apart from the exception handling problem - which has been worked around -
I recall no objections to gnatgcc for which evidence was given that
problems were real.

Joseph S. Myers

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