Re: Ada policy

Re: Ada policy

[Richard Kenner]

    This discussion is about appearances as well as actuality.  Can you at
    least agree that a reasonable person could reach my position?  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?

You have the quantifiers wrong.  The statement was that there was no
*guarantee* that it would work with older version, that there was the need
for freedom to allow it not to work with arbitrarily old versions.  That
doesn't mean there was a plan to purposely break it, just the reality 
that the cost of having it be compilable by arbitrarily-old versions
may be more than the benefits of doing so at times.

Re: Ada policy

[Zack Weinberg]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     This discussion is about appearances as well as actuality.  Can you at
>     least agree that a reasonable person could reach my position?  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?
>
> You have the quantifiers wrong.  The statement was that there was no
> *guarantee* that it would work with older version, that there was
> the need for freedom to allow it not to work with arbitrarily old
> versions.

Yes, you and Robert keep saying that that is what you said.  Prior
experience indicates that I put the cost-benefit break point in a
different place from you, but I'm not planning to argue about it
except in the unlikely event that it actually bites me (again).

What I am trying to get across, though, is that reasonable people
could - did - read something different in the messages that I quoted.
Understand them to mean that compiling GNAT from GCC 3.x with
something other than GNAT from GCC 3.(x-1) had a very high probability
of not working, and further that this was not considered a bug, or
even an inconvenience.

That is a little different from 'a deliberate policy of breaking
source compatibility between releases', I admit.  I think that a
reasonable person could reach that conclusion too, but only having
read messages which I remember reading but cannot presently find in
the archives.

zw

Re: Ada policy

[Kai Henningsen]

zack@codesourcery.com (Zack Weinberg)  wrote on 30.08.04 in <87acwc3qq6.fsf@codesourcery.com>:

> That is a little different from 'a deliberate policy of breaking
> source compatibility between releases', I admit.  I think that a
> reasonable person could reach that conclusion too, but only having
> read messages which I remember reading but cannot presently find in
> the archives.

Hmm. I certainly seem to remember reading those messages, too. Not that it  
were a plan to always break compatibility, but that incompatible features  
were pretty much always introduced and they wanted to use them in the  
compiler, which then produced that incompatibility; and as long as the  
previous version was still compatible, that was not considered a problem.

And that in fact only-the-previous-version had been true for a large  
number of versions.

Hmm ... this seems relevant:

http://gcc.gnu.org/ml/gcc/2002-03/msg01197.html
http://gcc.gnu.org/ml/gcc/2002-03/msg01245.html
http://gcc.gnu.org/ml/gcc/2002-03/msg01268.html

... and probably more in that thread.

It seems completely obvious from that thread that ACT's ideas of how much  
old version bootstrap compatibility was worth, was vastly different from  
either the FSF's, or the one described in the current thread (that is,  
lots of old versions used to check exactly that internally).

Furthermore, there's mention of a plan to document which versions work for  
3.1 or the next version. We have 3.4 out, and now it seems we finally get  
such a list ...

(I wonder if I should also mention the "either take our contributions the  
way they are, or we'll take our toys and go home" thing ...)

MfG Kai

Re: Ada policy

[Robert Dewar]

Kai Henningsen wrote:

> Hmm. I certainly seem to remember reading those messages, too. Not that it  
> were a plan to always break compatibility, but that incompatible features  
> were pretty much always introduced and they wanted to use them in the  
> compiler, which then produced that incompatibility; and as long as the  
> previous version was still compatible, that was not considered a problem.
> 
> And that in fact only-the-previous-version had been true for a large  
> number of versions.

That's just not true. GNAT has been able to be built from 3.13 for
many years (3.13 was released several years ago). We only introduce
incompatibilities if we really need to for some significant cleanup
or kludge removal. Earlier on that was more common, but we have not
needed to do that for many years now.

Re: Ada policy

[Florian Weimer]

* Robert Dewar:

> That's just not true. GNAT has been able to be built from 3.13 for
> many years (3.13 was released several years ago). We only introduce
> incompatibilities if we really need to for some significant cleanup
> or kludge removal. Earlier on that was more common, but we have not
> needed to do that for many years now.

I wonder why it's not possible to disable some aspects of -gnatg when
building the stage1 compiler.  If there was such an option, you might
be able to do some cleanups (like instrumenting the code with more
precise pragmas to control warnings) without requiring newer compiler
versions to bootstrap.

Re: Ada policy

[Robert Dewar]

Florian Weimer wrote:

> * Robert Dewar:
> 
> 
>>That's just not true. GNAT has been able to be built from 3.13 for
>>many years (3.13 was released several years ago). We only introduce
>>incompatibilities if we really need to for some significant cleanup
>>or kludge removal. Earlier on that was more common, but we have not
>>needed to do that for many years now.
> 
> 
> I wonder why it's not possible to disable some aspects of -gnatg when
> building the stage1 compiler.  If there was such an option, you might
> be able to do some cleanups (like instrumenting the code with more
> precise pragmas to control warnings) without requiring newer compiler
> versions to bootstrap.

We can consider that sort of thing if we run into it, but as I noted,
we can now bootstrap with very old versions of the compiler (3.13 was
released in the middle of 2000, so over four years ago). I don't think
there is any point at this stage in trying to make it work with older
versions, and at the same time, we don't see any problems in maintaining
the compatibility with 3.13 at least for now. If problems come up we
can discuss them then.

Meanwhile, I really think this is a non-issue. No one has ever had
trouble from trying to use a too-old version of GNAT to bootstrap
that we are aware of.

Re: Ada policy

[Florian Weimer]

* Robert Dewar:

> Florian Weimer wrote:
>
>> * Robert Dewar:
>>
>>>That's just not true. GNAT has been able to be built from 3.13 for
>>>many years (3.13 was released several years ago). We only introduce
>>>incompatibilities if we really need to for some significant cleanup
>>>or kludge removal. Earlier on that was more common, but we have not
>>>needed to do that for many years now.
>> I wonder why it's not possible to disable some aspects of -gnatg when
>> building the stage1 compiler.  If there was such an option, you might
>> be able to do some cleanups (like instrumenting the code with more
>> precise pragmas to control warnings) without requiring newer compiler
>> versions to bootstrap.
>
> We can consider that sort of thing if we run into it,

No, you can't, unless you've got a time machine.  The Ada compiler
which builds the stage1 compiler must support this option.  You must
add it in advance, otherwise it won't be there when you need it.

Re: Ada policy

[Robert Dewar]

Florian Weimer wrote:

>>We can consider that sort of thing if we run into it,
> 
> 
> No, you can't, unless you've got a time machine.  The Ada compiler
> which builds the stage1 compiler must support this option.  You must
> add it in advance, otherwise it won't be there when you need it.

Sorry, I don't see the point. You can perfectly well override anything
you don't like in -gnatg with command line options, nothing special is
required in the compiler as far as I can see.

Perhaps I don't understand your concern, please say what you mean by
"some aspects of -gnatg".

If you are only concerned with warnings, you can always use -gnatwn

Actually for the compiler itself, you can probably just omit -gnatg
(never tried it, but it would probably work fine).

Please be more specific about what you have in mind, since I just
don't see anything that would be useful here.

Re: Ada policy

[Florian Weimer]

* Robert Dewar:

> Florian Weimer wrote:
>
>>>We can consider that sort of thing if we run into it,
>> No, you can't, unless you've got a time machine.  The Ada compiler
>> which builds the stage1 compiler must support this option.  You must
>> add it in advance, otherwise it won't be there when you need it.
>
> Sorry, I don't see the point. You can perfectly well override anything
> you don't like in -gnatg with command line options, nothing special is
> required in the compiler as far as I can see.

Sorry, I missed -gnatwn.  It even makes style check failures
non-fatal.  Apparently, it is indeed sufficient to add "-gnatwn" when
we hit bootstrap failures due to the problems I alluded to.

Re: Ada policy

[Robert Dewar]

Florian Weimer wrote:

> Sorry, I missed -gnatwn.  It even makes style check failures
> non-fatal.  Apparently, it is indeed sufficient to add "-gnatwn" when
> we hit bootstrap failures due to the problems I alluded to.

It would still be interesting to know what bootstrap failures
you are encountering in more detail (beyond an "allusion" :-)

Re: Ada policy

[Florian Weimer]

* Robert Dewar:

> Florian Weimer wrote:
>
>> Sorry, I missed -gnatwn.  It even makes style check failures
>> non-fatal.  Apparently, it is indeed sufficient to add "-gnatwn" when
>> we hit bootstrap failures due to the problems I alluded to.
>
> It would still be interesting to know what bootstrap failures
> you are encountering in more detail (beyond an "allusion" :-)

As I told you, I missed -gnatwn.  All the breakage I previously
thought to be unavoidable can very likely address by enabling this
switch during bootstrap (as soon as it becomes necessary).  At least
my tests with unrecognized pragmas and style check failures suggests
that.

Re: Ada policy

[Robert Dewar]

Florian Weimer wrote:

> As I told you, I missed -gnatwn.  All the breakage I previously
> thought to be unavoidable can very likely address by enabling this
> switch during bootstrap (as soon as it becomes necessary).  At least
> my tests with unrecognized pragmas and style check failures suggests
> that.

Are you saying you were trying to use a version of GNAT before
3.13. If so, that's really stretching it, and I doubt it will
work, even with -gnatwn.

Re: Ada Policy

[Richard Kenner]

    FYI, my work on separate libada has stalled *because* Ada didn't
    (maybe still doesn't, for all I know) bootstrap on mainline.  This
    made it impossible to test whether I'd broken anything.

At the moment, I believe it bootstraps, but can't build the library.  There
are patches I've done to fix some of the library problems, but Arno can't
commit them because he can't do a successful library build due to middle-end
problems.  I think two of them have been fixed, but I think one remains.
I'm going to try to pin down the exact status on Monday.

Re: Ada Policy

[Nathanael Nerode]

Zack Weinberg wrote:

>The last time this came up, I posted a list of requirements which I
>consider non-negotiable prerequisites for the community at large being
>required to test Ada when they are not specifically working on it.
>This list received no commentary whatsoever, and no progress has been
>made toward meeting any of the requirements except the separate libada
>(which seems to have stalled).
>
>http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

FYI, my work on separate libada has stalled *because* Ada didn't (maybe still
doesn't, for all I know) bootstrap on mainline.  This made it impossible
to test whether I'd broken anything.

-- 
This space intentionally left blank.

Re: Ada policy

[Robert Dewar]

Joe Buck wrote:

> Perhaps I've been blaming the trouble I've had on the wrong issue, but
> I've had much more trouble with Ada build failures than your message would
> indicate, to the point where I only build Ada on recent GNU/Linux systems
> with a very recent prepackaged gnat.

I would guess that the problems are more likely to be makefile related

Re: Ada policy

[Robert Dewar]

Joe Buck wrote:

> Perhaps I've been blaming the trouble I've had on the wrong issue, but
> I've had much more trouble with Ada build failures than your message would
> indicate, to the point where I only build Ada on recent GNU/Linux systems
> with a very recent prepackaged gnat.

Well by all means report details, so we can figure out what's going on!
We build GNAT from 3.13 every night, so it really can't be a matter of
recent incompatible changes per se.

Re: Ada policy

[Richard Kenner]

    Perhaps I've been blaming the trouble I've had on the wrong issue, but
    I've had much more trouble with Ada build failures than your message
    would indicate, to the point where I only build Ada on recent
    GNU/Linux systems with a very recent prepackaged gnat.

Well, what were you using before?  Certainly some of the older systems
had a mixed versions of Ada and C that would cause EH problems, especially
since there was stuff put into the configury that purported to support
that (I was always against that stuff since I think it never worked).

So the issue wasn't the age of the version of GNAT, but whether the package
on the system was properly built.  It should not be a surprise that
you can't build it from an improper package, though it is unfortunate
that there was a time when a lot of them existed.

Re: Ada policy

[Joe Buck]

On Wed, Sep 01, 2004 at 04:21:02PM -0400, Robert Dewar wrote:
> Joe Buck wrote:
> 
> > What bothers me (and what prevents me from doing testing of Ada) is not
> > that GNAT won't compile with proprietary Ada compilers, but that a
> > specific release of GNAT will only compile with certain very specific
> > other releases of GNAT, and that this changes all the time.  That makes it
> > very hard to build.
> 
> This really is not the case, there has been no change in the set of
> GNAT compilers that can be used to start a build for over four years.
> Any version 3.13 or later should work fine.

Perhaps I've been blaming the trouble I've had on the wrong issue, but
I've had much more trouble with Ada build failures than your message would
indicate, to the point where I only build Ada on recent GNU/Linux systems
with a very recent prepackaged gnat.

Re: Ada policy

[Robert Dewar]

Joe Buck wrote:

> What bothers me (and what prevents me from doing testing of Ada) is not
> that GNAT won't compile with proprietary Ada compilers, but that a
> specific release of GNAT will only compile with certain very specific
> other releases of GNAT, and that this changes all the time.  That makes it
> very hard to build.

This really is not the case, there has been no change in the set of
GNAT compilers that can be used to start a build for over four years.
Any version 3.13 or later should work fine.

> If GNAT relies on extensions, and the extensions that it relies on
> constantly change, it makes life very difficult for builders and testers.

That's simply not the case, there have been no such changes for four
years. If you have found life "very difficult", I don't see that it can
be because of constant changes which have not in fact occurred. Could
you try to be more specific about your particular experiences. Perhaps
there are completely unrelated problems that should be addressed.

> One way to avoid this, it seems, would be to try to use only standard Ada.
> This would permit other Ada compilers to compile GNAT, but that's not the
> point; the point is to lessen the bootstrap problem.  You have chosen
> otherwise, and I don't know enough to say with any confidence whether this
> is a mistake, just that there is a price for it.

We have no reports of bootstrap problems arising from inability to use
earlier versions of GNAT. We did have a couple of reports of difficulties
from trying to use incompatible versions of C and Ada (which had to do
not with extensions or anything like that, but rather with different
models for handling of exceptions).

I am not sure that using only standard Ada would in fact help much, since
in the past, the problems have come from bugs in earlier versions of GNAT.
That's a long time in the past now (over four years as per the above). I
don't know for sure that the current GNAT will not build with 3.12, since
we don't test with versions that early. Note that the set of compilers
that can be used includes all FSF versions.

Re: Ada policy

[Joe Buck]

On Wed, Sep 01, 2004 at 02:19:45PM -0400, Robert Dewar wrote:
> To try to get this a bit back on track .. I would like to ask the question
> of why Zack and perhaps some others think it would be desirable if GNAT 
> could be compiled with other proprietary Ada compilers. I really have not
> been able to understand any reason why this would be desirable.

What bothers me (and what prevents me from doing testing of Ada) is not
that GNAT won't compile with proprietary Ada compilers, but that a
specific release of GNAT will only compile with certain very specific
other releases of GNAT, and that this changes all the time.  That makes it
very hard to build.

If GNAT relies on extensions, and the extensions that it relies on
constantly change, it makes life very difficult for builders and testers.

One way to avoid this, it seems, would be to try to use only standard Ada.
This would permit other Ada compilers to compile GNAT, but that's not the
point; the point is to lessen the bootstrap problem.  You have chosen
otherwise, and I don't know enough to say with any confidence whether this
is a mistake, just that there is a price for it.

Re: Ada policy

[Robert Dewar]

To try to get this a bit back on track .. I would like to ask the question
of why Zack and perhaps some others think it would be desirable if GNAT 
could be compiled with other proprietary Ada compilers. I really have not
been able to understand any reason why this would be desirable. Let's assume
that

a) it would be quite a bit of work to make this so
b) no one would test it (certainlynot us, since we don't even have these
     expensive proprietary compilers, let alone time to fiddle with them).
