Re: GCC 3.5 Status (2004-08-29)

Re: GCC 3.5 Status (2004-08-29)

[Richard Kenner]

    I notice that the, uh, "project" to get Ada bootstrapping (Kenner,
    when can we expect this?) is not listed.  These changes will
    presumably be accepted in stage 3?

Because it's not a "project" in the sense of new development, but rather
bugs that Ada triggers in middle-end code.   Fixing bugs is Stage 3 work.
So the timing of the Ada work is not relevent to entering Stage 3.

    However, I'm beginning to worry that Ada is going to delay the release
    of GCC 3.5 substantially if it's not bootstrapping soon, because the
    long period without Ada bootstrapping is likely to lead to bug
    discoveries when Ada is revived from the dead.

Well it was bootstrapping on and off but indeed various changes have broken
it for about two weeks.  Part of the reason for the long period was that I
was in Europe for a meeting for about a week.

In any event, as of yesterday afternoon, I have it bootstrapping in my tree.
It should be bootstrapping again in the GCC CVS in a day or so.  It'll be
more work to get it ACATS clean because some of the kludges I used to work
around bugs will need to be converted into the proper fix.

    Is Ada functioning a requirement for the release?  If so it seems a
    moderately bad idea to go into stage 3 with it totally busted.

The answer to the first question has always been "no".  But in practice,
my expectation is that it will work fine on the release.

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 12:22, Richard Kenner wrote:
> >    Is Ada functioning a requirement for the release?  If so it seems a
> >    moderately bad idea to go into stage 3 with it totally busted.
> 
> The answer to the first question has always been "no".  But in practice,
> my expectation is that it will work fine on the release.

We had a barely working Ada compiler in 3.3 (fortunately enough for
bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
on x86 and x86_64 at -O2.

I believe it's reasonable now to make it a requirement that Ada works in
future GCC releases, at least on x86 and x86_64 with no regression.

Laurent

Re: GCC 3.5 Status (2004-08-29)

[Jakub Jelinek]

On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> On Mon, 2004-08-30 at 12:22, Richard Kenner wrote:
> > >    Is Ada functioning a requirement for the release?  If so it seems a
> > >    moderately bad idea to go into stage 3 with it totally busted.
> > 
> > The answer to the first question has always been "no".  But in practice,
> > my expectation is that it will work fine on the release.
> 
> We had a barely working Ada compiler in 3.3 (fortunately enough for
> bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass

Well, fully working on x86, not working in 3.4 on 64-bit architectures
and not working on ppc32 (while it worked in 3.3 on all of them).

	Jakub

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 11:06, Jakub Jelinek wrote:
> On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> > We had a barely working Ada compiler in 3.3 (fortunately enough for
> > bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> > 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
> > on x86 and x86_64 at -O2.
>
> Well, fully working on x86, not working in 3.4 on 64-bit architectures
> and not working on ppc32 (while it worked in 3.3 on all of them).

3.3 did not have ACATS so working = bootstrap, which doesn't
mean much for end user (I know of no one successfully using Ada with FSF
3.3 except for bootstraping 3.4).

3.4 on x86_64 (so 64 bits) is not that broken, 6 fail on 2316 tests.

(Also I believe s390 and s390x results were quite good before tree-ssa)

But back to the point, is not having *all* architectures perfectly
working for a language a reason to allow breaking of previously working
architectures? 

Is the requirement for not release GCC with broken Ada on x86 and x86_64
too strong?

Laurent

Re: GCC 3.5 Status (2004-08-29)

[Jakub Jelinek]

On Mon, Aug 30, 2004 at 08:01:34PM +0200, Laurent GUERBY wrote:
> On Mon, 2004-08-30 at 11:06, Jakub Jelinek wrote:
> > On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> > > We had a barely working Ada compiler in 3.3 (fortunately enough for
> > > bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> > > 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
> > > on x86 and x86_64 at -O2.
> >
> > Well, fully working on x86, not working in 3.4 on 64-bit architectures
> > and not working on ppc32 (while it worked in 3.3 on all of them).
> 
> 3.3 did not have ACATS so working = bootstrap, which doesn't
> mean much for end user (I know of no one successfully using Ada with FSF
> 3.3 except for bootstraping 3.4).
> 
> 3.4 on x86_64 (so 64 bits) is not that broken, 6 fail on 2316 tests.

It bootstraps for me only if I use 3.3 as a bootstrap compiler,
not when using 3.4 as a bootstrap compiler, see
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00911.html
(this happened on ia64 and x86-64 at least).

On ppc32, the problem is
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00981.html

	Jakub

Re: GCC 3.5 Status (2004-08-29)

[Florian Weimer]

* Laurent GUERBY:

> Is the requirement for not release GCC with broken Ada on x86 and x86_64
> too strong?

When was the last successful bootstrap of mainline, with Ada enabled?

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.

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 18:24, Jakub Jelinek wrote:
> It bootstraps for me only if I use 3.3 as a bootstrap compiler,
> not when using 3.4 as a bootstrap compiler, see
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00911.html
> (this happened on ia64 and x86-64 at least).

I did not notice this one, the attached patch "cures"
the problem on my x86_64 box using 3.4.1 to bootstrap
(at the total cost of 10-15 seconds of rebuilding various things).

I'm not sure if I'm just working around -O2 code generation
problems in 3.4.1 or doing something more "correct"
with respect to the bootstrap process.

Arnaud?

I'll do more testing shortly (x86_64 starting with 3.3 and x86 with 3.3
and 3.4).

> On ppc32, the problem is
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00981.html

Unfortunately I don't have access to this platform. May be Eric
as author of the patch that introduced the problem has an idea?

Laurent

--- Make-lang.in.orig   2004-08-30 21:13:02.824369585 +0200
+++ Make-lang.in        2004-08-30 21:22:13.595332552 +0200
@@ -988,27 +988,32 @@
 ada/treeprs.ads : ada/treeprs.adt ada/sinfo.ads ada/xtreeprs.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xtreeprs ; ./xtreeprs ../treeprs.ads )
+       (cd ada/bldtools; gnatmake -q -a -f xtreeprs ; \
+        ./xtreeprs ../treeprs.ads )

 ada/einfo.h : ada/einfo.ads ada/einfo.adb ada/xeinfo.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xeinfo ; ./xeinfo ../einfo.h )
+       (cd ada/bldtools; gnatmake -q -a -f xeinfo ; \
+        ./xeinfo ../einfo.h )

 ada/sinfo.h : ada/sinfo.ads ada/xsinfo.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xsinfo ; ./xsinfo ../sinfo.h )