c) it would somewhat reduce efficiency, maintainability and readability
     but not to a disabling degree

So these are the negatives, what exactly are the positives, or is this
discussion without practical aim?

I understand that Zack is disappointed, but I am not sure that is enough to
even consider making this change :-)

Certainly I can think of a lot (to me) more productive use of time.
If indeed no one is really suggesting this change, then I would suggest
we drop this particular aspect of "Ada Policy" and concentrate on other
issues.

Re: Ada policy

[Robert Dewar]

It must be some other dewar who said

> "we do it this way because  
> the other way is not practical"

With respect to using portable Ada for large
projects. I said nothing of the kind. Yes of
course it would be practical to write GNAT in
portable Ada. It would also be practical to write
it in C++, but that does not mean it would be a
good idea in this case.

The bogus logic is to assume the following
syllogism which doesn't just have a divided
middle, it has no middle :-)


GNAT is written in non-portable Ada
GNAT is a large project
Therefore it is impractical to write large projects
  in portable Ada.

I have given lots of arguments and discussion to tell you
why we decided to use GNAT extensions in writing GNAT. Nowhere
among these arguments and discussions is any hint that one of
the reasons was that it was impractical to use portable Ada!

Re: Ada policy

[Kai Henningsen]

dewar@gnat.com (Robert Dewar)  wrote on 31.08.04 in <4134C6C4.5090103@gnat.com>:

> You have a strange way of jumping to extremely odd conclusions.

Actually, Zack's conclusions seem far more logical to me than your  
arguments.

> No one ever said that it is not practical to write a large complex
> piece of software in standard Ada, and yet you conclude from our
> quite deliberate choice here that this is not practical.

You have a very strange way of switching from "we do it this way because  
the other way is not practical" to "we do this deliberately" to "how dare  
you say we do this deliberatly, it is the only practical way" to ... and  
so on.

MfG Kai

Re: Ada policy

[Robert Dewar]

Geoffrey Keating wrote:

> 1. Since the Ada compiler cannot be bootstrapped from most system
>    compilers, it must be at least as easy, if not easier, to
>    cross-compile it from a system which does have GNAT installed.  At
>    a minimum, it must be possible to easily build a cross Ada compiler
>    for the other system, even when the other target is a host
>    (including hosts for which binutils is not readily available, like
>    AIX and Darwin), and then use that to build a native Ada compiler
>    for the other system.

We build cross compilers all the time, in fact Richard does virtually
all his debugging on an opteron using cross-compilers for all other
targets.
> 
> 2. Since the Ada compiler and tools must be installed in binary form
>    on the other system (because there is no compiler to build it from
>    source), they must be fully relocatable, that is they must be able to
>    be installed in any location; because the person doing the
>    installation may not be able (or willing) to write it to /usr/local
>    or wherever it was originally built for.  (I know the C compilers
>    already do this, I am not sure if it really works for Ada).

GNAT can be installed anywhere, that's not a problem.

Re: Ada policy

[Florian Weimer]

* Geoffrey Keating:

> 2. Since the Ada compiler and tools must be installed in binary form
>    on the other system (because there is no compiler to build it from
>    source), they must be fully relocatable, that is they must be able to
>    be installed in any location; because the person doing the
>    installation may not be able (or willing) to write it to /usr/local
>    or wherever it was originally built for.  (I know the C compilers
>    already do this, I am not sure if it really works for Ada).

The official GNAT 3.15p distributions are fully relocatable on
GNU/Linux and Solaris (I haven't checked Windows).  I haven't tried
this with FSF releases, though.

Re: Ada policy

[Geoffrey Keating]

Zack Weinberg <zack@codesourcery.com> writes:

> http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

I believe when I looked at this, I thought everything in it was reasonable.

I would actually add two extra requirements, which are the reasons why
*I* don't build or test Ada:

1. Since the Ada compiler cannot be bootstrapped from most system
   compilers, it must be at least as easy, if not easier, to
   cross-compile it from a system which does have GNAT installed.  At
   a minimum, it must be possible to easily build a cross Ada compiler
   for the other system, even when the other target is a host
   (including hosts for which binutils is not readily available, like
   AIX and Darwin), and then use that to build a native Ada compiler
   for the other system.

2. Since the Ada compiler and tools must be installed in binary form
   on the other system (because there is no compiler to build it from
   source), they must be fully relocatable, that is they must be able to
   be installed in any location; because the person doing the
   installation may not be able (or willing) to write it to /usr/local
   or wherever it was originally built for.  (I know the C compilers
   already do this, I am not sure if it really works for Ada).

Re: Ada policy

[Robert Dewar]

Florian Weimer wrote:

> <stdint.h> is a huge improvement. 

Yes, absolutely!

> If your code is portable, it can't
> make a difference if you use int_least24_t or int_least32_t.  In fact,
> you could even substitute int32_t for int24_t, and the code would
> still work as before. 

Well .. you can make portable code by implementing a Turing machine and
doing everything at that level and "the code would still work as before",
but efficiency is not something you can afford to throw out of the window
when writing portable code.

Specifying int_least32_t on a 24 bit machine for quantities that could
fit fine in 24 bits is likely to be a severe efficiency hit. The whole
style in Ada is to specify types that accomodate the problem space and
then let the compiler choose efficient mappings.> By the way, your example

> | So for example, there is no equivalent of
> | 
> |    type R is range -2**23 .. 2**23-1;
> | 
> | which you expect to map into 24 bits on a 24 bit machine, and 36 bits on
> | a 36 bit machine.
> 
> seems to lack an R'Base.  Otherwise, your comment about mapping is a
> bit misleading.

The omission of an explicit base type is very definitely intentional here.
You are asking the compiler "you choose an efficient base type for me".
Specifying a base type is generally not what you want, since you do not
want to force the compiler to make an inefficient choice.

Re: Ada policy

[Florian Weimer]

* Robert Dewar:

> Hmm .. http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
>
> seems to confirm my understanding, and actually that reference says it is
> an extension of the C99 definition. What you would want is the type
> int_least24_t, but that's not required to be defined. Am I
> misunderstanding here?

<stdint.h> is a huge improvement.  If your code is portable, it can't
make a difference if you use int_least24_t or int_least32_t.  In fact,
you could even substitute int32_t for int24_t, and the code would
still work as before.  (The need for precise bit counts only arises if
you have certain overflow semantics, which you get only for unsigned
types in standard C.)

By the way, your example

| So for example, there is no equivalent of
| 
|    type R is range -2**23 .. 2**23-1;
| 
| which you expect to map into 24 bits on a 24 bit machine, and 36 bits on
| a 36 bit machine.

seems to lack an R'Base.  Otherwise, your comment about mapping is a
bit misleading.

Re: Ada policy

[Joseph S. Myers]

On Tue, 31 Aug 2004, Scott Robert Ladd wrote:

> I understood that you were discussing portability (based on your focus on
> int), which is often a matter of making certain that type "X" has a compatible
> range across multiple platforms. Thus the stdint.h definitions.
> 
> That is, of course, assuming you have a Standard C compiler across your target
> platforms. :)

Which is perhaps not wise in this regard if you want to rely on features 
GCC doesn't yet implement (<stdint.h>; see the last couple of comments in 
bug 448 for Geoff Keating's proposal to implement it) of a standard that 
has not yet been widely implemented.

Fortunately in this case you can substitute your own <stdint.h> if 
necessary using <limits.h> or autoconf if the target library doesn't have 
<stdint.h> or the more widely implemented <inttypes.h>.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Ada policy

[Scott Robert Ladd]

Robert Dewar wrote:
> Hmm .. I admit I am not an expert in C99 but I thought that stdint.h only
> required a very limited number of integer types, basically the powers of 2.
> So for example, there is no equivalent of
> 
>    type R is range -2**23 .. 2**23-1;
> 
> which you expect to map into 24 bits on a 24 bit machine, and 36 bits on
> a 36 bit machine.

Ah! No, that is *not* something that can be done in Standard C; I was 
unaware that Ada supported such a capability. See why I don't comment on 
Ada's capabilities? ;)

I understood that you were discussing portability (based on your focus 
on int), which is often a matter of making certain that type "X" has a 
compatible range across multiple platforms. Thus the stdint.h definitions.

That is, of course, assuming you have a Standard C compiler across your 
target platforms. :)

> Well I must say I was a bit surprised at the claim that it was arguable
> whether large applications could be practically written sticking strictly
> to ISO C (almost as surprising as Zack's claim that this was clearly
> impractical for Ada :-) I also found the idea that the only way to
> achieve portability is through use of conditional compilation to be
> surprising (I doubt this is true).

I've written a lot of portable C and C++; due to the lack of 
standards-compliant compilers or the use of platform-dependent 
facilities (e.g., GUIs), such code often contains conditional statements.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: Ada policy

[Robert Dewar]

Scott Robert Ladd wrote:

> However, I *can* comment on you understanding of C. Standard C (approved 
> about five years ago) allows explicit declarations of integer sizes via 
> the types in stdint.h. What you have encountered is either old code, or 
> code written by people who are not aware of explicit type sizes.

Hmm .. I admit I am not an expert in C99 but I thought that stdint.h only
required a very limited number of integer types, basically the powers of 2.
So for example, there is no equivalent of

    type R is range -2**23 .. 2**23-1;

which you expect to map into 24 bits on a 24 bit machine, and 36 bits on
a 36 bit machine.

Well let me go look it up ...

Hmm .. http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html

seems to confirm my understanding, and actually that reference says it is
an extension of the C99 definition. What you would want is the type
int_least24_t, but that's not required to be defined. Am I
misunderstanding here?

> This sort of "my language is better than your language" stuff is just 
> plain silly, from any side of the issue.

Well I must say I was a bit surprised at the claim that it was arguable
whether large applications could be practically written sticking strictly
to ISO C (almost as surprising as Zack's claim that this was clearly
impractical for Ada :-) I also found the idea that the only way to
achieve portability is through use of conditional compilation to be
surprising (I doubt this is true).

Re: Ada policy

[Scott Robert Ladd]

Robert Dewar wrote:
> Actually the point in Ada is that you don't need to "cater for
> portability across different implementations", since it is perfectly
> practical to write in completely standard portable Ada. In C, you
> can't help running into portability issues because fundamental
> definitions like the characteristics of int are implementation
> dependent, and so you are forced to mess with conditional
> compilation.

I am certainly not an Ada expert, so I can't comment on its abilities 
(or lack thereof).

However, I *can* comment on you understanding of C. Standard C (approved 
about five years ago) allows explicit declarations of integer sizes via 
the types in stdint.h. What you have encountered is either old code, or 
code written by people who are not aware of explicit type sizes.

This sort of "my language is better than your language" stuff is just 
plain silly, from any side of the issue.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: Ada policy

[Robert Dewar]

Laurent GUERBY wrote:

> This kind of liberty is only available for compiler writers that are
> able to "bootstrap", and not for software in general, so no general
> conclusion should be taken there :).

I wouldn't go that far. A lot of big applications using gcc (gnat,
or g++ or gnu-c or ..) decide that it is fine to restrict their application
to being compilable only with gcc.

For example, it is definitely attractive to use nested functions in C
if you decide to rely on gnu-c. This can for example make it
considerably easier to write thread-safe C (since what otherwise
might be global variables can be uplevel task-specific stack
references).

Re: Ada policy

[Laurent GUERBY]

On Tue, 2004-08-31 at 20:10, Zack Weinberg wrote:
> People seem to be reacting way out of proportion to this particular
> observation.  There's good solid engineering reasons why you need GNAT
> to build GNAT and I don't mean to second-guess that.  

Thanks for the precision (was not clear to me).

> When I say I'm
> disappointed, that's an abstract observation on the state of the Ada
> language -- if it's not practical to write a large complex piece of
> software such as a compiler in the language as standardized, then the
> standard is less than useful, and that's disappointing.

That's not the point, it's practical to write large complex software
in Ada (I worked on "porting" n-million lines Ada application from
compilers and platforms without much trouble except long compile time on
old 16MB of RAM machines for software of such size :).

It's just that GNAT people choose to take advantage of non portable
feature they added as they saw fit since it had no practical drawback
(given the cross compilation abilities of GCC). 

This kind of liberty is only available for compiler writers that are
able to "bootstrap", and not for software in general, so no general
conclusion should be taken there :).

Laurent

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> [It's debatable whether it's practical to write a large complex piece
> of software in the C language as ISO-standardized, but at least it's
> possible to do so in the /de facto/ standard language.]

My final note on this issue, I am really surprised that it is debatable
for C whether it is practical to write large complex pieces of software
in standard C. I guess things are worse than I thought if that's the
case.

In Ada, it is most certainly practical to write completely portable
large complex applications in Ada, and we have several customers who
do this since their coding guidelines require such portability, and
indeed some of them are using more than one compiler in parallel.

But once again, although this is practical and possible, it is simply
not a design criterion for GNAT. Since we know we are being compiled
with GNAT we take advantage of its full features. If vendors of
proprietary compilers want to borrow some of our code, then they
can mess to make it work with their compilers.

Here's a specific example:

THere is a routine in Ada.Decimal that does high precision decimal
scaled division. Of course the body could be written in pure
Ada, but in GNAT you will find:

       procedure Divide
         (Dividend  : in Dividend_Type;
          Divisor   : in Divisor_Type;
          Quotient  : out Quotient_Type;
          Remainder : out Remainder_Type);

       pragma Import (Intrinsic, Divide);

The Ada standard defines the convention Intrinsic, but it is implementation
dependent what intrinsics are provided. The effect is similar to a built-in
in GCC, and the result is to let the compiler generate direct efficient
code for this operation.

Now if Aonix wants to borrow our implementations of decimal (they did borrow
some code at least at one point to fill in things they had not bothered to
implement themselves), then they will find this won't compile. Too bad as
far as we are concerned, being able to compile with Aonix is not one of
our coding requirements :-)

P.S. I know this is a run-time example, but it's a simple one to explain,
and there are many similar examples throughout the compiler.

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> And the C language seems to cater more for portability across
> different implementations, too (with conditional compilation and the
> like).

Actually the point in Ada is that you don't need to "cater for
portability across different implementations", since it is perfectly
practical to write in completely standard portable Ada. In C, you
can't help running into portability issues because fundamental
definitions like the characteristics of int are implementation
dependent, and so you are forced to mess with conditional
compilation. When writing portable Ada, you would of course
completely avoid the use of the type Integer (which is what
corresponds to int), since you don't need to use these built
in integer types when you can define your own.

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> People seem to be reacting way out of proportion to this particular
> observation.  There's good solid engineering reasons why you need GNAT
> to build GNAT and I don't mean to second-guess that.  When I say I'm
> disappointed, that's an abstract observation on the state of the Ada
> language -- if it's not practical to write a large complex piece of
> software such as a compiler in the language as standardized, then the
> standard is less than useful, and that's disappointing.

You have a strange way of jumping to extremely odd conclusions.

No one ever said that it is not practical to write a large complex
piece of software in standard Ada, and yet you conclude from our
quite deliberate choice here that this is not practical.

Of course it would be possible to write GNAT is standard Ada, but
since we decided long ago that the only requirement is that it
be able to compile itself, we might as well take advantage of the
many implementation dependent extra features in GNAT to improve
the quality and readabiity of the compiler.

> [It's debatable whether it's practical to write a large complex piece
> of software in the C language as ISO-standardized, but at least it's
> possible to do so in the /de facto/ standard language.]

It's FAR easier to write within the confines of the Ada standard than
the C standard since it is a much more flexible language. Just one
example, in C there is no way of precisely specifying the layout of
data, e.g. bit packed arrays. Zack, I have a feeling you don't know
Ada that well :-) :-)

Re: Ada policy

[Laurent GUERBY]

On Tue, 2004-08-31 at 00:56, Florian Weimer wrote:
> Laurent, shiuld I put you in touch with Debian's gnat maintainer?

Sure, but may be some of them are also in our bugzilla, if they
have a way to know which ones that would help 

BTW don't forget to CC me or put "guerby" in the body of the message if
you want to be 100% sure I read it :).

Laurent

Re: Ada policy

[Robert Dewar]

Laurent GUERBY wrote:

> On Tue, 2004-08-31 at 16:39, Gabriel Dos Reis wrote:
> 
>>I think you could reason on facts: the C front-end!
> 
> 
> I'd say not relevant, the Ada subset used by GNAT is
> much more complex than C.

I think you missed the point. Gabriel was saying that even
the (much simpler) language of the C front end is unable
to meet the criterion of compiling with all possible previous
C compilers :-)

Re: Ada policy

[Zack Weinberg]

Laurent GUERBY <laurent@guerby.net> writes:

> On Tue, 2004-08-31 at 16:39, Gabriel Dos Reis wrote:
>> I think you could reason on facts: the C front-end!
>
> I'd say not relevant, the Ada subset used by GNAT is much more
> complex than C. Also as soon as bootstrap was complete, GNAT code
> started using Ada 9x features and there was no other Ada 9x compiler
> to help with portability problems, which was clearly not the
> situation for C.

And the C language seems to cater more for portability across
different implementations, too (with conditional compilation and the
like).

People seem to be reacting way out of proportion to this particular
observation.  There's good solid engineering reasons why you need GNAT
to build GNAT and I don't mean to second-guess that.  When I say I'm
disappointed, that's an abstract observation on the state of the Ada
language -- if it's not practical to write a large complex piece of
software such as a compiler in the language as standardized, then the
standard is less than useful, and that's disappointing.

[It's debatable whether it's practical to write a large complex piece
of software in the C language as ISO-standardized, but at least it's
possible to do so in the /de facto/ standard language.]

zw

Re: Ada policy

[Laurent GUERBY]

On Tue, 2004-08-31 at 16:39, Gabriel Dos Reis wrote:
> I think you could reason on facts: the C front-end!