+       (cd ada/bldtools; gnatmake -q -a -f xsinfo ; \
+        ./xsinfo ../sinfo.h )

 ada/nmake.adb : ada/sinfo.ads ada/nmake.adt ada/xnmake.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xnmake ; ./xnmake -b ../nmake.adb )
+       (cd ada/bldtools; gnatmake -q -a -f xnmake ; \
+        ./xnmake -b ../nmake.adb )

 ada/nmake.ads :  ada/sinfo.ads ada/nmake.adt ada/xnmake.adb ada/nmake.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xnmake ; ./xnmake -s ../nmake.ads )
+       (cd ada/bldtools; gnatmake -q -a -f xnmake ; \
+        ./xnmake -s ../nmake.ads )

 update-sources : ada/treeprs.ads ada/einfo.h ada/sinfo.h ada/nmake.adb \
        ada/nmake.ads

Ada policy (was: GCC 3.5 Status (2004-08-29))

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

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. 

Is that what you want for Ada now? If not, why not spell it out clearly
to avoid discussions with no time left later on? Also
if this rule is not set now, I see no reason for it to be set later
then, and that's not good news for the GNU Compiler _Collection_
Ada-wise.

Laurent

PS: I have tested and will test again at work our 500 KSLOC software
with FSF CVS.

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

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

[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

[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

[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

[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

[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

[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

[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]

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:

> 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

[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

[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

[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: GCC 3.5 Status (2004-08-29)

[Eric Botcazou]

> > On ppc32, the problem is
> > http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00981.html
>
> Unfortunately I don't have access to this platform. May be Eric
> as author of the patch that introduced the problem has an idea?

Err... my patch can't have retroactively introduced a problem.

-- 
Eric Botcazou

Re: GCC 3.5 Status (2004-08-29)

[Arnaud Charlet]

> I'm not sure if I'm just working around -O2 code generation
> problems in 3.4.1 or doing something more "correct"
> with respect to the bootstrap process.
> 
> Arnaud?

Certainly looks like a work around to me, to avoid a codegen problem at
-O2 in the bootstrap compiler, since you're forcing recompilation of the same
run time files at a different optimization level.

That being said, if this change can make more people able to test Ada
that would be a good reason to put this change in, although I'd rather
only do a minimal change (e.g. only do a gnatmake -f -a on the first file to
be built, and not do a -f -a on others, since they should use the newly
compiled files anyway) with proper documentation on why this peculiar
change is done.

Arno

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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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:

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

[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]

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

[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]

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

[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

[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

[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

[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

[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

[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

[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]

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 (was: GCC 3.5 Status (2004-08-29))

[Laurent GUERBY]

On Mon, 2004-08-30 at 22:28, Richard Kenner wrote:
>     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. 
> 
> Yes, but that's a *different* standard.  What you are talking about
> if whether the commit rules will require running ACATS to commit a
> patch.  

Sorry I wasn't clear on my intent. The commit rules don't require you to
test on all the platforms, but if someone report that you break one you
didn't test, it's still considered your fault and you should try to help
on the issue, and in some extreme cases the patch could be reverted (at
least that's my understanding).

This "platform" rule could also be applied to components, you don't
necessarily have to test Ada, but if someones points out
a breakage, you have to be helpful on the issue.

(BTW I didn't find on the web site a link to the 3.4 release criteria
page http://gcc.gnu.org/gcc-3.4/criteria.html, and didn't find one for
3.5 did I miss something?)

> The question raised was whether Ada should be part of the
> release criteria.
> 
> These are not the same.

May be but I must admit I fail to see the practical difference, if
you're not continuously looking in some way at regressions on one
platform or component for a full development cycle, it's unlikely that
you'll be able to reach any relase criteria involving this platform or
component at the end of the cycle (without potential delays).

The current rules differ on who should be "looking" at regressions
depending on component vs platform (the patch submitter or someone
else), but that's less important IMHO than having a consistent rule on
what to do when a regression is detected on a particular patch.

Laurent

Re: Ada policy (was: GCC 3.5 Status (2004-08-29))

[Richard Kenner]

    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. 

Yes, but that's a *different* standard.  What you are talking about
if whether the commit rules will require running ACATS to commit a
patch.  The question raised was whether Ada should be part of the
release criteria.

These are not the same.