I'd say not relevant, the Ada subset used by GNAT is
much more complex than C. Also as soon as bootstrap
was complete, GNAT code started using Ada 9x features
and there was no other Ada 9x compiler to help
with portability problems, which was clearly
not the situation for C.

Laurent

Re: Ada policy

[Robert Dewar]

Here is the promised information on what we currently test in terms
of bootstrap paths. We use the following compilers on various
machines to start the bootstrap

3.13a1 (similar to 3.13p)
3.14a1 (similar to 3.14p)
3.15a1 (similar to 3.15p)
3.16a1
5.02a1 (GCC 3.2.x based)

Re: Ada policy

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| The point is that working around bugs in all previous versions of
| GNAT (not to mention bugs in all previous versions of all alledgedly
| standard Ada compilers) would be somewhat infeasible. Again, suppose
| that you were required to code the g++ front end in C++ subject to
| the requirement that it compile correctly on all previous versions
| of C++ from all vendors, including all versions of g++, well that
| would be tricky :-)

I think you could reason on facts: the C front-end!

-- Gaby

Re: Ada policy

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| Zack Weinberg wrote:
| 
| > Having thought about this a bit more, I can only defend a slightly
| > weaker assertion based on messages I can actually find in the mailing
| > list archives.  See my response to Kenner.  Can you agree that a
| > reasonable person could have reached *that* conclusion?
| 
| Well quite a bit weaker actually :-) Saying that we were deliberately
| breaking things seemed to be going a bit far!
| 
| The issue is a simple one. It is the extent of the guarantee that
| it will be possible to bootstrap from previous versions. If you
| imagine for a moment that the g++ front end were written entirely
| in C++, I think you can see that it would not be quite so easy to
| guarantee that it could be bootstrapped with any previous version
| of g++.

Why imagining the case of g++ when you can take the actual case of
cc1, the C front-end? :-)

-- Gaby

Re: Ada policy

[Robert Dewar]

Florian Weimer wrote:

> Of course it could be done, but how many GCC users would need such a
> feature?  Maybe a dozen, but certainly not more.

I would be amazed if it were a dozen :-)

I would actually be surprised if there is even one user who wants to
bootstrap GNAT with other than a version of GNAT!

Re: Ada policy

[Robert Dewar]

Per Bothner wrote:

> Richard Kenner wrote:
> 
>> As I'm sure you know, if you start with copyrighted code and "trim it
>> down", you still have copyrighted code.  Making a non-proprietary
>> version of a test case involves a lot more work than that.

> A trimmed-out test case, with comments removed, and identifiers renamed,
> is still a "derived" work, but presumably many customers would be
> willing to disclaim copyright interest.

This might work in some cases, but it's much harder than you think.
Every such case has to go to company lawyers, whose job it is to
protect the IPR interests of the company, and who naturally default
to a conservative "protect everything" viewpoint. In the absence
of a very strong argument of value to the company, it is hard to
get such agreements. Furthermore, we have been very successful
in persuading companies large and small to contribute substantial
chunks of proprietary code, under the absolute guarantee of
fierce protection. That's lead to us having a very effective
suite of real code with tens of thousands of files, and many
millions of lines of real Ada application code. So we have to
be careful not to confuse the message.

> Perhaps as part of your
> bug resolution procedure you could ask "could you please review
> this simplified test case as to whether we can release it".  This
> does involve some customer education, so it is probably only worthwhile
> for your bigger customers - i.e. those who submit lots of test cases.

Right, it might work in some limited number of cases. We have some
experience with this when it comes to a few cases in which customers
have contributed code. Even that can be a tricky case to deal with
and very often we have ended up just rewriting from scratch rather
than deal with the legal problems. We don't get very much contributed
code of this type, so these are isolated cases from a small number of
customers, and yes, education is a large part of the job here.

Re: Ada policy

[Florian Weimer]

* Zack Weinberg:

> I continue to be disappointed that an arbitrary standard-conforming
> Ada compiler cannot be used.

Have you actually seen any such compiler in the wild? 8-)

Of course it could be done, but how many GCC users would need such a
feature?  Maybe a dozen, but certainly not more.

Re: Ada policy

[Robert Dewar]

Matt Austern wrote:

> The other thing, of course, is that people who are working with
> the FSF compiler and the free test suite can't be expected to
> fix regressions that are only visible in a proprietary test suite
> that they don't have access to. 

Yes, of course, that goes without saying. The same thing is true
for other GCC back ends. You can't fix what you can't see. What
needs to happen here (and this has happened frequently in the
past), is that if a change breaks some test in our test suite,
then we either fix it ourselves, or we produce a distributable
test case (often we try to do this in C since the problem so far
is all concerned with back end bugs). We can't expect anyone to
help if we don't do that!

> The basic question, as far as I can tell, is: for someone who
> isn't a dedicated Ada maintainer, how much responsibility do they
> have for keeping Ada working? If everyone is happy for the answer
> to be "not very much", then most of these discussions about process
> can be put aside.

Well running the ACATS tests is actually a very substantial step.
I think that even *requiring* this is something that needs to be
discussed, because we don't want to erect obstacles in the way of
people working on other languages who have no interest in Ada. Yes
there's a balance here, but I would hesitate to require such testing.
Instead I would try to make it as easy as possible, and encourage it
as much as possible.

Furthermore, if we proceed ahead and add the tests that can be
added, which Laurent has volunteered to help with, that will be
a further level of tests

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> I continue to be disappointed that an arbitrary standard-conforming
> Ada compiler cannot be used.

Oh, and by the way, I hope this does not come as a drastic surprise
to you, but there are no standard-conforming Ada compilers, not 100%
conforming, since a single bug contradicts that status, and I have to
report that especially in the case of previous versions of GNAT, we
know of quite a few bugs :-)

(as a marketing phrase, we have sometimes used the tag line "there
is only one bug in GNAT", but I am afraid this is not strictly true.

The point is that working around bugs in all previous versions of
GNAT (not to mention bugs in all previous versions of all alledgedly
standard Ada compilers) would be somewhat infeasible. Again, suppose
that you were required to code the g++ front end in C++ subject to
the requirement that it compile correctly on all previous versions
of C++ from all vendors, including all versions of g++, well that
would be tricky :-)

I suppose you could just degrade to coding in C after all, but the
whole point of moving to C++ for the front end of g++ (which by the
way seems a perfectly reasonable step to me), would be to take
advantage of some of the important features of C++. Yes, discussion
would be needed (and some has gone on) on what subset would be
appropriate, and you can see the discussion ranges from quite
conservative (me for example) to much more liberal, but certainly
even if you take a very conservative position, you cannot expect
to be compatible with all previous versions of c++ compilers,
and I would not argue for using this as a criterion.

Certainly in the case of Ada and GNAT, we had lots of discussions
about the subset to be used for the compiler, and it is actually
fairly small (e.g. avoiding tasking, controlled types, tagged
types etc).

P.S. Once upon a time (actually I think it was in 1992),
GNAT was bootstrapped with another compiler (the Alsys
compiler on SunOS), but once that bootstrap was complete,
we only ever regarded bootstrapping with GNAT as the
criterion for moving forward.

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> Having thought about this a bit more, I can only defend a slightly
> weaker assertion based on messages I can actually find in the mailing
> list archives.  See my response to Kenner.  Can you agree that a
> reasonable person could have reached *that* conclusion?

Well quite a bit weaker actually :-) Saying that we were deliberately
breaking things seemed to be going a bit far!

The issue is a simple one. It is the extent of the guarantee that
it will be possible to bootstrap from previous versions. If you
imagine for a moment that the g++ front end were written entirely
in C++, I think you can see that it would not be quite so easy to
guarantee that it could be bootstrapped with any previous version
of g++. Of course everyone agrees that it is desirable to maintain
the broadest possible set of bootstrap paths (that's why the
accusation that we were deliberately breaking things rankled a
bit :-)

The question is whether you can guarantee that it will be possible
to bootstrap with all previous versions. Well of course you cannot
make that broad of a guarantee. So what you want to do is to balance
the conflicting goals here:

1. Provide a front end that is as efficient as possible, written
as clearly as possible.

2. Maintain general bootstrap paths

I think in practice we have made the right decisions here. The
only reported difficulty was when you (Zack) tried to use some
inconsistent versions of C and GNAT, and exceptions could not
be properly supported in that mixed environment.

>>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.
> 
> That is a good sign...
> 
>>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!)

> I continue to be disappointed that an arbitrary standard-conforming
> Ada compiler cannot be used.

That would be a very fierce restriction, resulting in considerable
inefficiencies, since it would mean that we could not take advantage
of any of the standard GNAT pragmas and attributes, which are used
extensively (many of these attributes and pragmas were in fact put
there for use by the compiler in the first place, e.g. pragma
No_Return, so that we can turn on full warnings).

The probability of someone wanting to bootstrap GNAT starting with
an expensive proprietary compiler seems vanishingly small, given
that GNAT is so widely available, and that it is fairly easy to
build cross compilers to go to new architectures. I don't think
there are cases anyway (unlike the situation with GCC) where you
have an environment with an Ada compiler which is not GNAT, and
GNAT is not available.

Yes, in the abstract, this goal sounds desirable, but the gains
would be minuscule and the cost high. If you don't agree, spend
a bit of time (well it might take *quite* a bit of time) looking
through the sources to see how we use GNAT attributes. Look for
example at the use of 'Unrestricted_Access. Yes, you can remove
these uses, but in almost all cases you will do real damage to
the readability of the code. The technical problem here is that
Ada severely restricts the passing of subprograms as parameters.
Why? Becuase some other now defunct Ada compiler could not easily
support reasonable semantics, and the vendor screamed murder at
the standards committee. So everyone using standard Ada is stuck
with annoying work arounds.

> Until such time as the distinction between the runtime and the
> compiler proper is reflected in the organization of the source tree, I
> cannot be bothered to figure out which is which.

That's fine, but be careful about basing deductions from this
position of lack of understanding of the distinction. In practice
there is no issue of making mistakes here, since if for example,
you incorrectly use pragma Unreferenced in the compiler proper,
the build will fail if you follow our style of using an early
version of the compiler for the bootstrap.

> This must sound
> dreadfully lazy to you, but consider that from my point of view,
> checking in a grab bag of patches once a week with no public review is
> far lazier.  (You continue not to address this concern.)

It's not a matter of being lazy, it is simply a matter of resources.
If we had millions of dollars in the bank, and could afford to have
one or two full time people dedicated to the submission of patches
in a more separated way. I am dubious about review, almost all these
patches require a pretty detailed knowledge of GNAT to understand.
But review is always welcome (we certainly would welcome more
input anywhere on GNAT, and yes, if we spent more effort on how the
patches were submitted, it might help, but I doubt it). The situation
with back end general gcc patches is of course different, and as you
know these often get substantially discussed.

So we (AdaCore) have three choices at the moment

1. Don't submit Ada patches at all
2. Submit them as we are doing now, keeping the tree up to date
3. Submit them broken down, fully documented, with tests, for review

Yes, 3 would be nice, but there just aren't the resources to do it.
As it is doing 2 represents a significant investment for us. We
certainly recognize that we get a lot back for that investment,
but it already strains what we can achieve, given that attention
to supported customers is always our number one priority (without
the supported customers, there would be no patches from us :-)

So, not ideal, but 2 seems better than 1 to us, and arguing
strongly for 3 is not going to make much difference unless
someone is willing to fund this activity (in the old days
perhaps the AJPO could have been approached, but I don't
see any source for such funding today).

Robert

Re: Ada policy

[Richard Kenner]

    A trimmed-out test case, with comments removed, and identifiers renamed,
    is still a "derived" work, but presumably many customers would be
    willing to disclaim copyright interest.  Perhaps as part of your
    bug resolution procedure you could ask "could you please review
    this simplified test case as to whether we can release it".  This
    does involve some customer education, so it is probably only worthwhile
    for your bigger customers - i.e. those who submit lots of test cases.

Robert can say more about this, but remember that the biggest companies
are usually the ones with the biggest legal department ...

Re: Ada policy

[Per Bothner]

Richard Kenner wrote:

> As I'm sure you know, if you start with copyrighted code and "trim it
> down", you still have copyrighted code.  Making a non-proprietary
> version of a test case involves a lot more work than that.

A trimmed-out test case, with comments removed, and identifiers renamed,
is still a "derived" work, but presumably many customers would be
willing to disclaim copyright interest.  Perhaps as part of your
bug resolution procedure you could ask "could you please review
this simplified test case as to whether we can release it".  This
does involve some customer education, so it is probably only worthwhile
for your bigger customers - i.e. those who submit lots of test cases.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Ada policy

[Matt Austern]

On Aug 30, 2004, at 8:22 PM, Zack Weinberg wrote:

> kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
>
>> The point is what to do with the FSF tree with respect to fixes for
>> bugs for which no resources are available to make a non-proprietary
>> test case.  Should the fix for the bug not be propagated to the FSF
>> tree?  I see no argument in favor of doing that.
>
> For the record, I'm fine with putting the fix in the FSF tree and
> declaring that there is a test case but it's proprietary code, in
> this circumstance.  However, developing non-encumbered test cases
> is certainly a Good Thing, and IMO worth spending time on.

The other thing, of course, is that people who are working with
the FSF compiler and the free test suite can't be expected to
fix regressions that are only visible in a proprietary test suite
that they don't have access to.

The basic question, as far as I can tell, is: for someone who
isn't a dedicated Ada maintainer, how much responsibility do they
have for keeping Ada working? If everyone is happy for the answer
to be "not very much", then most of these discussions about process
can be put aside.

			--Matt

Re: Ada policy

[Zack Weinberg]

Robert Dewar <dewar@gnat.com> writes:

> I am gathering the data on what versions we use as the starting
> points for builds on both GCC 2.8.x and GCC 3.2.x. I will report
> to this list when I get all this data.
>
> In practice if we ever need to consider breaking these paths,
> that will be a pretty big discussion at our end anyway, so we
> will plan on involving the gcc mailing list in that discussion.

Thank you, I appreciate that.

zw

Re: Ada policy

[Zack Weinberg]

Robert Dewar <dewar@gnat.com> writes:

> 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.

Having thought about this a bit more, I can only defend a slightly
weaker assertion based on messages I can actually find in the mailing
list archives.  See my response to Kenner.  Can you agree that a
reasonable person could have reached *that* conclusion?

> 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.

That is a good sign...

> 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!)

I continue to be disappointed that an arbitrary standard-conforming
Ada compiler cannot be used.

> 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.

Until such time as the distinction between the runtime and the
compiler proper is reflected in the organization of the source tree, I
cannot be bothered to figure out which is which.  This must sound
dreadfully lazy to you, but consider that from my point of view,
checking in a grab bag of patches once a week with no public review is
far lazier.  (You continue not to address this concern.)

zw

Re: Ada policy

[Robert Dewar]

I am gathering the data on what versions we use as the starting
points for builds on both GCC 2.8.x and GCC 3.2.x. I will report
to this list when I get all this data.

In practice if we ever need to consider breaking these paths,
that will be a pretty big discussion at our end anyway, so we
will plan on involving the gcc mailing list in that discussion.

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> For the record, I'm fine with putting the fix in the FSF tree and
> declaring that there is a test case but it's proprietary code, in 
> this circumstance.  However, developing non-encumbered test cases
> is certainly a Good Thing, 

Yes, no one disagrees with that!

> and IMO worth spending time on.

That's of course the issue, worth it to whom? And who
covers the cost of this time. It's just a matter of
balancing resources as usual.

> It sounds like you have a regression test harness internally; would
> it be practical to clean that up and contribute it?

I think the clean up would be more effort than rewriting by quite
a large margin. The current script is tied into our whole system
for bug tracking etc.

Re: Ada policy

[Robert Dewar]

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).

Re: Ada policy

[Richard Kenner]

    However, developing non-encumbered test cases is certainly a Good
    Thing, and IMO worth spending time on.

Everyone agrees with that.  The problem is that there are a lot of
things that are worth spending time on and a limited amout of time.

    It sounds like you have a regression test harness internally; would
    it be practical to clean that up and contribute it?

It wouldn't be all that useful since it's meant to work in a very different
environment.  Laurent Guerby says that the harness he wrote for ACATS could
be converted to deal with the other tests cases fairly straightforwardly.

Re: Ada policy

[Zack Weinberg]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> The point is what to do with the FSF tree with respect to fixes for
> bugs for which no resources are available to make a non-proprietary
> test case.  Should the fix for the bug not be propagated to the FSF
> tree?  I see no argument in favor of doing that.

For the record, I'm fine with putting the fix in the FSF tree and
declaring that there is a test case but it's proprietary code, in 
this circumstance.  However, developing non-encumbered test cases
is certainly a Good Thing, and IMO worth spending time on.

It sounds like you have a regression test harness internally; would
it be practical to clean that up and contribute it?

zw

Re: Ada policy

[Zack Weinberg]

Robert Dewar <dewar@gnat.com> writes:
> Zack Weinberg wrote:
>> Robert Dewar <dewar@gnat.com> writes:
>> Whereas I cannot imagine how you manage to miss what is a clear
>> implication of the text of that message.
>
> The important point in the message is that it is critical that
> the C and Ada compiler be consistent
[...]

That may be what you see as the important point in the message, but it
is by no means the only thing said in the message, let alone the only
implication of the message.

This discussion is about appearances as well as actuality.  Can you at
least agree that a reasonable person could reach my position?  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?

>> 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.

> 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?

zw

Re: Ada policy

[Richard Kenner]

    Primary languages and platforms should have them, they come in handy
    from time to time and help make the compiler more maintainable and
    help ensure a certain quality standard.  Do no harm is really more
    interesting to a customer than a random bug fix that they don't hit,
    and by far, most code doesn't hit most bugs, therefore the greater
    good is to not fix the bug, if you can't also do the testcase to
    ensure that the customer won't hit the bug again...

The key point is who is "you".  ACT can clearly put the bug in *their*
regression suite, so the bug will stay fixed.  Not fixing a customer
bug isn't an option.

The point is what to do with the FSF tree with respect to fixes for
bugs for which no resources are available to make a non-proprietary
test case.  Should the fix for the bug not be propagated to the FSF
tree?  I see no argument in favor of doing that.

Re: Ada policy

[Robert Dewar]

Mike Stump wrote:

> Primary languages and platforms should have them, they come in handy 
> from time to time and help make the compiler more maintainable and help 
> ensure a certain quality standard.  Do no harm is really more 
> interesting to a customer than a random bug fix that they don't hit, and 
> by far, most code doesn't hit most bugs, therefore the greater good is 
> to not fix the bug, if you can't also do the testcase to ensure that the 
> customer won't hit the bug again...
> 
> Now, this is controversial, to be sure... and I'm not sure what should 
> be required of other frontends...  I'll abstain from that.

Of course in practice if the FSF version is kept very close to the
AdaCore GNAT Pro version (which is what we try to achieve), then we
run millions of lines of proprietary tests on every target every day,
so indirectly you get the benefit of these tests anyway. If the trees
diverge, then you lose this very valuable input.
> 
> On the other hand, if you never need to run the testsuite and never 
> break any bugs, then, doing the testsuite is a complete waste of time.  :-)

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:
> Robert Dewar <dewar@gnat.com> writes:

> Whereas I cannot imagine how you manage to miss what is a clear
> implication of the text of that message.

The important point in the message is that it is critical that
the C and Ada compiler be consistent, that is still very much
the case (there may be isolated cases where this is not required
but such combinations are never tested by us).

> I'm willing to accept what you say now as a statement of a changed
> policy, though.

Well I am glad that you see a perceived change that you find
OK, there is in fact no change at all.

>>Just so things are clear, we start our nightly runs with several
>>different older versions of the compiler precisely to make sure we
>>retain as much compatibility with old versions as possible for
>>builds.
> 
> 
> I am very glad to hear this.

This has been the case for a long time

>  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.

Re: Ada policy

[Mike Stump]

On Aug 30, 2004, at 4:03 PM, Richard Kenner wrote:
> As Robert said, there will be lots of situations where the choice is 
> either
> to submit the fix without a test case or not submit the fix.  Which do
> you think is the best approach?

Primary languages and platforms should have them, they come in handy 
from time to time and help make the compiler more maintainable and help 
ensure a certain quality standard.  Do no harm is really more 
interesting to a customer than a random bug fix that they don't hit, 
and by far, most code doesn't hit most bugs, therefore the greater good 
is to not fix the bug, if you can't also do the testcase to ensure that 
the customer won't hit the bug again...

Now, this is controversial, to be sure... and I'm not sure what should 
be required of other frontends...  I'll abstain from that.

On the other hand, if you never need to run the testsuite and never 
break any bugs, then, doing the testsuite is a complete waste of time.  
:-)

Re: Ada policy

[Zack Weinberg]

Robert Dewar <dewar@gnat.com> writes:

> Zack Weinberg wrote:
>
>> Robert Dewar <dewar@gnat.com> writes:
>>
>>>Reading Zack's message:
>>>
>>>>Second, the Ada maintainers have said in the past that they
>>>>deliberately break source compatibility between releases (such that
>>>>GCC 3.x with Ada is only guaranteed to be buildable with GCC 3.(x-1)).
>>>
>>>That's entirely wrong. Nothing is broken deliberately, and no one
>>>ever said anything of the kind.
>> I disagree; that *is*, in fact, what is said or at least strongly
>> implied by messages like
>> <http://gcc.gnu.org/ml/gcc/2002-05/msg00086.html>:
>
> No, it definitely is NOT said here. There is absolutely nothing
> there about deliberately breaking source compatibility. I can't
> imagine how you manage this strange reading.

Whereas I cannot imagine how you manage to miss what is a clear
implication of the text of that message.

I'm willing to accept what you say now as a statement of a changed
policy, though.

> Just so things are clear, we start our nightly runs with several
> different older versions of the compiler precisely to make sure we
> retain as much compatibility with old versions as possible for
> builds.

I am very glad to hear this.  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.

>> I'd also add that personally, I consider my third requirement
>> (patch submission according to the same requirements binding 
>> on all other contributors) to be much more important than the 
>> one you chose to discuss.
>
> You must be missing some messages in this thread, since that has
> most certainly been discussed by me and others.

Test cases has been discussed at length, but the other ways in which
ACT does not follow the patch submission requirements have not been
discussed at all.

zw

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> Robert Dewar <dewar@gnat.com> writes:
> 
> 
>>Reading Zack's message:
>>
>>>Second, the Ada maintainers have said in the past that they
>>>deliberately break source compatibility between releases (such that
>>>GCC 3.x with Ada is only guaranteed to be buildable with GCC 3.(x-1)).
>>
>>That's entirely wrong. Nothing is broken deliberately, and no one
>>ever said anything of the kind.
> 
> 
> I disagree; that *is*, in fact, what is said or at least strongly
> implied by messages like
> <http://gcc.gnu.org/ml/gcc/2002-05/msg00086.html>:

No, it definitely is NOT said here. There is absolutely nothing
there about deliberately breaking source compatibility. I can't
imagine how you manage this strange reading.

> and goes on to talk about how it'd be nice to use pragma Unreferenced,
> but this breaks compatibility with the Ada compiler in GCC 3.[12].
> And, grepping gcc/ada, I see that there are now many uses of pragma
> Unreferenced - so building GNAT with GCC 3.(<3) has indeed been
> deliberately broken.\

Please don't talk about things you have not studied carefully.
We never use pragma Unreferenced in the compiler, or in the
run-time units used by the compiler. If we did so, our nightly
runs would break, since some of them start from quite early
versions of the compiler. We use pragma Unreferenced only in
the run-time, but this is always built with the newly built
compiler, so there is no issue there.

Just so things are clear, we start our nightly runs with several
different older versions of the compiler precisely to make sure
we retain as much compatibility with old versions as possible
for builds. Any impression that this kind of compatibility has
been recently broken at all, let alone deliberately, is based
on confusion and lack of understanding I am afraid.

> I have some sympathy for a situation where version X of GNAT contained
> invalid code which version Y (Y > X) correctly rejects; but when this
> occurs while version X is a still-live release branch, patches should
> go into version X to correct the bug.

I disagree with this, you don't want to discombobulate users using the
older version of the compiler, and in any case this is largely
unnecessary. You are really creating strawmen here. The current version
of Ada bootstraps with quite old versions of GNAT.

> I'd also add that personally, I consider my third requirement (patch
> submission according to the same requirements binding on all other
> contributors) to be much more important than the one you chose to
> discuss.

You must be missing some messages in this thread, since that has
most certainly been discussed by me and others.
> 
> zw

Re: Ada policy

[Zack Weinberg]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Note that that was in the context of a discussion of whether configure
>     should refuse to enable Ada if the "wrong" bootstrap compiler was found.
>
> You missed the point that "wrong" meant one of the compilers where the
> you'd end up building the C and Ada parts with different versions of
> GCC.  That caused EH problems within the compiler.

No.  I remember that argument (and I still disagree with its
resolution).  Geert was speaking more generally.

>     But that doesn't mean you can't use pragma Unreferenced; it just has
>     to be properly conditionalized so that GCC 3.(<3) somehow sees pragma
>     Warnings (Off) instead.
>
> You can't "conditionalize" in Ada, "properly" or not.  It was a
> requirement of the language that it *not* permit conditionalization.
> The reason was to avoid situations where you'd get compilation errors
> with one set of options and not with others.  The requirements for the
> language that became Ada forbid that.

You get to write scripts to munge the text of the files before handing
them to the compiler, then.

zw

Re: Ada policy

[Richard Kenner]

    Note that that was in the context of a discussion of whether configure
    should refuse to enable Ada if the "wrong" bootstrap compiler was found.

You missed the point that "wrong" meant one of the compilers where the
you'd end up building the C and Ada parts with different versions of
GCC.  That caused EH problems within the compiler.

    But that doesn't mean you can't use pragma Unreferenced; it just has
    to be properly conditionalized so that GCC 3.(<3) somehow sees pragma
    Warnings (Off) instead.

You can't "conditionalize" in Ada, "properly" or not.  It was a
requirement of the language that it *not* permit conditionalization.
The reason was to avoid situations where you'd get compilation errors
with one set of options and not with others.  The requirements for the
language that became Ada forbid that.  There's simply no way to avoid
the sort of problem you are trying to work around.

Re: Ada policy

[Zack Weinberg]

Robert Dewar <dewar@gnat.com> writes:

> Reading Zack's message:
>> Second, the Ada maintainers have said in the past that they
>> deliberately break source compatibility between releases (such that
>> GCC 3.x with Ada is only guaranteed to be buildable with GCC 3.(x-1)).
>
> That's entirely wrong. Nothing is broken deliberately, and no one
> ever said anything of the kind.

I disagree; that *is*, in fact, what is said or at least strongly
implied by messages like
<http://gcc.gnu.org/ml/gcc/2002-05/msg00086.html>:

# Right now, we are in a transitioning phase, since there is no GCC
# release yet with Ada support. We could even disable Ada by default,
# as there will be people building binary versions anyway. For future
# versions, there is a very clear base compiler that should be used,
# which is the previous FSF released version of GCC.

Note that that was in the context of a discussion of whether configure
should refuse to enable Ada if the "wrong" bootstrap compiler was
found.

More explicitly, <http://gcc.gnu.org/ml/gcc/2002-05/msg02458.html> -
which you wrote - says that

#> It would be nice if we could preserve bootstrap compatibility
#> farther back, but if there are major gains to maintainability from
#> raising the bar, fine.
#
# Well certainly we are not going to make incompatibilities for the
# sake of making incompatibilties. But there are always cases in every
# release where we preserve some kludge for maintainability.

and goes on to talk about how it'd be nice to use pragma Unreferenced,
but this breaks compatibility with the Ada compiler in GCC 3.[12].
And, grepping gcc/ada, I see that there are now many uses of pragma
Unreferenced - so building GNAT with GCC 3.(<3) has indeed been
deliberately broken.

Now, I say

>> There must be guaranteed bidirectional source compatibility between
>> all 3.x branches of GCC, such that it is possible to build any 3.x
>> version of GNAT with any other 3.x version of GNAT.

and I do still insist on that.  But that doesn't mean you can't use
pragma Unreferenced; it just has to be properly conditionalized so
that GCC 3.(<3) somehow sees pragma Warnings (Off) instead.

With regard to this statement

> Unfortunately there are occasionally cases where bugs cannot be
> fixed without breaking this requirement. It's relatively rare, and
> for some time now, GNAT has been able to be built with a pretty
> significant variety of starting compilers

I have some sympathy for a situation where version X of GNAT contained
invalid code which version Y (Y > X) correctly rejects; but when this
occurs while version X is a still-live release branch, patches should
go into version X to correct the bug.

When it's a case of version X contains a bug which causes it to
miscompile the code in version Y (again, Y > X) I have *no* sympathy.
We work around this kind of thing all the damn time in the parts of
the compiler that are written in C, and I see no reason why the Ada
parts should be any different.

I'd also add that personally, I consider my third requirement (patch
submission according to the same requirements binding on all other
contributors) to be much more important than the one you chose to
discuss.

zw

Re: Ada policy

[Florian Weimer]

* Robert Dewar:

> Florian Weimer wrote:
>
>> I wouldn't say that.  They won't help you much when you want to
>> determine the ultimate state of the work with respect to copyright, of
>> course.  But as Joe Buck wrote in 2000, the main goal is to make
>> complaints very unlikely, and to me, this suggests are more optimistic
>> approach.
>
> Fine, sounds reasonable, but for me this is far short of the criterion
> of "coming with proper licensing conditions", which for me requires
> a formal license statement.

I see.  I'm affected by the way Debian typically deals with licenses:
Everything is examined but the actual source code, its history and its
ownership. 8-)

Re: Ada policy

[Florian Weimer]

* Laurent GUERBY:

> On Mon, 2004-08-30 at 21:28, Florian Weimer wrote:
>> I understand that Ada is already in much better shape than we expected
>> it to be before the tree-ssa merge (and that's certainly good news!),
>> but I really doubt we should make a release criterion the quality of a
>> component that has received very little testing by the general GCC
>> community.
>
> I'm just talking about bootstrap, passing ACATS and no known regression
> on two targets, not "quality" in general (whatever that means).

I was talking about bootstrap and ACATS, too, but on a more general
scale.  Today's x86 systems are far from being homogeneous.

> Is that what you want for Ada now?

You wrote that the GCC 3.4 release was pretty good from an Ada point
of view, and we didn't have any formalized Ada criteria for it.

As far as I can see, we haven't had a bootstrapping Ada compiler for
months.  (This is by no means a criticism, I note that we are still
way ahead of the original schedule, Ada-wise.  Certainly I didn't
expect Ada to be included in 3.5 at all, based on the discussion
before the tree-ssa merge.)  I think, however, that it is unreasonable
to expect that large fraction of GCC developers will be able to
_efficiently_ deal with Ada regressions before the 3.5 release, simply
because they lack an Ada toolchain that is in a well-defined state and
can be used to build a compiler and a working run-time environment.

Re: Ada policy

[Robert Dewar]

Florian Weimer wrote:

> I wouldn't say that.  They won't help you much when you want to
> determine the ultimate state of the work with respect to copyright, of
> course.  But as Joe Buck wrote in 2000, the main goal is to make
> complaints very unlikely, and to me, this suggests are more optimistic
> approach.

Fine, sounds reasonable, but for me this is far short of the criterion
of "coming with proper licensing conditions", which for me requires
a formal license statement.

Re: Ada policy

[Richard Kenner]

    Don't start fixing a testcase until after you've trimmed the testcase
    down, then you will find that all bugs you fix will have cut down test
    cases.

As I'm sure you know, if you start with copyrighted code and "trim it
down", you still have copyrighted code.  Making a non-proprietary
version of a test case involves a lot more work than that.

    We can describe the procedure to transform a proprietary testcase in 
    detail into one that isn't, if you want.  

Let's not get into copyright law, but the point is that if you transform
it using a "procedure", it's still proprietary.

    So, I guess I am confused as to, do you just not want to do the work
    to produce the testcases, or do you lack the understanding of how to
    do it?

There are a lot of people fixing bugs in the Ada front end.  The skill levels
of each of these people in making non-proprietary versions of test cases
differs.  The amount of time each has to commit to that work differs.
As Robert said, there will be lots of situations where the choice is either
to submit the fix without a test case or not submit the fix.  Which do
you think is the best approach?

Re: Ada policy

[Florian Weimer]

* Robert Dewar:

>> By the way , are copyright assignments for test cases required?  Or
>> could we just copy testcases from everywhere, provided that they come
>> with proper licensing conditions and there's no apparent show-stopper?
>
> What do you mean by "come with proper licensing conditions"?

Something which isn't downright GPL-incompatible or even
unredistributable.

> Please remember that notices at the start of a file have no legal
> significance whatever.

I wouldn't say that.  They won't help you much when you want to
determine the ultimate state of the work with respect to copyright, of
course.  But as Joe Buck wrote in 2000, the main goal is to make
complaints very unlikely, and to me, this suggests are more optimistic
approach.

Re: Ada policy

[Florian Weimer]

* Joseph S. Myers:

> On Tue, 31 Aug 2004, Florian Weimer wrote:
>
>> Debian's gnat package also contains a small but growing test suite.
>> 
>> By the way , are copyright assignments for test cases required?  Or
>> could we just copy testcases from everywhere, provided that they come
>> with proper licensing conditions and there's no apparent show-stopper?
>
> The description we have of the guidance from Eben Moglen is 
> <http://gcc.gnu.org/ml/gcc/2000-01/msg00593.html>.  I don't know if 
> there's a specific statement direct from him available.

Thanks, that doesn't look too bad.  We can probably use the Debian
testcases under this policy.

Laurent, shiuld I put you in touch with Debian's gnat maintainer?

Re: Ada policy

[Robert Dewar]

Mike Stump wrote:
> On Aug 30, 2004, at 3:34 PM, Joseph S. Myers wrote:
> 
>> Bugs shown by proprietary testcases should indeed be fixed.  But each
>> individual patch submission that can't include a testcase should 
>> include a
>> statement of why (e.g. that the test is proprietary and a synthetic one
>> not readily producable
> 
> 
> I think that one can misuse `readily producible'.  Certainly when I 
> spend hours upon hours trimming a testcase, I'm not feeling like the 
> testcase is readily producible, but I do it anyway.

It's certainly great that you have the bandwidth do do this, no one
would think otherwise.

Re: Ada policy

[Robert Dewar]

Mike Stump wrote:
> On Aug 30, 2004, at 2:21 PM, Richard Kenner wrote:
> 
>> second that nearly all of the test cases are proprietary code.
> 
> 
> Yes, and this was true of quite a few of the C/C++ testcases too...  
> but, this doesn't relieve the obligation to add a test case.
> 
> Don't start fixing a testcase until after you've trimmed the testcase 
> down, then you will find that all bugs you fix will have cut down test 
> cases.  A few bug fixes will never have testcases, that is fine.  A good 
> example is a memory smasher that randomly goes in and out of workingness 
> as the testcase is changed.  These will not usually have a testcase.  
> However the vast majority of the rest can have a minimal testcase 
> produced.  A few will need 12 hours to cut down the testcase, the bulk 
> of them should be substantially easier.

It's simply a matter of not having the resources to follow this
desirable approach.

> Sometimes there will be areas where the testing infrastructure doesn't 
> support testing, for which you'll just skip adding tests, this too is 
> fine to a degree.  In C/C++, this is done with stuff like cross module 
> or cross shared library issues...  Not perfect, but the best we can do 
> at the moment.  In time, we'll have a driver even for that.
> 
> We can describe the procedure to transform a proprietary testcase in 
> detail into one that isn't, if you want.  There is an algorithm.  
> Roughly, get testcase, remove every function, variable, block, 
> statement, argument that can be that doesn't affect the testcase.  
> Understand why what's left is minimal as you fix the bug, then try and 
> recode the testcase to make the things that happen to be true, to be 
> true.  For example, need register pressure, insert canonical code to 
> increase pressure...  Mostly works for me.  It is greedy, and has near 
> linear cost.  Further, at times, people automate it in various ways 
> (delta, slice)...  If it is a hardship, pick an automation to handle the 
> grunt work, or an intern...  Even a language agnostic one that just runs 
> the algorithm line by line might be enough for you...  One that is done 
> change all variable/function/type names and then examine code to be sure 
> that no trade secrets or original structure or original intent, use or 
> meaning is left that the customer would care about, if in doubt, just 
> ask them directly.

Again, we don't need to know how this is done, we know perfectly
well. We simply don't have the resources to do it (even keeping the
trees syncrhonized is a huge amount of work).

> So, I guess I am confused as to, do you just not want to do the work to 
> produce the testcases, or do you lack the understanding of how to do it?

It is not a matter of what we want, it is a matter of what we have the
resources to provide.

> As for the past, I'd say that while it would be nice to get more of the 
> Ada testcase that you have into the the FSF testsuite, I think it is 
> reasonable to merely require this of _new_ bugfixes to new 
> bugs/regressions.

But as I mentioned before, the practical effect of this requirement, if
you make it a requirement is that fixes will simply not get transferred
to the FSF tree in many cases. Mike, I encourage you to examine, in
detail, typical front end fixes, which is what we are talking about
here. I think the concern is more theoretical than actual.

Re: Ada policy

[Robert Dewar]

Joseph S. Myers wrote:
> On Mon, 30 Aug 2004, Robert Dewar wrote:
> 
> 
>>1. We submit fixes for bugs for which we have only proprietary
>>test cases, meaning that overall the quality of the Ada front
>>end will be higher, since for one thing, it will be far closer
>>to our in house tree for GNAT Pro (not quite indentical, since
>>there are things in the GNAT Pro tree that cannot go into the
>>FSF version for various reasons, related to FSF/GCC requirements,
>>not our requirements).

> Bugs shown by proprietary testcases should indeed be fixed.  But each 
> individual patch submission that can't include a testcase should include a 
> statement of why (e.g. that the test is proprietary and a synthetic one 
> not readily producable), and such bug fixes need more detailed 
> explanations of what the problem was and why and how the patch addressed 
> it, if not obvious, than bug fixes with included testcases, in case the 
> patch causes problems and someone trying to address those problems needs 
> to understand why the patch was needed in the first place.

In practice that is probably more of an issue with back end fixes
than front end fixes. Nearly all the front end fixes are clear, and
in any case the patch always includes appropriate comments. I am not
saying that following the above protocol would not be desirable, just
that in practice, we don't have the bandwidth to do much more than
the synchronization we are doing now. I do agree that general gcc
patches require appropriate documentation etc.
> 

Re: Ada policy

[Mike Stump]

On Aug 30, 2004, at 2:21 PM, Richard Kenner wrote:
> second that nearly all of the test cases are proprietary code.

Yes, and this was true of quite a few of the C/C++ testcases too...  
but, this doesn't relieve the obligation to add a test case.

Don't start fixing a testcase until after you've trimmed the testcase 
down, then you will find that all bugs you fix will have cut down test 
cases.  A few bug fixes will never have testcases, that is fine.  A 
good example is a memory smasher that randomly goes in and out of 
workingness as the testcase is changed.  These will not usually have a 
testcase.  However the vast majority of the rest can have a minimal 
testcase produced.  A few will need 12 hours to cut down the testcase, 
the bulk of them should be substantially easier.

Sometimes there will be areas where the testing infrastructure doesn't 
support testing, for which you'll just skip adding tests, this too is 
fine to a degree.  In C/C++, this is done with stuff like cross module 
or cross shared library issues...  Not perfect, but the best we can do 
at the moment.  In time, we'll have a driver even for that.

We can describe the procedure to transform a proprietary testcase in 
detail into one that isn't, if you want.  There is an algorithm.  
Roughly, get testcase, remove every function, variable, block, 
statement, argument that can be that doesn't affect the testcase.  
Understand why what's left is minimal as you fix the bug, then try and 
recode the testcase to make the things that happen to be true, to be 
true.  For example, need register pressure, insert canonical code to 
increase pressure...  Mostly works for me.  It is greedy, and has near 
linear cost.  Further, at times, people automate it in various ways 
(delta, slice)...  If it is a hardship, pick an automation to handle 
the grunt work, or an intern...  Even a language agnostic one that just 
runs the algorithm line by line might be enough for you...  One that is 
done change all variable/function/type names and then examine code to 
be sure that no trade secrets or original structure or original intent, 
use or meaning is left that the customer would care about, if in doubt, 
just ask them directly.

So, I guess I am confused as to, do you just not want to do the work to 
produce the testcases, or do you lack the understanding of how to do 
it?

As for the past, I'd say that while it would be nice to get more of the 
Ada testcase that you have into the the FSF testsuite, I think it is 
reasonable to merely require this of _new_ bugfixes to new 
bugs/regressions.

Re: Ada policy

[Mike Stump]

On Aug 30, 2004, at 3:34 PM, Joseph S. Myers wrote:
> Bugs shown by proprietary testcases should indeed be fixed.  But each
> individual patch submission that can't include a testcase should 
> include a
> statement of why (e.g. that the test is proprietary and a synthetic one
> not readily producable

I think that one can misuse `readily producible'.  Certainly when I 
spend hours upon hours trimming a testcase, I'm not feeling like the 
testcase is readily producible, but I do it anyway.

Re: Ada policy

[Joseph S. Myers]

On Mon, 30 Aug 2004, Robert Dewar wrote:

> 1. We submit fixes for bugs for which we have only proprietary
> test cases, meaning that overall the quality of the Ada front
> end will be higher, since for one thing, it will be far closer
> to our in house tree for GNAT Pro (not quite indentical, since
> there are things in the GNAT Pro tree that cannot go into the
> FSF version for various reasons, related to FSF/GCC requirements,
> not our requirements).

Bugs shown by proprietary testcases should indeed be fixed.  But each 
individual patch submission that can't include a testcase should include a 
statement of why (e.g. that the test is proprietary and a synthetic one 
not readily producable), and such bug fixes need more detailed 
explanations of what the problem was and why and how the patch addressed 
it, if not obvious, than bug fixes with included testcases, in case the 
patch causes problems and someone trying to address those problems needs 
to understand why the patch was needed in the first place.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Ada policy

[Robert Dewar]

> By the way , are copyright assignments for test cases required?  Or
> could we just copy testcases from everywhere, provided that they come
> with proper licensing conditions and there's no apparent show-stopper?

What do you mean by "come with proper licensing conditions"? Please
remember that notices at the start of a file have no legal significance
whatever.

Re: Ada policy

[Robert Dewar]

Richard Kenner wrote:
>     A while ago I asked for these 0000-xxx tests (I believe they are those
>     you describe, right?) 

In fact I sent a few along as you will remember! Nothing seemed to
happen with them, so doing more of them is on my list, but not done
yet.
> 
> Well, 000x-xxx, but yes.
> 
>     The current ACATS harness need no or little modification to run
>     non ACATS tests, if no one has another Ada-aware harness at hand, I can
>     collect the test cases from the GCC archives and put them there.
> 
> Doesn't that harness depend on the test using the Report mechanism,
> which random tests won't do?  Certainly most of the one you cite don't:
> they rely on printing output and comparing it with a known-good file.

None of our purpose written tests use report, they all use a comparison
approach, as Richard knows.
> 
> You're familiar with the format of those tests.  Some harness that could
> run them would be a good start.

Re: Ada policy

[Robert Dewar]

Joseph S. Myers wrote:
> On Mon, 30 Aug 2004, Richard Kenner wrote:
> 
> 
>>There are two problems here.  First, there is no testsuite harness to
>>add the available test cases (as you say) and second that nearly all
>>of the test cases are proprietary code.
>>
>>If somebody volunteers to do the former, that problem will go away.
>>But the second problem is more serious, especially if you enlarge
>>the set of changes that need test cases to front-end changes.
> 
> 
> *Some* tests are proprietary code. 

Actually *most* tests for fixed bugs are proprietary code.

> But there are all the Ada testcases 
> you've sent to the lists over the years (apart from those derived from 
> ACATS), which are public even though they may be synthetic tests to cover 
> problems originally shown in proprietary code

Yes, there are a few cases like this.


, and tests that were
> submitted to GCC Bugzilla, and tests written by the authors of front-end 
> features (rather than based on proprietary code showing a bug) when they 
> add such features.

Right, these feature tests are indeed distributable

> (If testcases suitable for automated testing aren't 
> routinely written when new front end features are added,

Actually they are typically written *before* the features
are added.

Re: Ada policy

[Robert Dewar]

> If somebody volunteers to do the former, that problem will go away.
> But the second problem is more serious, especially if you enlarge
> the set of changes that need test cases to front-end changes.

Indeed, though there are a fair number of tests that could be
provided (e.g. the tests we write for ourselves for new features).

But the majority of test code is indeed proprietary, and certainly
we don't have the bandwidth at AdaCore to do what can sometimes
be an extremely difficult job of providing independent distributable
tests.

So there are really two choices.

1. We submit fixes for bugs for which we have only proprietary
test cases, meaning that overall the quality of the Ada front
end will be higher, since for one thing, it will be far closer
to our in house tree for GNAT Pro (not quite indentical, since
there are things in the GNAT Pro tree that cannot go into the
FSF version for various reasons, related to FSF/GCC requirements,
not our requirements).

2. We simply avoid fixing problems in the FSF tree for which
we don't have distributable test cases. That's difficult but
possible.

I am dubious that 2. is advantageous for anyone ...

Re: Ada policy

[Joseph S. Myers]

On Tue, 31 Aug 2004, Florian Weimer wrote:

> Debian's gnat package also contains a small but growing test suite.
> 
> By the way , are copyright assignments for test cases required?  Or
> could we just copy testcases from everywhere, provided that they come
> with proper licensing conditions and there's no apparent show-stopper?

The description we have of the guidance from Eben Moglen is 
<http://gcc.gnu.org/ml/gcc/2000-01/msg00593.html>.  I don't know if 
there's a specific statement direct from him available.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Ada policy

[Florian Weimer]

* Joseph S. Myers:

> On Mon, 30 Aug 2004, Richard Kenner wrote:
>
>> There are two problems here.  First, there is no testsuite harness to
>> add the available test cases (as you say) and second that nearly all
>> of the test cases are proprietary code.
>> 
>> If somebody volunteers to do the former, that problem will go away.
>> But the second problem is more serious, especially if you enlarge
>> the set of changes that need test cases to front-end changes.
>
> *Some* tests are proprietary code.  But there are all the Ada testcases 
> you've sent to the lists over the years (apart from those derived from 
> ACATS), which are public even though they may be synthetic tests to cover 
> problems originally shown in proprietary code, and tests that were 
> submitted to GCC Bugzilla, and tests written by the authors of front-end 
> features (rather than based on proprietary code showing a bug) when they 
> add such features.

Debian's gnat package also contains a small but growing test suite.

By the way , are copyright assignments for test cases required?  Or
could we just copy testcases from everywhere, provided that they come
with proper licensing conditions and there's no apparent show-stopper?

Re: Ada policy

[Robert Dewar]

Richard Henderson wrote:
> On Mon, Aug 30, 2004 at 01:34:25PM -0700, Zack Weinberg wrote:
> 
>>http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html
> 
> 
> For the record, I completely agree.

Reading Zack's message:

> Second, the Ada maintainers have said in the past that they
> deliberately break source compatibility between releases (such that
> GCC 3.x with Ada is only guaranteed to be buildable with GCC 3.(x-1)).

That's entirely wrong. Nothing is broken deliberately, and no one
ever said anything of the kind. What they did say is that it
is not always feasible to maintain what Zack would like:

> There must be
> guaranteed bidirectional source compatibility between all 3.x branches
> of GCC, such that it is possible to build any 3.x version of GNAT with
> any other 3.x version of GNAT.

Unfortunately there are occasionally cases where bugs cannot
be fixed without breaking this requirement. It's relatively
rare, and for some time now, GNAT has been able to be built
with a pretty significant variety of starting compilers,
though no one guarantees this to be the case (the only
guarantee is that it builds with the most recent release,
although in practice we have been using a much older
compiler internally for starting builds).

Note that this is particularly the case if the GCC community
decides to stick with 3.xx designations indefinitely.

Re: Ada policy

[Richard Kenner]

    A while ago I asked for these 0000-xxx tests (I believe they are those
    you describe, right?) 

Well, 000x-xxx, but yes.

    The current ACATS harness need no or little modification to run
    non ACATS tests, if no one has another Ada-aware harness at hand, I can
    collect the test cases from the GCC archives and put them there.

Doesn't that harness depend on the test using the Report mechanism,
which random tests won't do?  Certainly most of the one you cite don't:
they rely on printing output and comparing it with a known-good file.

You're familiar with the format of those tests.  Some harness that could
run them would be a good start.

Re: Ada policy

[Laurent GUERBY]

On Mon, 2004-08-30 at 23:44, Richard Kenner wrote:
> As I said, there are indeed a large number of tests cases that can be added
> to a harness: those that were posted and at least 200 tests that were written
> specifically to test new features.  

A while ago I asked for these 0000-xxx tests (I believe they are those
you describe, right?) but I believe I never got them. If someone
could make a tarball of them and ship them to me, that would be great.

> But we need the harness.

The current ACATS harness need no or little modification to run
non ACATS tests, if no one has another Ada-aware harness at hand, I can
collect the test cases from the GCC archives and put them there.

Laurent

Re: Ada policy

[Richard Kenner]

    *Some* tests are proprietary code.  But there are all the Ada
    testcases you've sent to the lists over the years (apart from those
    derived from ACATS), which are public even though they may be
    synthetic tests to cover problems originally shown in proprietary
    code, and tests that were submitted to GCC Bugzilla, and tests written
    by the authors of front-end features (rather than based on proprietary
    code showing a bug) when they add such features.

Sorry, I wasn't clear.

What I meant was that virtually all of the *original* test cases were
proprietary code.  There have certainly been times when I (or somebody ele)
has synthesized smaller tests from those.  But doing so in general takes a
lot of time and isn't always possible (e.g. in the case of reload or
scheduling bugs where changing *anything* in the source makes the problem go
away.

As I said, there are indeed a large number of tests cases that can be added
to a harness: those that were posted and at least 200 tests that were written
specifically to test new features.  But we need the harness.

    (If testcases suitable for automated testing aren't routinely written
    when new front end features are added, then starting writing such
    tests to accompany future features is simply part of following the
    usual GCC development practice followed for other front ends.)

Usually, when new languages features are added to Ada, the "language folks"
write new ACATS tests for them.  That has not been happening recently, but
people who are implementing features from Ada 2005 have been writing tests in
the ACATS style for them.  These should eventually make their way into the
official ACATS suite, but there needs to be a place for them in the meantime.

Re: Ada policy

[Joseph S. Myers]

On Mon, 30 Aug 2004, Richard Kenner wrote:

> There are two problems here.  First, there is no testsuite harness to
> add the available test cases (as you say) and second that nearly all
> of the test cases are proprietary code.
> 
> If somebody volunteers to do the former, that problem will go away.
> But the second problem is more serious, especially if you enlarge
> the set of changes that need test cases to front-end changes.

*Some* tests are proprietary code.  But there are all the Ada testcases 
you've sent to the lists over the years (apart from those derived from 
ACATS), which are public even though they may be synthetic tests to cover 
problems originally shown in proprietary code, and tests that were 
submitted to GCC Bugzilla, and tests written by the authors of front-end 
features (rather than based on proprietary code showing a bug) when they 
add such features.  (If testcases suitable for automated testing aren't 
routinely written when new front end features are added, then starting 
writing such tests to accompany future features is simply part of 
following the usual GCC development practice followed for other front 
ends.)

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Ada policy

[Richard Kenner]

    for example, fixes to bugs with public non-ACATS testcases don't get
    them added to the testsuite (and there is no harness to add them to)
    although a fair number of such testcases have been posted to the lists
    over the years which ought to be in the testsuite.

There are two problems here.  First, there is no testsuite harness to
add the available test cases (as you say) and second that nearly all
of the test cases are proprietary code.

If somebody volunteers to do the former, that problem will go away.
But the second problem is more serious, especially if you enlarge
the set of changes that need test cases to front-end changes.

Re: Ada policy

[Diego Novillo]

On Mon, 2004-08-30 at 16:57, Richard Henderson wrote:
> On Mon, Aug 30, 2004 at 01:34:25PM -0700, Zack Weinberg wrote:
> > http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html
> 
> For the record, I completely agree.
> 
Likewise.


Diego.

Re: Ada policy

[Joseph S. Myers]

On Mon, 30 Aug 2004, Zack Weinberg wrote:

> http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

Ada changes do now come with associated documentation.  I don't think any 
of the other problems have been fixed; for example, fixes to bugs with 
public non-ACATS testcases don't get them added to the testsuite (and 
there is no harness to add them to) although a fair number of such 
testcases have been posted to the lists over the years which ought to be 
in the testsuite.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Ada policy

[Richard Henderson]

On Mon, Aug 30, 2004 at 01:34:25PM -0700, Zack Weinberg wrote:
> http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

For the record, I completely agree.


r~

Re: Ada policy

[Richard Guenther]

Zack Weinberg wrote:
> Laurent GUERBY <laurent@guerby.net> writes:
> 
> 
>>On Mon, 2004-08-30 at 21:28, Florian Weimer wrote:
>>
>>>I understand that Ada is already in much better shape than we
>>>expected it to be before the tree-ssa merge (and that's certainly
>>>good news!), but I really doubt we should make a release criterion
>>>the quality of a component that has received very little testing by
>>>the general GCC community.
>>
>>I'm just talking about bootstrap, passing ACATS and no known
>>regression on two targets, not "quality" in general (whatever that
>>means).
>>
>>The scenario I want to avoid is that we first reach 100% ACATS pass on
>>the two targets (looks likely), then later a patch goes in that
>>introduces 20 ACATS regressions on those two targets and the patch is
>>not fixed or reverted following the usual rules for other components.
> 
> 
> The last time this came up, I posted a list of requirements which I
> consider non-negotiable prerequisites for the community at large being
> required to test Ada when they are not specifically working on it.
> This list received no commentary whatsoever, and no progress has been
> made toward meeting any of the requirements except the separate libada
> (which seems to have stalled).
> 
> http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

Maybe testing rules could be relaxed if we had a GENERIC/GIMPLE 
front-end to fed it testcases which cannot be constructed using C code. 
  That way testing of frontends different from C could be omitted, if 
not modifying them.

Richard.

Re: Ada policy

[Zack Weinberg]

Laurent GUERBY <laurent@guerby.net> writes:

> On Mon, 2004-08-30 at 21:28, Florian Weimer wrote:
>> I understand that Ada is already in much better shape than we
>> expected it to be before the tree-ssa merge (and that's certainly
>> good news!), but I really doubt we should make a release criterion
>> the quality of a component that has received very little testing by
>> the general GCC community.
>
> I'm just talking about bootstrap, passing ACATS and no known
> regression on two targets, not "quality" in general (whatever that
> means).
>
> The scenario I want to avoid is that we first reach 100% ACATS pass on
> the two targets (looks likely), then later a patch goes in that
> introduces 20 ACATS regressions on those two targets and the patch is
> not fixed or reverted following the usual rules for other components.

The last time this came up, I posted a list of requirements which I
consider non-negotiable prerequisites for the community at large being
required to test Ada when they are not specifically working on it.
This list received no commentary whatsoever, and no progress has been
made toward meeting any of the requirements except the separate libada
(which seems to have stalled).

http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

zw