Re: Ada files now checked in

Re: Ada files now checked in

[Richard Kenner]

    It's my contention that the FSF tree needs to support a broader range
    of situations than the ACT internal tree does.  

True, but that doesn't mean *every possible* situation.  There is no
long-term reason why you would have a different driver name and there
is no point in adding extra rules for such a transitory situation.

Re: Ada files now checked in

[Zack Weinberg]

I'm responding to all your mail at once.

On Sat, Oct 06, 2001 at 08:59:14PM -0400, Richard Kenner wrote:
>     It's my contention that the FSF tree needs to support a broader range
>     of situations than the ACT internal tree does.  
> 
> True, but that doesn't mean *every possible* situation.  There is no
> long-term reason why you would have a different driver name and there
> is no point in adding extra rules for such a transitory situation.

Vendor packaging will not change until well after the release of GCC
3.1.  I would estimate at least six months before they even consider
making it their default system compiler.  Therefore, the soonest that
there is likely to be a release of Linux or *BSD with "gcc" capable of
Ada is the end of 2002.  The soonest that it will be widespread enough
that we can even *consider* ignoring earlier configurations is 2004.

It is ridiculous to speak of a situation as "transitory" when its
duration is measured in years.

> "Wrong" or "right" isn't a meaningful term here.  The point is that
> neither FSF nor ACT has ever viewed this as a configuration that
> needs to be supported.

ACT may not have.  Given RMS's comments cited by Joseph, I am not
convinced the FSF agrees.  Please provide evidence for this statement.

>     This "short period" you refer to stretches from now until GCC >=3.1
>     (including Ada) is the default system compiler on every relevant
>     platform. 
>
> No, not at all.  Just until the *first time* gnat is build from a
> gnat1 and gnatbind.  Then you can just use what you built.  You
> don't have to wait for a release.

A system integrator packaging gnat will not be willing to do any such
thing.  They will, instead, create patches similar to the one I
submitted, so that they can build gnat without manual intervention
using the software they already have installed.

>     3. You have a complete gnat provided by your system integrator.
> 
> But there are few such.  The major one is SGI, and they call the
> driver "gcc".

Debian and Red Hat both call it "gnatgcc".  FreeBSD calls it "adagcc".
(NetBSD and OpenBSD don't seem to have native packages.)

ACT can pretend they don't exist.  We can't.

>     No.  I have either to do the manual procedure *every time I build the
>     compiler*, or I am not testing with the vendor-provided packages
>     anymore, and that is the whole point.
> 
> Why is that the "whole point"?  I often do "make install" and from then on
> use that compiler (both C and Ada) for my compilations.

It's the whole point because that most closely mimics what our users
do when they install GCC.  If I am not testing the same thing they
are, my tests do not provide any confidence in what will happen when
they do it.

> As Robert says, there is no assurance that any vendor-supplied GNAT can
> be used to bootstrap GNAT 5.0.  Perhaps the SGI-version can, but I'm not
> sure and don't particularly care.  That's what the gnat1 and gnatbind
> binaries will be for.

As I've said, if the existing packaged GNATs don't work, that is fine
by me.  What I object to is refusing to even let them try because they
happen not to have the official name.

zw

Re: Ada files now checked in

[Richard Henderson]

On Sat, Oct 06, 2001 at 09:17:07PM -0700, Zack Weinberg wrote:
> As I've said, if the existing packaged GNATs don't work, that is fine
> by me.  What I object to is refusing to even let them try because they
> happen not to have the official name.

I, for one, completely agree with you.  Your patch should go in.


r~

Re: Ada files now checked in

[dewar]

<<Ouch.  You mean, even before constant folding and elimination of a
not-taken branch of an "if"?  That would greatly increase the number of
false positives over what we have now.
>>

I think that is indeed a problem. In GNAT, we also detected these warnings
early, before elimination of dead code, and found that was a problem (we now
have a circuit to remove associated warnings when dead code is eliminated).

Re: Ada files now checked in

[dewar]

<<> - if its only reaching definition is the ghost def, the variable
>   *is* used uninitialized.

Not generally true.  The uninitialized use might never be executed.
Back to the halting problem...
>>

A warning is generally saying that IF the code is executed, THEN there
is a problem. Sure it is nice to delete such warnings in obviously
deactivated code (GNAT certainly does that, since the use of constant
booleans to achieve the effect of conditional compilation is standard
practice), but obviously this cannot be done in general. So if you
regard this as an unacceptable obstacle, you will have to get rid of
all warnings of runtime errors, which would be too bad.

Re: Ada files now checked in

[Joern Rennecke]

Diego Novillo:
> <<> - if its only reaching definition is the ghost def, the variable
> >   *is* used uninitialized.
...

dewar:
> A warning is generally saying that IF the code is executed, THEN there
> is a problem. Sure it is nice to delete such warnings in obviously

That's okay with me, as long as it is kept in mind that such a warning
might still be a false positive inasmuch as the code might be unreachable.
Diegos statement sounded a bit too absolute.  When his explanation goes
into a piece of documentation, it should be qualified as you did above.

Moreover, warnings that can give false positives should have an option
to turn them off, lest all warnings become useless in code that triggers
false positives of one kind too often.  I know we can do that right now
with uninitialized warnings, but the temptation might be there if you
thought that your 'is used uninitialized' warning never gave false
positives to make it independent of -Wuninitialized.

Re: Ada files now checked in

[Diego Novillo]

On Sun, 14 Oct 2001, Joern Rennecke wrote:

> Diego Novillo:
> > <<> - if its only reaching definition is the ghost def, the variable
> > >   *is* used uninitialized.
> ...
> 
> dewar:
> > A warning is generally saying that IF the code is executed, THEN there
> > is a problem. Sure it is nice to delete such warnings in obviously
> 
> That's okay with me, as long as it is kept in mind that such a warning
> might still be a false positive inasmuch as the code might be unreachable.
> Diegos statement sounded a bit too absolute.  When his explanation goes
> into a piece of documentation, it should be qualified as you did above.
> 
Yes.  My statement had been hastily worded.  The implicit
assumption is that the code is indeed reachable.  I will update
the documentation for -Wuninitialized.  Thanks.

This warning is not on by default, it's only triggered by
-Wuninitialized.  I expect more false positives for the 'maybe
used uninitialized'  message.  Mostly because we are emitting the
warning before any optimizations are performed.  (See my message
on merging tree SSA for 3.1
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00609.html )

Diego.

Re: Ada files now checked in

[Joe Buck]

[ arguments about -Winitialized, halting problem etc] 

Diego writes:

> This warning is not on by default, it's only triggered by
> -Wuninitialized.  I expect more false positives for the 'maybe
> used uninitialized'  message.  Mostly because we are emitting the
> warning before any optimizations are performed.

Ouch.  You mean, even before constant folding and elimination of a
not-taken branch of an "if"?  That would greatly increase the number of
false positives over what we have now.

Re: Ada files now checked in

[Diego Novillo]

On Mon, 15 Oct 2001, Joe Buck wrote:

> > This warning is not on by default, it's only triggered by
> > -Wuninitialized.  I expect more false positives for the 'maybe
> > used uninitialized'  message.  Mostly because we are emitting the
> > warning before any optimizations are performed.
> 
> Ouch.  You mean, even before constant folding and elimination of a
> not-taken branch of an "if"?  That would greatly increase the number of
> false positives over what we have now.
> 
Right now, yes.  Over time we will start moving this warning down
the transformation chain.  There is work in progress to add
constant propagation that should run before this.

Of course, if you move this down too much you will go back to the
problem of only supporting -Wuninitialized only if -O is used.

Or maybe we could allow cleanup passes to run whenever
-Wuninitialized is used.  It's only a matter of deciding when to
run it, really.  The basic analysis won't change.


Diego.

Re: Ada files now checked in

[Joe Buck]

> On Mon, 15 Oct 2001, Joe Buck wrote:
> 
> > > This warning is not on by default, it's only triggered by
> > > -Wuninitialized.  I expect more false positives for the 'maybe
> > > used uninitialized'  message.  Mostly because we are emitting the
> > > warning before any optimizations are performed.
> > 
> > Ouch.  You mean, even before constant folding and elimination of a
> > not-taken branch of an "if"?  That would greatly increase the number of
> > false positives over what we have now.
> > 
> Right now, yes.  Over time we will start moving this warning down
> the transformation chain.  There is work in progress to add
> constant propagation that should run before this.
> 
> Of course, if you move this down too much you will go back to the
> problem of only supporting -Wuninitialized only if -O is used.

I'd rather require -O for -Wuninitialized than have a broken and useless
-Wuninitialized.  You'll just steer people in the direction of making
their programs worse, by adding unneeded initializers.

Maybe the uninitialized warnings should be split in two.  We can identify
three cases:

1) if the function is called an uninitialized use of foo will always occur.
2) if the function is called an uninitialized use of foo will never occur.
3) can't tell (analysis too weak, halting problem etc).

Improving the analysis reduces the size of set 3 and creates more members
of sets 1 and 2.  But it seems that we could warn by default for set 1,
reporting obvious errors even with -O off, and have a flag that turns on
warnings for set 3.

Re: Ada files now checked in

[Diego Novillo]

On Mon, 15 Oct 2001, Joe Buck wrote:

> Maybe the uninitialized warnings should be split in two.  We can identify
> three cases:
> 
> 1) if the function is called an uninitialized use of foo will always occur.
> 2) if the function is called an uninitialized use of foo will never occur.
> 3) can't tell (analysis too weak, halting problem etc).
> 
> Improving the analysis reduces the size of set 3 and creates more members
> of sets 1 and 2.  But it seems that we could warn by default for set 1,
> reporting obvious errors even with -O off, and have a flag that turns on
> warnings for set 3.

Sounds good to me.  Thanks a lot for the feedback.  I'll work a
patch for splitting the analysis and add a new -Wuninitialized
flag for reporting the 'maybes'.

Diego.

Re: Ada files now checked in

[dewar]

>>I'm surprised to read that English grammar includes typography. ;-)

it most certainly includes punctuation, and that is what we are talking
about here! A quotation (which is what this is) appears in quotation
marks (which look roughly like "").

The character ` is indeed a grave accent in Latin-1, and of course English
doesn't have accents at all, further clarifying my point (I used the
phrase reverse quote, since I thought it would be more familiar to
english readers, and furthermore, that's what is going on here, we
are misusing a grave accent as an opening quotation mark. Indeed it
is a bit odd if we insist on this misuse, that we do not also use
Acute (Latin-1 code 180) as the closing quote, at least that would
be just slightly less odd to the eye.

The character ' is by the way an apostrophe, not a quote. The normal
english use is in posessives, and there is a special rule about using
it for nested quotations in place of normal quote marks.

Note that this is not completely idle discussion, the GNAT message insertions
do use quotations as in:

j.adb:3:04: "xyz" is undefined

compared to the c message

j.c:1: `asdf' undeclared (first use this function)

SO we definitely have a non-uniform usage here (and I don't think that
GNAT is about to change, or more accurately, I do not think that the ACT
version of GNAT is going to change). By the way the exact text of error
messages in GNAT should not be casually changed, since it is in the baselines
for the ACATS B tests. This does not mean that it cannot be changed, just
that if anyone changes anything, they have to check the ACATS B test baselines.

Re: Ada files now checked in

[Gabriel Dos Reis]

dewar@gnat.com writes:

| j.adb:3:04: "xyz" is undefined
| 
| compared to the c message
| 
| j.c:1: `asdf' undeclared (first use this function)

For a non-native English speaker like me, I have always questioned
myself why the latter choice (which I find odd and difficult to read)
is current practice and not the former.  FWIW, I would suggest that we
switch to Robert's suggestion.

-- Gaby

Re: Ada files now checked in

[Zack Weinberg]

On Sun, Oct 07, 2001 at 08:34:26AM -0400, dewar@gnat.com wrote:
> >>I'm surprised to read that English grammar includes typography. ;-)
> 
> it most certainly includes punctuation, and that is what we are talking
> about here! A quotation (which is what this is) appears in quotation
> marks (which look roughly like "").
> 
> The character ` is indeed a grave accent in Latin-1, and of course English
> doesn't have accents at all, further clarifying my point (I used the
> phrase reverse quote, since I thought it would be more familiar to
> english readers, and furthermore, that's what is going on here, we
> are misusing a grave accent as an opening quotation mark. Indeed it
> is a bit odd if we insist on this misuse, that we do not also use
> Acute (Latin-1 code 180) as the closing quote, at least that would
> be just slightly less odd to the eye.

The issue here is that there are (historically) two competing
standards for the meaning and therefore the appropriate glyph for
ASCII codes 27 and 60 (hexadecimal).  One is Latin-1: 27 is APOSTROPHE
and 60 is GRAVE ACCENT.  The other standard was never officially
promulgated but it is deeply embedded in the assumptions of programs
such as M4, TeX, and GNU Info.  I suspect its origin is the way the
original VT100 terminal displayed the characters.  Anyway, in that
standard 27 is RIGHT SINGLE QUOTATION MARK and 60 is LEFT SINGLE
QUOTATION MARK.  The error messages issued by cc1 are obeying the
second standard.

Unicode matches Latin-1 and there seems to be a trend toward that
choice in font design, for instance XFree86 4.1's fonts use the first
standard (previous versions use the second).  I haven't seen any
believable transition plan for programs like M4 and TeX, though.

It is probably best if GCC avoids the issue by using exclusively ASCII
22 (QUOTATION MARK) in error messages.  If I understand you, this is
what Ada does now.  Unlike some people, I do not expect Unicode to be
universally accepted anytime soon.  (But of course we can use U+201C
and U+201D (LEFT and RIGHT DOUBLE QUOTATION MARK) or U+2018 and U+2019
(LEFT and RIGHT SINGLE QUOTATION MARK) in translations targeted at
Unicode locales.)

Search-and-replace patches to change all the existing error messages
should be welcome.

zw

Re: Ada files now checked in

[dewar]

<<By appearing to support it, we are leading people to believe that it
will work, but the period of time for which that statement is true is
likely to be very small (and may, in fact, be zero: has anybody
actually *tried* to bootstrap starting from that distribution?).
>>

Someone reported that they could indeed bootstrap from the Debian version,
and that is not at all surprising for the current sources, which are in
fact speced to be compilable with a version 3.13 gnat.

But indeed it is not the case that this will be true for ever, or even for
very long (I already gave two cases of kludges in the source that are just
waiting to be removed -- indeed in our normal procedures we would have
stepped up to 3.14 for the prior version, but kept 3.13 as a base precisely
to ease transitions for GCC 3).

One thing that concerns me is that if people decide that it is useful to
be able to bootstrap with the current Debian package, then it is only a
small step to decide that it definitely should work, and then it is only
a small step to decide that if in the future it does not work, that is a
bug which needs fixing, and suddenly we have an influence that makes it
hard to clean up these bootstrap issues, and in some cases, harder to
improve the technology. That would be unfortunate (and would of course
also lead to greater divergence between the FSF and ACT versions -- right
now, it is our intention to try to keep the FSF and ACT versions in very
close sync, since this makes it more practical to ensure that our changes
and development can be reflected in the FSF tree, we have even discussed
whether we could use the FSF tree directly for ACT development in the
future).

Just to state our current philosophy, it is that the current version of
GNAT requires the most recent *official* release to compile (that's a bit
different from Richard's more general statement of a recent version).

What we would like to guarantee at any particular point is that the FSF
GNAT snapshots are compilable starting either with the most recent FSF
release, or with starter binaries maintained at the ACT libre site. For
now we don't have anything like an official FSF release although we will
also try to ensure that the most recent snapshot can compile itself (this
is a normal bootstrap requirement after all). That means that the starter
binaries are the only *guaranteed* starting point. By the way I have asked
that the starter binaries be made available in any case at the libre site
early this coming week. We will post an announcement here.

Re: Ada files now checked in

[dewar]

<<True, but in this simple case, I see no reason why the compiler
could not construct a valid proof that the variable is indeed used
uninitialized in all cases.
>>

Yes, of course there are simple cases in which this is true.

Re: Ada files now checked in

[Richard Kenner]

    <<No, it's not that simple.  There is no reason to believe that any
    subsequent distributions will have the nonstandard name.  But there
    *is* a strong reason to believe that GNAT, even if it can be
    bootstrapped with that version now, will be able to in the future, and
    not too long into the future.  See Robert's comments about the reasons
    for this.  >>

    I think Richard has a not missing somewhere in the above paragraph.

I don't think so, but let me try again:

Due to issues like the ones you've raised, a GNAT version used to
bootstrap GNAT can't be too much older than the sources they are
bootstrapping.  That particularly version is unchanging and, at some point
in the not-too-distant future, will not be able to bootstrap the CVS GNAT
sources even if it can now.

By appearing to support it, we are leading people to believe that it
will work, but the period of time for which that statement is true is
likely to be very small (and may, in fact, be zero: has anybody
actually *tried* to bootstrap starting from that distribution?).

Re: Ada files now checked in

[dewar]

<<No, it's not that simple.  There is no reason to believe that any
subsequent distributions will have the nonstandard name.  But there
*is* a strong reason to believe that GNAT, even if it can be
bootstrapped with that version now, will be able to in the future, and
not too long into the future.  See Robert's comments about the reasons
for this.
>>

I think Richard has a not missing somewhere in the above paragraph.

Re: Ada files now checked in

[Richard Kenner]

    As I've said, if the existing packaged GNATs don't work, that is fine
    by me.  What I object to is refusing to even let them try because they
    happen not to have the official name.

No, it's not that simple.  There is no reason to believe that any
subsequent distributions will have the nonstandard name.  But there
*is* a strong reason to believe that GNAT, even if it can be
bootstrapped with that version now, will be able to in the future, and
not too long into the future.  See Robert's comments about the reasons
for this.

There's no point in making major Makefile and configure changes to support
one specific version that we *know* won't work in the fairly near future.

Re: Ada files now checked in

[dewar]

<<Yes, you've made that clear, but the point is that that distribution
is *not* intended to bootstrap GNAT.  Nobody knows whether it will or
not.  The intent is to start from known-good gnat1 and gnatbind
binaries, which are intended for that purpose.
>>

Not clear that we are moving to agreement here. Seems to me that if the
makefile patches to allow peculiar driver names are not too difficult
why not. I still think that certainly we will recommend using the starter
binaries, or a current build.

Re: Ada files now checked in

[dewar]

<<I notice it says "_is_ used uninitialized".  Does that mean you've
eliminated the old false positive problems?
>>

You can't eliminate false positives, without also correct messages (if
you think you can, I have a Turing machine with a tape here to send
off to you ..... :-)

Re: Ada files now checked in

[Florian Weimer]

dewar@gnat.com writes:

> <<I notice it says "_is_ used uninitialized".  Does that mean you've
> eliminated the old false positive problems?
> >>
>
> You can't eliminate false positives, without also correct messages (if
> you think you can, I have a Turing machine with a tape here to send
> off to you ..... :-)

True, but in this simple case, I see no reason why the compiler
could not construct a valid proof that the variable is indeed used
uninitialized in all cases.

Re: Ada files now checked in

[dewar]

<<This will always point to the line with a use of an uninitialized
variable:
>>

Big improvement, that's really nice

A little nitpick, the reverse quote at the start of insertions looks
really horrible in most environments, and has no typographic justification.
I know this is nothing to do with this particular message, but it is 
something that always strikes me as wrong (I know we had this discussion
wrt the documentation, but the same consideration applies for error
messages, perhaps even more strongly, since there it is harder to apply
some filter to get rid of the junk character. The use of apostrophes is
odd anyway (as opposed to using quotation markes, which is what normal
english grammar would suggest).

Re: Ada files now checked in

[Florian Weimer]

dewar@gnat.com writes:

> A little nitpick, the reverse quote at the start of insertions looks
> really horrible in most environments, and has no typographic justification.

It is not a reverse quote, it is a GRAVE ACCENT in all standards I've
seen so far.  See http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html for
additional information, including glyph samples.

> The use of apostrophes is odd anyway (as opposed to using quotation
> markes, which is what normal english grammar would suggest).

I'm surprised to read that English grammar includes typography. ;-)

Re: Ada files now checked in

[Richard Kenner]

    It is ridiculous to speak of a situation as "transitory" when its
    duration is measured in years.

No, it's measured in *hours*.  Once the first bootstrap using the supplied
gnat1 and gnatbind is complete, you have a working and standard GNAT that
can be used for subsequent bootstraps.

But I've said this before and there seems no point in going around and
around with this.  You've stated your position numerous times, as have I,
and we disagree.

Re: Ada files now checked in

[Richard Henderson]

On Sun, Oct 07, 2001 at 07:52:57AM -0400, Richard Kenner wrote:
> No, it's measured in *hours*.  Once the first bootstrap using the supplied
> gnat1 and gnatbind is complete, you have a working and standard GNAT that
> can be used for subsequent bootstraps.

No, it is not.  Disregarding Zack's argument, it is hours for me.

Then another few hours for Tom, Dick, Harry, and everyone else who
wants to bootstrap from the binaries currently provided by various
distributions, all the way up until the moment distributions provide
binaries based on the released gcc 3.1.



r~

Re: Ada files now checked in

[Richard Kenner]

    My argument - and I think Joseph is saying the same thing - is that we
    should support what is done *now*.  

Yes, you've made that clear, but the point is that that distribution
is *not* intended to bootstrap GNAT.  Nobody knows whether it will or
not.  The intent is to start from known-good gnat1 and gnatbind
binaries, which are intended for that purpose.

Re: Ada files now checked in

[dewar]

<<I find it a bit hard to believe that mere packaging errors regularly
introduces subtle code generation problems, so that you must not trust
a compiler which has not been built with a binary supplied supplied by
ACT.  (More severe problems would already have been noted.)
>>

no one is saying you "must not trust" anything. Just that it seems cleaner
to start with something that you *know* will work.

Re: Ada files now checked in

[dewar]

<<$ gcc -Wuninitialized -ftree-ssa foo.c -O -c
foo.c: In function `main':
foo.c:3: warning: `b' is used uninitialized in this function
>>

Right, I know about those messages, the trouble is that the message
does not point to the problem point, it points instead to the declaration
of b. What you need in more complex cases is a pointer to the exact
occurrence that is detected as potentially troublesome

Re: Ada files now checked in

[Diego Novillo]

On Sat, 06 Oct 2001, dewar@gnat.com wrote:

> <<$ gcc -Wuninitialized -ftree-ssa foo.c -O -c
> foo.c: In function `main':
> foo.c:3: warning: `b' is used uninitialized in this function
> >>
> 
> Right, I know about those messages, the trouble is that the message
> does not point to the problem point, it points instead to the declaration
> of b. What you need in more complex cases is a pointer to the exact
> occurrence that is detected as potentially troublesome
>
No, this is based on the new tree SSA infrastructure (BTW, I had
cut&pasted the wrong output in my inital message).

This will always point to the line with a use of an uninitialized
variable:

-----------------------------------------------------------------------------
$ cat rdefs.c
main()
{
  int a, b;

  a = b + 4;
  if (a > 0)
    b = b + 3;
}

$ gcc -Wuninitialized -ftree-ssa rdefs.c -O -c
rdefs.c: In function `main':
rdefs.c:5: warning: `b' is used uninitialized in this function
rdefs.c:7: warning: `b' is used uninitialized in this function
-----------------------------------------------------------------------------

As I said, I'm still debugging this work, but the basic
infrastructure is already in the AST branch.


Diego.

Re: Ada files now checked in

[Zack Weinberg]

On Sun, Oct 07, 2001 at 03:34:42AM -0400, Diego Novillo wrote:
> $ gcc -Wuninitialized -ftree-ssa rdefs.c -O -c
> rdefs.c: In function `main':
> rdefs.c:5: warning: `b' is used uninitialized in this function
> rdefs.c:7: warning: `b' is used uninitialized in this function
> -----------------------------------------------------------------------------
> 
> As I said, I'm still debugging this work, but the basic
> infrastructure is already in the AST branch.

Extremely cool.  That will make finding missing initializations much
easier.

Maybe you could change the warning message to "...used uninitialized
here" or "at this point" or something like that?  Just to be clear
it's not the same old "somewhere in the function" message.

I notice it says "_is_ used uninitialized".  Does that mean you've
eliminated the old false positive problems?

How expensive is it to calculate these?  It'd be nice if we could
generate the warnings with optimization off; that's always been a wart.

zw

Re: Ada files now checked in

[Diego Novillo]

On Sun, 07 Oct 2001, Zack Weinberg wrote:
> Maybe you could change the warning message to "...used uninitialized
> here" or "at this point" or something like that?  Just to be clear
> it's not the same old "somewhere in the function" message.
> 
Sure.


> I notice it says "_is_ used uninitialized".  Does that mean you've
> eliminated the old false positive problems?
> 
That's the intent.  The new code still spews out false positives,
that's what I'm now working on.

The analysis depends on the computation of reaching definitions.
Prior to computing the SSA form, we insert ghost definitions for
every symbol in the entry basic block.  After reaching
definitions, we traverse all the variable use references in the
function.  For every use:

- if its only reaching definition is the ghost def, the variable
  *is* used uninitialized.

- if one of its reaching definitions is the ghost def, the
  variable *may be* used uninitialized.

That's a very simplified view that will give you lots of false
positives (variables with its address taken, global variables,
etc).  I'm refining the criteria with each bootstrap.

Also, I'm about to add def-def chains to model non-killing
definitions like:

1: int a, b *p;
2: 
3: a = 4;
4: *p = 3;
5: b = a + 1;

The use of a at line 5 may be reached by the definitions of *p
and a at lines 4 and 3, respectively.  But this part is nowhere
near ready.


> How expensive is it to calculate these?> 
The analysis itself is relatively cheap once you have computed
the SSA form and reaching definitions of the function. It's
roughly O(SxR) where S is the number of symbols and R the number
of symbol references in the function.

Computing the SSA form is not cheap, but can be improved.
Essentially you need to:

- Build the flowgraph.  That's roughly linear in the number of
  statement tree nodes.

- Find all the variable references in the function.  Linear in
  the total number of tree nodes.

- Compute the SSA form.  This involves computing immediate
  dominators and dominance frontiers.  I believe the algorithms
  we have in GCC are quite quick, but I haven't really looked.

  Building the FUD chains is like O(SxNxE) (could be wrong, I'm
  quoting from memory).  There is a linear phi placing algorithm
  which I plan to switch to.

I want to hook-up all the tree SSA passes to -ftime-report.  That
will give us a better idea of how expensive this really is.

> It'd be nice if we could generate the warnings with
> optimization off; that's always been a wart.
>
Definitiely possible.  We only need to make -Wuninitialized
trigger -ftree-ssa.


Diego.

Re: Ada files now checked in

[Daniel Berlin]

....
>   Building the FUD chains is like O(SxNxE) (could be wrong, I'm
>   quoting from memory).  There is a linear phi placing algorithm
>   which I plan to switch to.

You meen Sreedhar and gao's?
If so, i've got it coded already for the tree ssa stuff.
....

> Diego.

Re: Ada files now checked in

[Diego Novillo]

On Sun, 07 Oct 2001, Daniel Berlin wrote:

> ....
> >   Building the FUD chains is like O(SxNxE) (could be wrong, I'm
> >   quoting from memory).  There is a linear phi placing algorithm
> >   which I plan to switch to.
> 
> You meen Sreedhar and gao's?
>
Yes.  These two:

@InProceedings{	  bib:johnson.ea-94,
  title		= "The Program Structure Tree: Computing Control Regions in
		  Linear Time",
  author	= "R. Johnson and D. Pearson and K. Pingali",
  booktitle	= pldi94,
  address	= "Orlando, Florida",
  month		= jun,
  year		= "1994",
  pages		= "171--185"
}

@InProceedings{	  bib:sreedhar.ea-95,
  author	= "V. C. Sreedhar and G. R. Gao",
  title		= "A Linear Time Algorithm for Placing ${\phi}$-nodes",
  pages		= "62--73",
  isbn		= "0-89791-692-1",
  booktitle	= popl95,
  month		= jan,
  publisher	= "ACM Press",
  address	= "New York, NY, USA",
  year		= "1995"
}

> If so, i've got it coded already for the tree ssa stuff.
>
Cool.  Mind submitting the patch?

Thanks.  Diego.

Re: Ada files now checked in

[Daniel Berlin]

On Sunday, October 7, 2001, at 02:26  PM, Diego Novillo wrote:

> On Sun, 07 Oct 2001, Daniel Berlin wrote:
>
>> ....
>>>   Building the FUD chains is like O(SxNxE) (could be wrong, I'm
>>>   quoting from memory).  There is a linear phi placing algorithm
>>>   which I plan to switch to.
>>
>> You meen Sreedhar and gao's?
>>
> Yes.  These two:
>
> @InProceedings{	  bib:johnson.ea-94,
>   title		= "The Program Structure Tree: Computing Control Regions in
> 		  Linear Time",
>   author	= "R. Johnson and D. Pearson and K. Pingali",
>   booktitle	= pldi94,
>   address	= "Orlando, Florida",
>   month		= jun,
>   year		= "1994",
>   pages		= "171--185"
> }
>
> @InProceedings{	  bib:sreedhar.ea-95,
>   author	= "V. C. Sreedhar and G. R. Gao",
>   title		= "A Linear Time Algorithm for Placing ${\phi}$-nodes",
>   pages		= "62--73",
>   isbn		= "0-89791-692-1",
>   booktitle	= popl95,
>   month		= jan,
>   publisher	= "ACM Press",
>   address	= "New York, NY, USA",
>   year		= "1995"
> }
>
>> If so, i've got it coded already for the tree ssa stuff.
>>
> Cool.  Mind submitting the patch?
>
It's not a single patch (functionally, anyway), but i'll submit it 
sometime soon.
I construct an explicit dominator tree (from the idoms), then augment it 
with the DJ graph info.
This is because APT ("APT: a data structure for optimal control 
dependence computation", 
http://www.acm.org/pubs/citations/proceedings/pldi/207110/p32-pingali/ ) 
uses a dominator tree augmented with info as well, so it didn't make 
sense to just make a dj-graph specific version.
It's of course, largely non-tree-ssa specific, however, i used it in 
doing loop optimizations for tree-ssa.

> Thanks.  Diego.

Re: Ada files now checked in

[Joern Rennecke]

> - if its only reaching definition is the ghost def, the variable
>   *is* used uninitialized.

Not generally true.  The uninitialized use might never be executed.
Back to the halting problem...

Re: Ada files now checked in

[Richard Kenner]

    Clearly CVS GCC ought to support bootstrapping via the packaged GNAT on
    the FSF-preferred version of GNU/Linux.

Sure it will, but that has doesn't mean we have to immortalize one
particular choice made before GNT was integrated into GCC.

Re: Ada files now checked in

[Richard Kenner]

    The problem is that they shouldn't be in CVS and shouldn't be
    generated into the source directory, because this causes tons of
    other problems.

Such as?  We've been doing this for c-parse.y for over a decade.

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 09:13:09PM -0400, Richard Kenner wrote:
>     The problem is that they shouldn't be in CVS and shouldn't be
>     generated into the source directory, because this causes tons of
>     other problems.
> 
> Such as?  We've been doing this for c-parse.y for over a decade.

And we stopped doing it because it was a continual source of version
skew and other such problems.  Please consult the mailing list
archives.

zw

Re: Ada files now checked in

[Richard Kenner]

    No.  I have either to do the manual procedure *every time I build the
    compiler*, or I am not testing with the vendor-provided packages
    anymore, and that is the whole point.

Why is that the "whole point"?  I often do "make install" and from then on
use that compiler (both C and Ada) for my compilations.

As Robert says, there is no assurance that any vendor-supplied GNAT can
be used to bootstrap GNAT 5.0.  Perhaps the SGI-version can, but I'm not
sure and don't particularly care.  That's what the gnat1 and gnatbind
binaries will be for.

Re: Ada files now checked in

[Richard Kenner]

    3. You have a complete gnat provided by your system integrator.

But there are few such.  The major one is SGI, and they call the
driver "gcc".

Re: Ada files now checked in

[Richard Kenner]

    I'd like to see how you propose to make the extra effort disappear
    otherwise.  I've been quite clear where it comes from.

Once you do it the first time, every other build is straightforward.

    "ACT never does that" is not the same as "wrong."

"Wrong" or "right" isn't a meaningful term here.  The point is that neither
FSF nor ACT has ever viewed this as a configuration that needs to be
supported.

    This "short period" you refer to stretches from now until GCC >=3.1
    (including Ada) is the default system compiler on every relevant
    platform. 

No, not at all.  Just until the *first time* gnat is build from a
gnat1 and gnatbind.  Then you can just use what you built.  You don't have
to wait for a release.

Re: Ada files now checked in

[Richard Kenner]

    I'm now wondering how much additional trouble it would be to require
    the presence of the basic Ada runtime library as well as a bootstrap
    compiler.  That would not only make it easy to generate these tools,

Why bother?  If the ouput of these tools is in CVS (and they will be),
then you don't need them to bootstrap and once you do, you can easily
build the tools.  I don't understand the reason for this extra effort.

    it would permit us to separate the construction of the compiler from
    the construction of the runtime.  

Actually, it will make it *harder*, but that's a long story ...

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 08:57:50PM -0400, Richard Kenner wrote:
>     I'm now wondering how much additional trouble it would be to require
>     the presence of the basic Ada runtime library as well as a bootstrap
>     compiler.  That would not only make it easy to generate these tools,
> 
> Why bother?  If the ouput of these tools is in CVS (and they will
> be),

They shouldn't be.

Please review the history of problems we've had with Yacc-generated
parser files, and reconsider.

zw

Re: Ada files now checked in

[dewar]

<<Yes, this is already implemented in the ast-optimizer-branch.
The compiler computes reaching definitions for local variables
and emits a warning for every variable that might be used
uninitialized (tree-ssa.c:analyze_rdefs).
>>

And just to be clear, flags the occurrence that is troublesome?

Re: Ada files now checked in

[Diego Novillo]

On Sat, 06 Oct 2001, dewar@gnat.com wrote:

> <<Yes, this is already implemented in the ast-optimizer-branch.
> The compiler computes reaching definitions for local variables
> and emits a warning for every variable that might be used
> uninitialized (tree-ssa.c:analyze_rdefs).
> >>
> 
> And just to be clear, flags the occurrence that is troublesome?

It displays this message:

-----------------------------------------------------------------------------
$ cat foo.c
main()
{
  int a, b;

  a = b + 4;
}

$ gcc -Wuninitialized -ftree-ssa foo.c -O -c
foo.c: In function `main':
foo.c:3: warning: `b' is used uninitialized in this function
-----------------------------------------------------------------------------

Re: Ada files now checked in

[Florian Weimer]

Diego Novillo <dnovillo@redhat.com> writes:

>> And just to be clear, flags the occurrence that is troublesome?
>
> It displays this message:
>
> -----------------------------------------------------------------------------
> $ cat foo.c
> main()
> {
>   int a, b;
>
>   a = b + 4;
> }
>
> $ gcc -Wuninitialized -ftree-ssa foo.c -O -c
> foo.c: In function `main':
> foo.c:3: warning: `b' is used uninitialized in this function
> -----------------------------------------------------------------------------

Well, Robert probably wants to see something like this:

foo.c: In function `main':
foo.c:5:7: warning: `b' is used uninitialized at this point

Looking at the warning message and its different modality to the
standard one, I think the branch currently tackles the problem of
false positives, not the problem of friendly reporting.

Re: Ada files now checked in

[Diego Novillo]

On Sat, 06 Oct 2001, Florian Weimer wrote:

> Well, Robert probably wants to see something like this:
> 
> foo.c: In function `main':
> foo.c:5:7: warning: `b' is used uninitialized at this point
> 
> Looking at the warning message and its different modality to the
> standard one, I think the branch currently tackles the problem of
> false positives, not the problem of friendly reporting.
>
Ah, I see.  Yes, the warning message uses the line number
information stored in the statement containing the offending
expression.  I don't know if absolute line and column numbers are
stored in the trees.

Diego.

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 05:12:45PM -0400, Diego Novillo wrote:
> On Sat, 06 Oct 2001, Florian Weimer wrote:
> 
> > Well, Robert probably wants to see something like this:
> > 
> > foo.c: In function `main':
> > foo.c:5:7: warning: `b' is used uninitialized at this point
> > 
> > Looking at the warning message and its different modality to the
> > standard one, I think the branch currently tackles the problem of
> > false positives, not the problem of friendly reporting.
> >
> Ah, I see.  Yes, the warning message uses the line number
> information stored in the statement containing the offending
> expression.  I don't know if absolute line and column numbers are
> stored in the trees.

I don't know if they are now, but there isn't any deep reason why they
couldn't be.  For C and C++, we have column number information coming
back from the preprocessor now, and I understand that the new C++
parser is going to use that information for its own error reporting.
It shouldn't be that much harder to annotate variable uses with their
source position at the tree level.  It is probably too much to hope
for to get that into RTL.

I would also like to see this level of detail in uninitialized
variable warnings.

zw

Re: Ada files now checked in

[dewar]

<<It does mean you would be shipping a big binary file (or two) and the
source to the bytecode engine. I really don't know if the costs
would outweigh the benefits, but I thought a discussion might help
point to a workable solution.
>>

I see the benefits as fairly minor, since I think we won't have that much
trouble resolving the discussion about how to set things up in a convenient
manner (lots of people have been building GNAT from sources for lots of
different operating systems for a long time). On the other hand, the costs
of this are huge. Yes, JGNAT sort of opens up a path, but getting this path
to fully work would be a lot of work (on the order of person years).

Re: Ada files now checked in

[dewar]

The separate Ada for GNU/Linux team is a group of people who do some
work on the GNU/Linux version independently of ACT. Actually they
do not seem very active at the moment. Historically, they were the
first to generate RPM's, and did so before ACT did. The reason was
that at that point we at ACT did not know how to generate RPM's that
would work reliably. Neither did they, but they thought it was more
important to have an RPM than to have something that worked reliably
(that's not *so* unreasonable, since for a lot of simple student
use, the RPM's worked well enough). Now those problems have been
resolved in any case.

I agree that if Debian continues to distribute in the form with separate
driver names, then we need to accomodate that, but I would argue that
this is not a good idea for several reasons

1. gcc is by design intended to support multiple compilers, and it is
convenient to have a single driver that does just this.

2. the documentation all assumes that the name of the compiler is gcc

3. historically one of the reasons to do this was that gnat was not
fully part of gcc, and in particular, that it used an older version
of gcc as the base. This reason is in the process of disappearing.

So let's not assume that this decision is necessarily one that will
continue into the future. It's at least an item for discussion.

As to whether it is possible to bootstrap the checked in GNAT sources
using the currently packaged Debian version of GNAT, I don't know if
anyone has ever tried that, we certainly have not.

Re: Ada files now checked in

[Florian Weimer]

dewar@gnat.com writes:

> As to whether it is possible to bootstrap the checked in GNAT sources
> using the currently packaged Debian version of GNAT, I don't know if
> anyone has ever tried that, we certainly have not.

I'm running Debian, and I've managed to built the current CVS version
on x86 (modulo the problems reported by Laurent Guerby).

In the past, I got the impression that the problems of the non-ACT
GNAT versions (and even the ACT GNAT version when compiled with the
default threading implementation, BTW) were in areas such as exception
traceback, tasking, and debugging support (especially together with
tasking).  The GNAT frontend does not need these facilities, of
course.

I find it a bit hard to believe that mere packaging errors regularly
introduces subtle code generation problems, so that you must not trust
a compiler which has not been built with a binary supplied supplied by
ACT.  (More severe problems would already have been noted.)

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 03:56:24PM -0400, dewar@gnat.com wrote:
> 
> I agree that if Debian continues to distribute in the form with separate
> driver names, then we need to accomodate that, but I would argue that
> this is not a good idea for several reasons
[etc]

My argument - and I think Joseph is saying the same thing - is that we
should support what is done *now*.  Never mind what Debian or anyone
else might do in the future.  Never mind whether or not a configuration
is exactly the same as the one ACT has historically supported.

I make this argument because I do not expect the status quo to change
before the end of 2002, and more likely, not before the middle of
2003.  It is ridiculous to speak of a transition period measured in
years as "short."

> As to whether it is possible to bootstrap the checked in GNAT sources
> using the currently packaged Debian version of GNAT, I don't know if
> anyone has ever tried that, we certainly have not.

I was hoping to be able to present results using my patches, but as
there are still no einfo.h and sinfo.h available, I haven't been able
to complete testing.

zw

Re: Ada files now checked in

[dewar]

<<Would it be possible to supply a 'java' (or some other engine) version
of the ADA compiler that could be used to bootstrap it?  You would then
only need to supply a pre-compiled ADA-to-bytecode compiler (in
bytecode)
to be able to bootstrap the ADA compiler.
>>

First, a little lesson for everyone :-)
Ada is not an acronym, but a woman's name (Ada Augusta Byron, daughter of the
poet, given credit by some as the first programmer, since she worked on
developing algorithms for Babbage). So Ada folks feel almost as strongly
about using Ada rather than ADA as some folks feel about using GNU/Linux
instead of L????

To answer the question, yes, everything is possible, but that's a huge
project. Once upon a time we actually thought about what it would take
to build GNAT without GNAT installed, but since it has never really been
a significant practical problem (and since these days there are systems
which don't come with C anyway), we have never bothered.

After all, you could also rewrite the whole of GNAT in C :-)

Re: Ada files now checked in

[dewar]

<<Meanwhile, I have to wonder why running GNU Ada on a popular version
of the GNU system needs the attention of a group outside the core
developers of GNU Ada.  Supporting GNU/Linu ought to be one of the
main priorities of the core group.
>>

Sorry, I am confused here, most certainly ACT has always supported GNU/Linux
with a standard installation in which the driver name is indeed gcc. I am
really not sure what the point is here.

Re: Ada files now checked in

[Joseph S. Myers]

On Sat, 6 Oct 2001 dewar@gnat.com wrote:

> <<Meanwhile, I have to wonder why running GNU Ada on a popular version
> of the GNU system needs the attention of a group outside the core
> developers of GNU Ada.  Supporting GNU/Linu ought to be one of the
> main priorities of the core group.
> >>
> 
> Sorry, I am confused here, most certainly ACT has always supported GNU/Linux
> with a standard installation in which the driver name is indeed gcc. I am
> really not sure what the point is here.

RMS's reference was to the message
<URL: http://gcc.gnu.org/ml/gcc/2000-11/msg00170.html > and the existence of
a separate Ada for GNU/Linux Team.  My point in quoting these messages is
that GNU Ada (not ACT internal development, but the version in the GCC CVS
repository) should work well with the current versions of the FSF's
preferred GNU/Linux distribution - including bootstrapping on it out of
the box, and supporting this should be a primary concern of the GNU Ada
maintainers.  That a particular configuration is used on the preferred GNU
system variant should be sufficient reason to support it for bootstrapping
rather than dismissing it as nonstandard.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[dewar]

<<Let's see if we can't get the in-Ada versions built safely during the
bootstrap, first.  If not, I'm willing to contribute C versions, time
permitting.
>>

Sounds like a plan, thanks for all your energy and help in getting things
going here. Hopefully we will get through these growing pains soon with the
help of you and others, and get things smoothly fit in.

Re: Ada files now checked in

[dewar]

<<if after this some bug is found in a past packaged release that prevents
bootstrap, you can contribute a test for the relevant bug (*not* a version
>>

Note that this need not always be a bug, there are two other cases:

  a) a new version of GNAT uses a feature that has not always been
     supported in previous releases. Obviously one does not do this
     casually, but if code can be improved substantially by such usage
     as has happened in the past (e.g. the addition of Inline_ALways)
     then you want to be able to take advantage of the improvement
     in some cases.

  b) sometimes bugs cannot be fixed cleanly because of bootstrap path
     problems, and we have to fix them in two stages, a kludge to get
     things working for now, and a clean fix in a later version once
     the version with the kludge is sufficiently official/distributed
     to base the bootstrap on. An example is the Style_Checks pragmas
     that are in the current sources. They have an awkward form, just
     because of such a consideration. Another example is from s-stalib:

   Inside_Elab_Final_Code : Integer := 0;
   pragma Export (C, Inside_Elab_Final_Code, "__gnat_inside_elab_final_code");
   --  ???This variable is obsolete starting from 29/08 but cannot be removed
   --  ???right away due to the bootstrap problems

     (these are both examples from the current sources where we are at the
     kludge stage, but not past it yet)

The reason I separate these is that indeed you can produce a test for 
class a) problems, but not always for class b) problems.

Re: Ada files now checked in

[mike stump]

> To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> Cc: zack@codesourcery.com, gcc@gcc.gnu.org
> From: Florian Weimer <fw@deneb.enyo.de>
> Date: Sat, 06 Oct 2001 13:38:37 +0200

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

> Doesn't CVS reset the file modification time to the time the file
> was committed to the repository?

Not my version.  If any do, it wouldn't matter, as update_gcc always
fixes the problem?!

Re: Ada files now checked in

[dewar]

<<That is the situation that the vast majority of users of the FSF CVS
tree will find themselves in.  It is the one that we *must* ensure
works, at least for all popular free operating system distributions.
>>

We cannot necessarily ensure this works, because we don't know what 
system integrators will provide. If they provide non-working versions
of GNAT (e.g. the RPM's that were distributed for 3.13), then it may or
may not be possible to bootstrap using them, and if it is not possible,
then it may not be practical to correct this.

Most certainly in the long run, you cannot expect that a given version
of the GNAT sources can be built by an arbitrarily older version of GNAT
supplied by your "system integrator". 

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 01:07:45PM -0400, dewar@gnat.com wrote:
> <<That is the situation that the vast majority of users of the FSF CVS
> tree will find themselves in.  It is the one that we *must* ensure
> works, at least for all popular free operating system distributions.
> >>
> 
> We cannot necessarily ensure this works, because we don't know what 
> system integrators will provide. If they provide non-working versions
> of GNAT (e.g. the RPM's that were distributed for 3.13), then it may or
> may not be possible to bootstrap using them, and if it is not possible,
> then it may not be practical to correct this.
> 
> Most certainly in the long run, you cannot expect that a given version
> of the GNAT sources can be built by an arbitrarily older version of GNAT
> supplied by your "system integrator". 

You expressed this concern several times.  I should clarify what I
mean by "works".

"You need a newer version of GNAT, go here (URL)" is an acceptable
answer to a bootstrap problem caused by a bug in a vendor's supplied
version of GNAT.

"You need a version of GNAT packaged just so, go here (URL)" is not an
acceptable answer to a bootstrap problem caused by the Makefile not
being clever enough to find the appropriate compiler driver.

In other words, we obviously do not expect the bootstrap to work in
the presence of arbitrarily bad bugs in the bootstrap compiler.  We
*do* need to make our best effort to locate and use what the system
provides.

Also, the whole point of the bootstrap sequence is to insulate us from
bugs in the bootstrap compiler.  I am not familiar with the history of
GNAT, but I would hope that the same techniques used in the back end
would make it possible to build with buggy previous versions of GNAT.
That is, starting with no optimization, avoiding features known to be
buggy, etc.

zw

Re: Ada files now checked in

[dewar]

<<The system integrators who shipped separate drivers for Ada and
everything else have good reason to do it that way - see Daniel
Jacobowitz' comments downthread, for instance.  The FSF tree needs to
support a wider range of initial system configurations than your
private tree does.
>>

Sure, but the issue is that we know some of these separately packaged
versions have serious problems, not serious enough to deter casual use
on simple programs, but serious enough to cause failures in our test
suite, and we simply don't know if it is possible to bootstrap with
these versions or not.

Re: Ada files now checked in

[dewar]

<<It's my contention that the FSF tree needs to support a broader range
of situations than the ACT internal tree does.  And I don't agree with
Richard that this adds an undue amount of complexity to the makefiles.
>>

Note that already we are agreeing that the FSF tree needs to support
a broader range, since of course ACT internally always builds from an
existing full installation of GNAT. The question is how much broader.

For example, we did take some care to try to ensure that the current
sources can be built with 3.13, rather than the previous version which
is 3.14, But I would expect an attempt to build with 3.12 or earlier
to fail, and I would not be surprised to find that some non-standard
distribution of 3.13 would also fail.

Re: Ada files now checked in

[Joseph S. Myers]

On Sat, 6 Oct 2001 dewar@gnat.com wrote:

> For example, we did take some care to try to ensure that the current
> sources can be built with 3.13, rather than the previous version which
> is 3.14, But I would expect an attempt to build with 3.12 or earlier
> to fail, and I would not be surprised to find that some non-standard
> distribution of 3.13 would also fail.

So, the configure script needs to check for the necessary features of the
bootstrap GNAT and for the bugs that prevent bootstrap.  I think Zack's
patch to find a bootstrap compiler that supports Ada is a good first step;
if after this some bug is found in a past packaged release that prevents
bootstrap, you can contribute a test for the relevant bug (*not* a version
test, since the Autoconf philosophy is to test for features rather than
versions) rather than claiming that some packaged versions (unspecified)
might have bugs (unspecified) that cause bootstrap to fail for some
(unspecified) reason.  You can also document the specific packaged
versions with problems in gcc/doc/install.texi under the entries for the
systems those problematic versions target.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[dewar]

<<It's my contention that the FSF tree needs to support a broader range
of situations than the ACT internal tree does.  And I don't agree with
Richard that this adds an undue amount of complexity to the makefiles.
>>

I am unconvinced, for example, we (we = ACT) don't know if the Debian
distribution or other packaged distributions of GNAT can in fact be
used to bootstrap. Maybe they can, but quite likely the answer might
be they can't for who knows what reason. It seems much cleaner to
suggest to people that they use starter binaries that are known to
be suitable for the bootstrap.

Re: Ada files now checked in

[dewar]

<<What, you want to keep the Ada tools around as well as the C or Perl
ones?  That would be silly.  We only need one version.
>>

See previous message, I potentially agree for C, but disagree for Perl, we
don't want to intodruce another language into our build environment at
ACT just for this purpose, especially if it is Perl :-)

<<I'm now wondering how much additional trouble it would be to require
the presence of the basic Ada runtime library as well as a bootstrap
compiler.  That would not only make it easy to generate these tools,
it would permit us to separate the construction of the compiler from
the construction of the runtime.  I think this would make it easier to
maintain both in the long run.  The only real disadvantage is that you
wind up with a compiler binary linked against the previous version of
the runtime, but this is not a huge problem, and one can always relink
the binaries afterward.
>>

I don't see this as simplifying, having two copies of runtime libraries
(a basic one, and not so basic if it has to build these tools), and the
full one, and making sure that compatible libraries are around for the
pre-bootstrap environment seems to complicate things to me. But let's
see what others think.

Re: Ada files now checked in

[Florian Weimer]

dewar@gnat.com writes:

> <<What, you want to keep the Ada tools around as well as the C or Perl
> ones?  That would be silly.  We only need one version.
> >>
>
> See previous message, I potentially agree for C, but disagree for Perl, we
> don't want to intodruce another language into our build environment at
> ACT just for this purpose, especially if it is Perl :-)

I don't see the problem with Ada tools for these particular files.
Only people who actually change the compiler need these tools, and
since they are platform-independent, the generated files can be
shipped together with the source code.

Okay, if you want to change certain parts of GNAT, you have to build
and install GNAT first (provided that you only have got the minimal
set of binaries), but this requirement does not seem too troublesome
to me.

The other build problem (different compiler driver names for C and
Ada) seems to be more problematic.  What about a patch for GCC 2.95.4
so that the gcc drivers includes Ada support by default, so that you
can drop in a gnat1 binary?

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 08:07:20PM +0200, Florian Weimer wrote:
> dewar@gnat.com writes:
> 
> > <<What, you want to keep the Ada tools around as well as the C or Perl
> > ones?  That would be silly.  We only need one version.
> > >>
> >
> > See previous message, I potentially agree for C, but disagree for Perl, we
> > don't want to intodruce another language into our build environment at
> > ACT just for this purpose, especially if it is Perl :-)
> 
> I don't see the problem with Ada tools for these particular files.
> Only people who actually change the compiler need these tools, and
> since they are platform-independent, the generated files can be
> shipped together with the source code.

The problem is that they shouldn't be in CVS and shouldn't be
generated into the source directory, because this causes tons of
other problems.

> The other build problem (different compiler driver names for C and
> Ada) seems to be more problematic.  What about a patch for GCC 2.95.4
> so that the gcc drivers includes Ada support by default, so that you
> can drop in a gnat1 binary?

Won't help.  I have explained this ad nauseam elsewhere.

zw

Re: Ada files now checked in

[Florian Weimer]

Zack Weinberg <zack@codesourcery.com> writes:

>> The other build problem (different compiler driver names for C and
>> Ada) seems to be more problematic.  What about a patch for GCC 2.95.4
>> so that the gcc drivers includes Ada support by default, so that you
>> can drop in a gnat1 binary?
>
> Won't help.  I have explained this ad nauseam elsewhere.

A patch to GCC 2.95.x and GCC 3.0.x could sneak in to the
vendor-provided GCC distributions before GNAT based on GCC 3 becomes
relevant to mainstream, so such a build environment would become more
common over time.  But maybe this doesn't happen fast enough.

Re: Ada files now checked in

[dewar]

<<Yes, I noticed that.  I am fairly confident they could be rewritten
using regular expressions, in say Perl.  Perhaps we could stop there,
if you're okay requiring Perl (this is already the case for people
wishing to generate manpages).  Or, translating a short Perl program
into C is not *that* hard.
>>

Well our policy is not to use perl for anything at all, so this is
definitely not something we would maintain. On the other hand if we
have reasonably documented, reasonably maintain C versions, then we
could just get rid of the Ada versions if this really would help things.
(the reason we prefer not to use perl, is that we have found it very
hard to maintain).

we here = ACT, and the point is that it is cleaner and reduces work
if ACT is using a more similar build approach internally.

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 12:56:03PM -0400, dewar@gnat.com wrote:
> <<Yes, I noticed that.  I am fairly confident they could be rewritten
> using regular expressions, in say Perl.  Perhaps we could stop there,
> if you're okay requiring Perl (this is already the case for people
> wishing to generate manpages).  Or, translating a short Perl program
> into C is not *that* hard.
> >>
> 
> Well our policy is not to use perl for anything at all, so this is
> definitely not something we would maintain.

Fair 'nuff.

>  On the other hand if we
> have reasonably documented, reasonably maintain C versions, then we
> could just get rid of the Ada versions if this really would help things.
> (the reason we prefer not to use perl, is that we have found it very
> hard to maintain).
> 
> we here = ACT, and the point is that it is cleaner and reduces work
> if ACT is using a more similar build approach internally.

Of course.

Let's see if we can't get the in-Ada versions built safely during the
bootstrap, first.  If not, I'm willing to contribute C versions, time
permitting.

zw

Re: Ada files now checked in

[dewar]

<<Only because 2.8.1 is incompatible with glibc 2.2.x.  More
specifically, it has a bunch of bugs that get tripped up by glibc's
aggressively modern header files.
>>

Right, glibc incompatibilities are much more of the problem here than plain
differences in the compilers themselves.

Re: Ada files now checked in

[dewar]

<<Completely agreed, and there is work in progress to improve these
warnings.
>>

Ah, that's *very* interesting, can you tell me more? In particular that
news means I can probably retire the work on trying to do this in the
GNAT front end (we already catch quite a bit there, but do not yet catch
cases involving conditionals).

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 12:39:45PM -0400, dewar@gnat.com wrote:
> <<Completely agreed, and there is work in progress to improve these
> warnings.
> >>
> 
> Ah, that's *very* interesting, can you tell me more? In particular that
> news means I can probably retire the work on trying to do this in the
> GNAT front end (we already catch quite a bit there, but do not yet catch
> cases involving conditionals).

I'm not sure if anyone has actually *proposed* this, but code is being
written to do data flow analysis on whole-function trees; since trees
retain much more information about user variables and source
positions, it would be possible to tag the exact location that the
compiler thought an uninitialized value could reach.

You might want to check out the ast-optimizer-branch.

zw

Re: Ada files now checked in

[Diego Novillo]

On Sat, 06 Oct 2001, Zack Weinberg wrote:

> On Sat, Oct 06, 2001 at 12:39:45PM -0400, dewar@gnat.com wrote:
> > <<Completely agreed, and there is work in progress to improve these
> > warnings.
> > >>
> > 
> > Ah, that's *very* interesting, can you tell me more? In particular that
> > news means I can probably retire the work on trying to do this in the
> > GNAT front end (we already catch quite a bit there, but do not yet catch
> > cases involving conditionals).
> 
> I'm not sure if anyone has actually *proposed* this, but code is being
> written to do data flow analysis on whole-function trees; since trees
> retain much more information about user variables and source
> positions, it would be possible to tag the exact location that the
> compiler thought an uninitialized value could reach.
> 
> You might want to check out the ast-optimizer-branch.
> 
Yes, this is already implemented in the ast-optimizer-branch.
The compiler computes reaching definitions for local variables
and emits a warning for every variable that might be used
uninitialized (tree-ssa.c:analyze_rdefs).

Diego.

Re: Ada files now checked in

[Joseph S. Myers]

On Sat, 6 Oct 2001, Diego Novillo wrote:

> Yes, this is already implemented in the ast-optimizer-branch.
> The compiler computes reaching definitions for local variables
> and emits a warning for every variable that might be used
> uninitialized (tree-ssa.c:analyze_rdefs).

Does this fix some or all of the XFAILing gcc.dg/uninit-*.c testcases?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Diego Novillo]

On Sat, 06 Oct 2001, Joseph S. Myers wrote:

> On Sat, 6 Oct 2001, Diego Novillo wrote:
> 
> > Yes, this is already implemented in the ast-optimizer-branch.
> > The compiler computes reaching definitions for local variables
> > and emits a warning for every variable that might be used
> > uninitialized (tree-ssa.c:analyze_rdefs).
> 
> Does this fix some or all of the XFAILing gcc.dg/uninit-*.c testcases?
> 
Dunno.  I didn't know these existed.  Thanks for pointing it out.

Right now I'm shaking off false positives by bootstrapping with
-Wuninitialized.  Once I'm confident it's more or less stable, I
will add the flag to the regression tests.

First I need to disable the original warning, otherwise we won't
know which of the two are emitting the warning.

Diego.

Re: Ada files now checked in

[dewar]

I must say that to me the simplest thing is that you consider only two
scenarios:

1. You obtain the necessary gnat1 and gnatbind from a special repository
of starter binaries for gnat bootstrapping. These are versions that are
guaranteed to be appropriate starting points.

2. You have a complete gnat that you have built from the sources

It seems to me that trying to use miscelleanous versions of gnat installed
in various ways from various sources, with no guarantee that the version
you are trying to use is suitable for bootstrapping is asking for problems.

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 12:38:47PM -0400, dewar@gnat.com wrote:
> I must say that to me the simplest thing is that you consider only two
> scenarios:
> 
> 1. You obtain the necessary gnat1 and gnatbind from a special repository
> of starter binaries for gnat bootstrapping. These are versions that are
> guaranteed to be appropriate starting points.
> 
> 2. You have a complete gnat that you have built from the sources

See, I'm interested only in

3. You have a complete gnat provided by your system integrator.

That is the situation that the vast majority of users of the FSF CVS
tree will find themselves in.  It is the one that we *must* ensure
works, at least for all popular free operating system distributions.

zw

Re: Ada files now checked in

[Kevin Handy]

dewar@gnat.com wrote:
> 
> I must say that to me the simplest thing is that you consider only two
> scenarios:
> 
> 1. You obtain the necessary gnat1 and gnatbind from a special repository
> of starter binaries for gnat bootstrapping. These are versions that are
> guaranteed to be appropriate starting points.
> 
> 2. You have a complete gnat that you have built from the sources
> 
> It seems to me that trying to use miscelleanous versions of gnat installed
> in various ways from various sources, with no guarantee that the version
> you are trying to use is suitable for bootstrapping is asking for problems.

Would it be possible to supply a 'java' (or some other engine) version
of the ADA compiler that could be used to bootstrap it?  You would then
only need to supply a pre-compiled ADA-to-bytecode compiler (in
bytecode)
to be able to bootstrap the ADA compiler.

1  source -> engine(bytecode-bytecode-compiler) ->
bytecode-native-compiler
2  source -> engine(bytecode-native-compiler) -> native-native-compiler
3? source -> native-native-compiler -> native-native-compiler

Not having looked into the Java Bytecode, how much would it need to
be extended to be usable as a target for the various compilers,
and how hard would it be to write a backend that targeted this engine?
Maybe a emulator for an existing targeted CPU could be used for the
bytecode engine instead.

Is this ADA discussion about bootstraping going to be duplicated when
the pascal front-end is checked in (is it written in pascal)?
If so, a more general approach may be needed to simplify bringing
everything up on a new machine.

Re: Ada files now checked in

[Joseph S. Myers]

On Sat, 6 Oct 2001, Kevin Handy wrote:

> Is this ADA discussion about bootstraping going to be duplicated when
> the pascal front-end is checked in (is it written in pascal)?
> If so, a more general approach may be needed to simplify bringing
> everything up on a new machine.

The Pascal front end is written in C.  The Modula-2 front end is written
in Modula-2 but includes a bootstrap procedure.  The Modula-3 front end is
written in Modula-3, but I don't know that anyone has any hope of
resolving the copyright and licensing issues to get it included in GCC
anyway.  The Mercury front end is written in Mercury (but can generate C
from Mercury; and I think only a few small parts of it were intended to go
in the GCC CVS).  I think the Fortran 95 front end is written in C.  The
COBOL front end web pages indicate an intention for most of that front end
to be written in COBOL.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Kevin Handy]

"Joseph S. Myers" wrote:
> 
> On Sat, 6 Oct 2001, Kevin Handy wrote:
> 
> > Is this ADA discussion about bootstraping going to be duplicated when
> > the pascal front-end is checked in (is it written in pascal)?
> > If so, a more general approach may be needed to simplify bringing
> > everything up on a new machine.
> 
> The Pascal front end is written in C.  The Modula-2 front end is written
> in Modula-2 but includes a bootstrap procedure.  The Modula-3 front end is
> written in Modula-3, but I don't know that anyone has any hope of
> resolving the copyright and licensing issues to get it included in GCC
> anyway.  The Mercury front end is written in Mercury (but can generate C
> from Mercury; and I think only a few small parts of it were intended to go
> in the GCC CVS).  I think the Fortran 95 front end is written in C.  The
> COBOL front end web pages indicate an intention for most of that front end
> to be written in COBOL.

I've noticed a lot of messages about bootstrapping the ADA front end
that talk about needing to use the "correct" version to do the
bootstrap,
which is one reason I proposed some type of bytecode engine. Since you
supply the pre-compiled bytecode version, it should just work. Ignore
whatever version the user has installed (which may be broken, the wrong
version, or not be installed properly), and use one you know will work,
because you put it there and tested it.

It does mean you would be shipping a big binary file (or two) and the 
source to the bytecode engine. I really don't know if the costs
would outweigh the benefits, but I thought a discussion might help
point to a workable solution.

Re: Ada files now checked in

[Toon Moene]

"Joseph S. Myers" wrote:

> I think the Fortran 95 front end is written in C.

Definitely.  The run-time library *might* be written in Fortran, but no
effort has been expended there yet.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Ada files now checked in

[Florian Weimer]

Kevin Handy <kth@srv.net> writes:

> Would it be possible to supply a 'java' (or some other engine) version
> of the ADA compiler that could be used to bootstrap it?

The correct spelling is 'Ada'. ;-)

> You would then only need to supply a pre-compiled ADA-to-bytecode
> compiler (in bytecode) to be able to bootstrap the ADA compiler.

There exists already a version of GNAT which outputs JVM code.
However, this is of little to no help here because you have to link in
the backend C code as well, and I would be surprised if you could do
that without substantial tweaking of the backend.

Re: Ada files now checked in

[dewar]

<<That is what happens.  This entire argument is about the scenario
where there is an Ada compiler but it's not named "gcc".
>>

I understand, this is indeed a scenario which ACT has never been involved
with, our standard distribution always calls the Ada compiler gcc. We are
aware that others have made contrary decisions, and that does indeed make
for some extra confusion.

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 12:36:55PM -0400, dewar@gnat.com wrote:
> <<That is what happens.  This entire argument is about the scenario
> where there is an Ada compiler but it's not named "gcc".
> >>
> 
> I understand, this is indeed a scenario which ACT has never been involved
> with, our standard distribution always calls the Ada compiler gcc. We are
> aware that others have made contrary decisions, and that does indeed make
> for some extra confusion.

It's my contention that the FSF tree needs to support a broader range
of situations than the ACT internal tree does.  And I don't agree with
Richard that this adds an undue amount of complexity to the makefiles.

zw

Re: Ada files now checked in

[Mark Mitchell]

--On Saturday, October 06, 2001 09:48:29 AM -0700 Zack Weinberg 
<zack@codesourcery.com> wrote:

> On Sat, Oct 06, 2001 at 12:36:55PM -0400, dewar@gnat.com wrote:
>> <<That is what happens.  This entire argument is about the scenario
>> where there is an Ada compiler but it's not named "gcc".
>> >>
>>
>> I understand, this is indeed a scenario which ACT has never been involved
>> with, our standard distribution always calls the Ada compiler gcc. We are
>> aware that others have made contrary decisions, and that does indeed make
>> for some extra confusion.
>
> It's my contention that the FSF tree needs to support a broader range
> of situations than the ACT internal tree does.  And I don't agree with
> Richard that this adds an undue amount of complexity to the makefiles.

It doesn't seem problematic to me if you have to download some GNAT
binary from somewhere.  To build GCC on Solaris, you have to download
a C compiler binary from somewhere, or build yourself one using a
cross-compiler.

My two cents,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Ada files now checked in

[Russ Allbery]

dewar <dewar@gnat.com> writes:

> I understand, this is indeed a scenario which ACT has never been
> involved with, our standard distribution always calls the Ada compiler
> gcc. We are aware that others have made contrary decisions, and that
> does indeed make for some extra confusion.

As someone who installs software for a site-wide software tree, I have to
throw in here that I'd never install Ada as "gcc" up until now, when it's
actually been included in the gcc tree.  For one thing, there's a rule
that packages aren't allowed to mess around with the binaries in other
packages, since doing otherwise requires far more work for us.  For
another thing... well, on one hand, one has a C compiler that doesn't
officially support Ada and that's absolutely critical to many classes and
research work, and on the other hand there's an Ada compiler used by very
few people on campus released by a different organization based on a
heavily hacked gcc that attempts to replace parts of gcc.  Um.

Now I'm in a position to realize that you folks actually took a great deal
of care in this area and it really would work.  :)  But most people don't
follow gcc development as closely as I do, and "um" really is likely to be
the most common reaction.

We've always installed the Ada driver under another name, and I expect
that's likely a fairly widespread practice among users of the public
release where Ada isn't critical to their daily life (and therefore
something about which they have an expert on staff).

(This is all moot for Stanford's setup, as the verison of GNAT that we
have installed is far too ancient to bootstrap anything and I'll probably
just not bother updating it now until GCC 3.1 comes out, but I figured I'd
throw out a non-developer viewpoint for what it's worth.)

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: Ada files now checked in

[dewar]

<<I'm afraid the answer is yes.  If you configure a language out with
--enable-languages, its spec strings are not included in the
default_compilers array.  Therefore, even if the front-end magically
appears in $(libsubdir), it won't be able to drive it.

That could of course be changed.
>>

seems like a desirable change to me.

Re: Ada files now checked in

[dewar]

<<Yes, I'd assume so.  But the complexity of having different languages
built from the same source on different platforms can interact badly
with our packaging system.  We'll revisit the issue when 3.1 is closer
to release, though.
>>

OK, that makes sense

Re: Ada files now checked in

[dewar]

<<FWIW, Debian has pretty much decided to do that.  Requiring an Ada
compiler for every bootstrap of the C compiler would introduce a lot of
complexity, especially given the number of our platforms on which Ada
isn't available - Linux/Alpha in particular seems to be problematic.
>>

I thought we had things set up so that if there is no Ada compiler around,
then there is no attempt to build Ada -- that's certainly what we had
discussed doing, so now I am confused.

Re: Ada files now checked in

[Daniel Jacobowitz]

On Sat, Oct 06, 2001 at 12:17:43PM -0400, dewar@gnat.com wrote:
> <<FWIW, Debian has pretty much decided to do that.  Requiring an Ada
> compiler for every bootstrap of the C compiler would introduce a lot of
> complexity, especially given the number of our platforms on which Ada
> isn't available - Linux/Alpha in particular seems to be problematic.
> >>
> 
> I thought we had things set up so that if there is no Ada compiler around,
> then there is no attempt to build Ada -- that's certainly what we had
> discussed doing, so now I am confused.

Yes, I'd assume so.  But the complexity of having different languages
built from the same source on different platforms can interact badly
with our packaging system.  We'll revisit the issue when 3.1 is closer
to release, though.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 12:17:43PM -0400, dewar@gnat.com wrote:
> <<FWIW, Debian has pretty much decided to do that.  Requiring an Ada
> compiler for every bootstrap of the C compiler would introduce a lot of
> complexity, especially given the number of our platforms on which Ada
> isn't available - Linux/Alpha in particular seems to be problematic.
> >>
> 
> I thought we had things set up so that if there is no Ada compiler around,
> then there is no attempt to build Ada -- that's certainly what we had
> discussed doing, so now I am confused.

That is what happens.  This entire argument is about the scenario
where there is an Ada compiler but it's not named "gcc".

zw

Re: Ada files now checked in

[dewar]

<<FWIW, Debian has pretty much decided to do that.  Requiring an Ada
compiler for every bootstrap of the C compiler would introduce a lot of
complexity, especially given the number of our platforms on which Ada
isn't available - Linux/Alpha in particular seems to be problematic.
>>

That's an entirely reasonable decision

<<Is there any reason that the gcc driver from a 3.1 install which did
not include --enable-languages=ada should be unable to drive gnat1,
though?
>>

The answer to this should be no ...

Re: Ada files now checked in

[Daniel Jacobowitz]

On Sat, Oct 06, 2001 at 12:16:24PM -0400, dewar@gnat.com wrote:
> <<FWIW, Debian has pretty much decided to do that.  Requiring an Ada
> compiler for every bootstrap of the C compiler would introduce a lot of
> complexity, especially given the number of our platforms on which Ada
> isn't available - Linux/Alpha in particular seems to be problematic.
> >>
> 
> That's an entirely reasonable decision
> 
> <<Is there any reason that the gcc driver from a 3.1 install which did
> not include --enable-languages=ada should be unable to drive gnat1,
> though?
> >>
> 
> The answer to this should be no ...

In which case, we only need to package the gnat1 backend separately,
without rebuilding the gcc driver, and can simply drop it in.  That'd
be ideal.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 12:16:24PM -0400, dewar@gnat.com wrote:
> <<FWIW, Debian has pretty much decided to do that.  Requiring an Ada
> compiler for every bootstrap of the C compiler would introduce a lot of
> complexity, especially given the number of our platforms on which Ada
> isn't available - Linux/Alpha in particular seems to be problematic.
> >>
> 
> That's an entirely reasonable decision
> 
> <<Is there any reason that the gcc driver from a 3.1 install which did
> not include --enable-languages=ada should be unable to drive gnat1,
> though?
> >>
> 
> The answer to this should be no ...

I'm afraid the answer is yes.  If you configure a language out with
--enable-languages, its spec strings are not included in the
default_compilers array.  Therefore, even if the front-end magically
appears in $(libsubdir), it won't be able to drive it.

That could of course be changed.

zw

Re: Ada files now checked in

[Daniel Jacobowitz]

On Sat, Oct 06, 2001 at 09:30:02AM -0700, Zack Weinberg wrote:
> On Sat, Oct 06, 2001 at 12:16:24PM -0400, dewar@gnat.com wrote:
> > <<FWIW, Debian has pretty much decided to do that.  Requiring an Ada
> > compiler for every bootstrap of the C compiler would introduce a lot of
> > complexity, especially given the number of our platforms on which Ada
> > isn't available - Linux/Alpha in particular seems to be problematic.
> > >>
> > 
> > That's an entirely reasonable decision
> > 
> > <<Is there any reason that the gcc driver from a 3.1 install which did
> > not include --enable-languages=ada should be unable to drive gnat1,
> > though?
> > >>
> > 
> > The answer to this should be no ...
> 
> I'm afraid the answer is yes.  If you configure a language out with
> --enable-languages, its spec strings are not included in the
> default_compilers array.  Therefore, even if the front-end magically
> appears in $(libsubdir), it won't be able to drive it.
> 
> That could of course be changed.

I'd very much like to see this change; if it's still true down the line
around 3.1 release (barring things like a specs rewrite we've all been
hoping for), I'll submit a patch myself.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Ada files now checked in

[dewar]

<<Since Laurent Guerby seems to have more luck than me, there's probably
some catch I don't know.  Probably it's essential to build the GNAT
library before the tools.  (This is the exact opposite of the old
approach.)
>>

Yes, this is definitely the right order in which to do things

Re: Ada files now checked in

[dewar]

<< o No recent binaries are publicly available, but the platform is
   supported by ACT (HP-UX, IRIX, and a few more).  Perhaps ACT would
   rather like to provide a minimal set of binaries instead of a full
   compiler.
>>

Right, it is easy for us to prvide a full minimal set of binaries, but
getting full public releases out is much more work, and not likely
to happen for a number of targets.

Re: Ada files now checked in

[dewar]

<<In June 2000, Robert Dewar expressed rather strong reservations
concerning the -W options together with the Ada frontend (more false
positives, GCC backend doesn't know much about Ada semantics, and so
on).  Are these problems no longer relevant?  (At least warnings about
unused variables do not properly demangle the name, BTW.)
>>

It has been a goal to eliminate these prblems, and at this point they are
eliminated, we have worked for a while ensuring that our sources do in
fact compile fine with -Wall.

Re: Ada files now checked in

[dewar]

Only -W and -Wall would be relevant, -Wwrite-strings has no meaning
for Ada. We do in fact try to keep the sources warning free (*) so
this is perfectly reasonable.

(*) I must say I find the warnings in this area from gcc to be awful. To
be told that somewhere in a procedure there is a suspicious use of a
particular variable, but not to have this particular use pointed out
is quite annoying, given that

a) the compiler really could know the specific case 
b) 95% of the time these warnings are wrong, and so you are not looking for
     a suspicious use, but one that the compiler thinks is suspicious.

We are intending to compeltely duplicate these kind of warnings in the
GNAT front end eventually since there we can give much more precise
information about where and why a reference is considered suspicious,
and when that is done it will be even easier to keep the sources
warning free.

Most certainly our general philosohpy in GNAT is turn on all the warnings,
and then make warnings fatal, so that it is not just desirable, but
mandatory to remove all warnings.

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 11:10:29AM -0400, dewar@gnat.com wrote:
> Only -W and -Wall would be relevant, -Wwrite-strings has no meaning
> for Ada. We do in fact try to keep the sources warning free (*) so
> this is perfectly reasonable.

Okay, I will revise the patch to include -W and -Wall in the
appropriate position.

> (*) I must say I find the warnings in this area from gcc to be awful. To
> be told that somewhere in a procedure there is a suspicious use of a
> particular variable, but not to have this particular use pointed out
> is quite annoying, given that
> 
> a) the compiler really could know the specific case 
> b) 95% of the time these warnings are wrong, and so you are not looking for
>      a suspicious use, but one that the compiler thinks is suspicious.

Completely agreed, and there is work in progress to improve these
warnings.

zw

Re: Ada files now checked in

[dewar]

<<Also, if it will result in a significant simplification of the build
process, it may be worth rewriting these tools in C.
>>

Maybe, but that's quite a bit of work. They are originally written using
powerful pattern matching of SNOBOL4. This translates directly into Ada,
using the GNAT.Spitbol.Patterns unit which provides exactly SNOBOL4
semantics pattern matching capabilities in Ada.

That does not mean that it is impossible to rewrite these in C, but
it would introduce a definite additional burden of keeping these C
tools in sync with the Ada ones (they do change every now and then
when e.g. the form of the tree changes enough to affect these tools).

Given that GNAT in any case needs "foreign" executables (namely gnat1),
then at worst we can simply provide these executables wherever we provide
the starter gnat1 binaries for the bootstrap.

I still think we should be able to build these without too much difficulty
as part of the build process. TBD

Robert

Re: Ada files now checked in

[Zack Weinberg]

On Sat, Oct 06, 2001 at 11:06:41AM -0400, dewar@gnat.com wrote:
> <<Also, if it will result in a significant simplification of the build
> process, it may be worth rewriting these tools in C.
> >>
>
> Maybe, but that's quite a bit of work. They are originally written
> using powerful pattern matching of SNOBOL4. This translates directly
> into Ada, using the GNAT.Spitbol.Patterns unit which provides
> exactly SNOBOL4 semantics pattern matching capabilities in Ada.

Yes, I noticed that.  I am fairly confident they could be rewritten
using regular expressions, in say Perl.  Perhaps we could stop there,
if you're okay requiring Perl (this is already the case for people
wishing to generate manpages).  Or, translating a short Perl program
into C is not *that* hard.

> That does not mean that it is impossible to rewrite these in C, but
> it would introduce a definite additional burden of keeping these C
> tools in sync with the Ada ones (they do change every now and then
> when e.g. the form of the tree changes enough to affect these
> tools).

What, you want to keep the Ada tools around as well as the C or Perl
ones?  That would be silly.  We only need one version.

> I still think we should be able to build these without too much
> difficulty as part of the build process. TBD

I'm now wondering how much additional trouble it would be to require
the presence of the basic Ada runtime library as well as a bootstrap
compiler.  That would not only make it easy to generate these tools,
it would permit us to separate the construction of the compiler from
the construction of the runtime.  I think this would make it easier to
maintain both in the long run.  The only real disadvantage is that you
wind up with a compiler binary linked against the previous version of
the runtime, but this is not a huge problem, and one can always relink
the binaries afterward.

zw

Re: Ada files now checked in

[Richard Kenner]

    Doesn't CVS reset the file modification time to the time the file was
    committed to the repository?  This means that the "touch" trick is a
    bit fragile.

It's no more fragile than doing it for, say, c-parse.c or configure.
It just means that whoever modified the underlying file in CVS needs
to be sure to modify that file.

Re: Ada files now checked in

[Richard Kenner]

    Since Laurent Guerby seems to have more luck than me, there's probably
    some catch I don't know.  Probably it's essential to build the GNAT
    library before the tools.  (This is the exact opposite of the old
    approach.)

Normally the library and tools and built in that order, but it shouldn't
matter because they are going into different directories.

Re: Ada files now checked in

[Richard Kenner]

      o No recent binaries are publicly available, but the platform is
        supported by ACT (HP-UX, IRIX, and a few more).  Perhaps ACT would
        rather like to provide a minimal set of binaries instead of a full
        compiler.

Yes, plus you don't need to have a platform supported to be able to provide
a gnat1 and gnatbind for it.  There's no need to run full qualification
testing: all that needs to be known is that a bootstrap can be completed
with those files. 

Re: Ada files now checked in

[Richard Kenner]

    In June 2000, Robert Dewar expressed rather strong reservations
    concerning the -W options together with the Ada frontend (more false
    positives, GCC backend doesn't know much about Ada semantics, and so
    on).  Are these problems no longer relevant?  

Less relevant.  We find they are relatively useful and have found bugs
that had gone unnoticed previously.

    (At least warnings about unused variables do not properly demangle the
    name, BTW.)

Known bug.  Should be fixed in a bit.

Re: Ada files now checked in

[Richard Kenner]

    The GNAT package I have is based on GCC 2.8.1, the C compiler of which
    is ancient and does not work properly with GNU libc 2.2.x.  It is
    effectively useless.

Right, but once the manual procedure is done *one time*, you will now have a
package which will work properly.

Re: Ada files now checked in

[Zack Weinberg]

On Fri, Oct 05, 2001 at 06:11:11PM -0400, Richard Kenner wrote:
>     The GNAT package I have is based on GCC 2.8.1, the C compiler of which
>     is ancient and does not work properly with GNU libc 2.2.x.  It is
>     effectively useless.
> 
> Right, but once the manual procedure is done *one time*, you will now have a
> package which will work properly.

No.  I have either to do the manual procedure *every time I build the
compiler*, or I am not testing with the vendor-provided packages
anymore, and that is the whole point.

zw

Re: Ada files now checked in

[Richard Kenner]

    On the contrary, it is the only way to make the CVS tree build without
    extra effort on the part of every person building it.

I disagree.

    This is not a nonstandard configuration that I have.  This is the way
    GNAT has been packaged for most Linux distributions for as long as
    I've been paying attention to these things.

I know, but that's "nonstandard".  There is not supposed to be a different
name for the driver program.  I have no idea why they chose to do it that
way, but I don't feel it reasonable to clutter up the Makefile to support
an incorrect and now obsolete packaging.

No ACT-related GNAT release, either customer releases or public releases
orginally prepared by ACT has had such a nonstandard usage.

Yes, there is a bootstrap problem because GNAT is written in Ada, but once
the GCC binary packages start including it, this problem will go away.  We
don't need to add the complexity just for that short period.

Re: Ada files now checked in

[Zack Weinberg]

On Fri, Oct 05, 2001 at 06:06:50PM -0400, Richard Kenner wrote:
>     On the contrary, it is the only way to make the CVS tree build without
>     extra effort on the part of every person building it.
> 
> I disagree.

I'd like to see how you propose to make the extra effort disappear
otherwise.  I've been quite clear where it comes from.

>     This is not a nonstandard configuration that I have.  This is the way
>     GNAT has been packaged for most Linux distributions for as long as
>     I've been paying attention to these things.
> 
> I know, but that's "nonstandard".  There is not supposed to be a
> different name for the driver program.  I have no idea why they
> chose to do it that way, but I don't feel it reasonable to clutter
> up the Makefile to support an incorrect and now obsolete packaging.
>
> No ACT-related GNAT release, either customer releases or public
> releases orginally prepared by ACT has had such a nonstandard usage.

"ACT never does that" is not the same as "wrong."

The system integrators who shipped separate drivers for Ada and
everything else have good reason to do it that way - see Daniel
Jacobowitz' comments downthread, for instance.  The FSF tree needs to
support a wider range of initial system configurations than your
private tree does.

> Yes, there is a bootstrap problem because GNAT is written in Ada,
> but once the GCC binary packages start including it, this problem
> will go away.  We don't need to add the complexity just for that
> short period.

This "short period" you refer to stretches from now until GCC >=3.1
(including Ada) is the default system compiler on every relevant
platform.  That will take at least two years.

zw

Re: Ada files now checked in

[Joseph S. Myers]

On Fri, 5 Oct 2001, Richard Kenner wrote:

> I know, but that's "nonstandard".  There is not supposed to be a different
> name for the driver program.  I have no idea why they chose to do it that
> way, but I don't feel it reasonable to clutter up the Makefile to support
> an incorrect and now obsolete packaging.

We should bear in mind RMS's comments in
<URL: http://gcc.gnu.org/ml/gcc/2000-11/msg00239.html >:

	Meanwhile, I have to wonder why running GNU Ada on a popular version
	of the GNU system needs the attention of a group outside the core
	developers of GNU Ada.  Supporting GNU/Linu ought to be one of the
	main priorities of the core group.

and <URL: http://gcc.gnu.org/ml/gcc/2000-11/msg00271.html >:

	Making RPMs is not part of a GNU maintainer's duties.  Our preferred
	version of GNU/Linux is Debian, so we should give Debian developers
	full cooperation, but we normally don't tell GNU package maintainers
	that they themselves should make the Debian packages (though they can
	do that job too if they want to).

	However, Guerby's message suggested that there are other issues
	involved, that this is not just a matter of making packages.

Clearly CVS GCC ought to support bootstrapping via the packaged GNAT on
the FSF-preferred version of GNU/Linux.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Richard Kenner]

    You really don't need gnatmake, these are simple programs to build

That's right, you don't, but I'm not sure we want to put yet more
explicit lists of RTS modules that are used in the Makefile.

Re: Ada files now checked in

[dewar]

<<That would be nice too in the long term, but I think will make the
initial bootstrap process more complex since then you need gnatmake and
a full library as well.
>>

You really don't need gnatmake, these are simple programs to build

Re: Ada files now checked in

[Richard Kenner]

    Um, no, they're not - well, sinfo.h and einfo.h are not, anyway.

Sorry.  I forgot to check.  I was told the files I started from were
complete.

Geert: can you add them?

Re: Ada files now checked in

[Geert Bosch]

On Thu, 4 Oct 2001, Richard Kenner wrote:

      Um, no, they're not - well, sinfo.h and einfo.h are not, anyway.
  
  Sorry.  I forgot to check.  I was told the files I started from were
  complete.
  
  Geert: can you add them?
  
Yes, I'll add them as part of a number of updates I'll finish this afternoon.

  -Geert

Re: Ada files now checked in

[Zack Weinberg]

On Thu, Oct 04, 2001 at 03:31:21PM -0400, Geert Bosch wrote:
> On Thu, 4 Oct 2001, Richard Kenner wrote:
> 
>       Um, no, they're not - well, sinfo.h and einfo.h are not, anyway.
>   
>   Sorry.  I forgot to check.  I was told the files I started from were
>   complete.
>   
>   Geert: can you add them?
>   
> Yes, I'll add them as part of a number of updates I'll finish this afternoon.

still waiting...

zw

Re: Ada files now checked in

[Geert Bosch]

On Fri, 5 Oct 2001, Zack Weinberg wrote:

  >   Geert: can you add them?
  >   
  > Yes, I'll add them as part of a number of updates I'll finish this afternoon.
  
  still waiting...
  
Actually, the reason I had not added them is that they were not
checked in in our repository (we generate them every night and include
them in the packaged sources, rather than checking them in).
I'm now changing the Makefile to build the tools.

  -Geert

Re: Ada files now checked in

[Florian Weimer]

Zack Weinberg <zack@codesourcery.com> writes:

>> Yes, I'll add them as part of a number of updates I'll finish this
>> afternoon.
>
> still waiting...

Even if you have them, and have worked around the other build
problems, the resulting compiler doesn't seem to be usable at the
moment, I'm afraid.  For example, the stage2 gnatbind tool does not
work correctly (the stage1 one so far does, however).  You can already
test a few things with the current sources (Yes! one GIGI abort which
bugged me in the past is gone ;-), but if you want to build the
run-time library in order to be able to compile and link something
(and not just GNAT and its tools), you have to do this manually (or
fix the build process ;-).

BTW, it doesn't seem to be possible to build the run-time library
at stage 1 because the makefile uses .ali and object files from the
compiler build itself (which are compiled by the old compiler used for
bootstrapping, another VPATH issue).  Is this a feature?

Re: Ada files now checked in

[Florian Weimer]

Ingrid^WFlorian Weimer <fw@deneb.enyo.de> writes:

> but if you want to build the run-time library in order to be able to
> compile and link something (and not just GNAT and its tools), you
> have to do this manually (or fix the build process ;-).

Since Laurent Guerby seems to have more luck than me, there's probably
some catch I don't know.  Probably it's essential to build the GNAT
library before the tools.  (This is the exact opposite of the old
approach.)

I'm going to give it another try tomorrow.

Re: Ada files now checked in

[Laurent Guerby]

The relevant part of my patch is ada/Make-lang.in, remove $(GCC_PARTS) from the line:

gnattools: $(GCC_PARTS) force

I haven't fully investigated the situation, but if I believe that for
a native build if a bootsrap has completed, we don't need anything
else for building gnattools.

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada files now checked in

[Geert Bosch]

On Sat, 6 Oct 2001, Florian Weimer wrote:
  Since Laurent Guerby seems to have more luck than me, there's probably
  some catch I don't know.  Probably it's essential to build the GNAT
  library before the tools.  (This is the exact opposite of the old
  approach.)

Currently, the bootstrap on x86 is not successfull, which probably
is due to a GCC change between the time we packaged up the sources
(about a week ago, after we did a successful bootstrap/regression test)
to contribute and now.

We'll post a message when this problem has been fixed.

  -Geert

Re: Ada files now checked in

[Richard Kenner]

    I tend to agree with the people who are saying that these files ought
    to be generated in the build directory during the bootstrap.

That would be nice too in the long term, but I think will make the
initial bootstrap process more complex since then you need gnatmake and
a full library as well.

    1. Any compilation of an Ada source file (.ads or .adb) might have to
    use a different program from the one used to compile C source.  

I don't think we want or need to support that.  It adds unnecessary
complexity and confusion.  We *want* the same compiler to be used for
everything.

    Now, the aclocal.m4 gook has the sole purpose of setting ADAC and
    GNATBIND correctly.  GNATBIND is easy - just call AC_CHECK_TOOL.
    (AC_CHECK_PROG was being used, but that will pick the wrong program in
    a cross-compilation.)  ADAC is trickier.  

Again, I don't think we want to go to this much trouble to support
non-standard configurations.  This is a new front-end: we don't need to
burden it with backwrds-compatibility like this.

Re: Ada files now checked in

[Geert Bosch]

On Thu, 4 Oct 2001, Richard Kenner wrote:

      I tend to agree with the people who are saying that these files ought
      to be generated in the build directory during the bootstrap.
  
  That would be nice too in the long term, but I think will make the
  initial bootstrap process more complex since then you need gnatmake and
  a full library as well.

I think the best solution here is to have the rules to update them if needed,
but provide correct generated versions for releases. I agree with Richard
that we don't want really require a full working GNAT version to bootstrap.

  -Geert

Re: Ada files now checked in

[Zack Weinberg]

On Thu, Oct 04, 2001 at 03:19:10PM -0400, Geert Bosch wrote:
> On Thu, 4 Oct 2001, Richard Kenner wrote:
> 
>       I tend to agree with the people who are saying that these files ought
>       to be generated in the build directory during the bootstrap.
>   
>   That would be nice too in the long term, but I think will make the
>   initial bootstrap process more complex since then you need gnatmake and
>   a full library as well.
> 
> I think the best solution here is to have the rules to update them if needed,
> but provide correct generated versions for releases. I agree with Richard
> that we don't want really require a full working GNAT version to bootstrap.

It may be acceptable to require a full working GNAT to bootstrap the
CVS tree, but ship these files with snapshots and releases so that it
is not necessary for users of those.

This is the same scenario as with the Yacc-generated parsers used for
C, C++, and Java.  They are not checked into CVS, but provided with
snapshots.  (We still construct them in the source directory, which is
wrong, but difficult to fix at this time.)

Also, if it will result in a significant simplification of the build
process, it may be worth rewriting these tools in C.

zw

Re: Ada files now checked in

[Geert Bosch]

On Fri, 5 Oct 2001, Zack Weinberg wrote:

  It may be acceptable to require a full working GNAT to bootstrap the
  CVS tree, but ship these files with snapshots and releases so that it
  is not necessary for users of those.

That's what I was thinking too.
  
  This is the same scenario as with the Yacc-generated parsers used for
  C, C++, and Java.  They are not checked into CVS, but provided with
  snapshots.  (We still construct them in the source directory, which is
  wrong, but difficult to fix at this time.)
  
  Also, if it will result in a significant simplification of the build
  process, it may be worth rewriting these tools in C.

I don't think that is necessary. It would be easy enough to add the
few lines to the make file to build these extremely simple utilities.
A gnat executable is needed anyway.

  -Geert

Re: Ada files now checked in

[Zack Weinberg]

On Fri, Oct 05, 2001 at 04:59:32PM -0400, Geert Bosch wrote:
>   
>   Also, if it will result in a significant simplification of the build
>   process, it may be worth rewriting these tools in C.
> 
> I don't think that is necessary. It would be easy enough to add the
> few lines to the make file to build these extremely simple utilities.
> A gnat executable is needed anyway.

I thought Richard said they needed a lot more of the Ada standard
library than gnat1 itself did?

zw

Re: Ada files now checked in

[Florian Weimer]

Zack Weinberg <zack@codesourcery.com> writes:

> On Fri, Oct 05, 2001 at 04:59:32PM -0400, Geert Bosch wrote:
> >   
>>   Also, if it will result in a significant simplification of the build
>>   process, it may be worth rewriting these tools in C.
>> 
>> I don't think that is necessary. It would be easy enough to add the
>> few lines to the make file to build these extremely simple utilities.
>> A gnat executable is needed anyway.
>
> I thought Richard said they needed a lot more of the Ada standard
> library than gnat1 itself did?

This does not matter in some cases.  I think we are dealing with quite
different scenarios at the same time:

  o Recent GNAT binaries are publicly available (GNU/Linux, FreeBSD,
    Solaris, Win32, to list a few platforms).  Almost any approach
    will work.  (Are the GNU libc 2.2/gcc 2.8.1 incompatibilities so
    severe?)  We have too separate cases here:

       - gcc is Ada-enabled
       - gcc is not, but gnatgcc/adagcc

  o No recent binaries are publicly available, but the platform is
    supported by ACT (HP-UX, IRIX, and a few more).  Perhaps ACT would
    rather like to provide a minimal set of binaries instead of a full
    compiler.

  o GCC backend does exist, but no GNAT binaries.  A cross-compiler is
    necessary, but not a complete development chain.  It is usually
    sufficient to copy the assembler files generated from the Ada
    source code to the target machine and proceed from there.

I think the GNAT build process should be tailored to the first case
(and both sub-cases).  The second case is only relevant during a
transition period, and all the proposals discussed so far do note make
the third case easier.

Re: Ada files now checked in

[Zack Weinberg]

On Thu, Oct 04, 2001 at 03:20:47PM -0400, Richard Kenner wrote:
> 
>     1. Any compilation of an Ada source file (.ads or .adb) might have to
>     use a different program from the one used to compile C source.  
> 
> I don't think we want or need to support that.  It adds unnecessary
> complexity and confusion.

On the contrary, it is the only way to make the CVS tree build without
extra effort on the part of every person building it.

>     Now, the aclocal.m4 gook has the sole purpose of setting ADAC and
>     GNATBIND correctly.  GNATBIND is easy - just call AC_CHECK_TOOL.
>     (AC_CHECK_PROG was being used, but that will pick the wrong program in
>     a cross-compilation.)  ADAC is trickier.  
> 
> Again, I don't think we want to go to this much trouble to support
> non-standard configurations.  This is a new front-end: we don't need to
> burden it with backwrds-compatibility like this.

I thought I had made clear why this was necessary.

This is not a nonstandard configuration that I have.  This is the way
GNAT has been packaged for most Linux distributions for as long as
I've been paying attention to these things.  It's very simple.  There
is one compiler driver that knows about all the languages included in
the primary GCC distribution.  Each add-on language (Ada, Pascal, etc)
has its own driver, which knows only about its own language.

I therefore have the following three choices:

I can jump through extensive hoops to construct a private bootstrap
compiler which speaks both C and Ada and use that.  I will not do
this, because a major reason why I do daily builds is to make sure
that the CVS tree can be compiled and tested using only stock
distribution tools.

I can fix the Makefiles, as I have done, so that they comprehend
this *common* configuration and work correctly.

Or I can ignore Ada until the system compiler becomes one that
understands it.  This probably won't happen until 2003 or so.  I
guarantee you this is the choice most people will make.

I should point out that the distribution maintainers may choose to
continue off-loading Ada into a separate package, if they have the
choice between that and jumping through the above-mentioned hoops to
build the C compiler.  Thus you may be *permanently* stuck with the
dual driver situation, and therefore with a dramatically reduced
potential user base, if you refuse to give us a transition plan away
from it.

zw

Re: Ada files now checked in

[Geert Bosch]

On Fri, 5 Oct 2001, Zack Weinberg wrote:
  I therefore have the following three choices:
  
  I can jump through extensive hoops to construct a private bootstrap
  compiler which speaks both C and Ada and use that.  I will not do
  this, because a major reason why I do daily builds is to make sure
  that the CVS tree can be compiled and tested using only stock
  distribution tools.
  
  I can fix the Makefiles, as I have done, so that they comprehend
  this *common* configuration and work correctly.
  
  Or I can ignore Ada until the system compiler becomes one that
  understands it.  This probably won't happen until 2003 or so.  I
  guarantee you this is the choice most people will make.

Robert and I suggested a fourth version:
  Build GNAT using the newly generated GCC driver, requiring only access
  to the gnat1/gnatbind executables.

I must say that I do not understand the issue. Either you have a
GCC version with an Ada front end, or you don't.
In the first case, you set the CC environment to your GCC driver
with Ada support (if configure cannot figure this out). 

In the second case you need to download a complete Ada compiler and
you're back in the first case, or you have to get a gnat1/gnatbind
executable and you'd need our fourth solutoin.

Why are there any problems with this approach?

  -Geert

Re: Ada files now checked in

[Florian Weimer]

Geert Bosch <bosch@gnat.com> writes:

> I must say that I do not understand the issue. Either you have a
> GCC version with an Ada front end, or you don't.
> In the first case, you set the CC environment to your GCC driver
> with Ada support (if configure cannot figure this out). 

I think it's reasonable to do daily builds mainly with a current (but
not bleeding-edge) compiler, say egcs 1.x or GCC 2.95.3, which is in
widespread use.  If you use the gcc driver binary of a typical GNAT
distribution, you divert significantly from a usual GCC installation,
so the feedback from the daily builds is less meaningful.

Re: Ada files now checked in

[Zack Weinberg]

On Fri, Oct 05, 2001 at 11:37:17PM +0200, Florian Weimer wrote:
> Geert Bosch <bosch@gnat.com> writes:
> 
> > I must say that I do not understand the issue. Either you have a
> > GCC version with an Ada front end, or you don't.
> > In the first case, you set the CC environment to your GCC driver
> > with Ada support (if configure cannot figure this out). 
> 
> I think it's reasonable to do daily builds mainly with a current (but
> not bleeding-edge) compiler, say egcs 1.x or GCC 2.95.3, which is in
> widespread use.  If you use the gcc driver binary of a typical GNAT
> distribution, you divert significantly from a usual GCC installation,
> so the feedback from the daily builds is less meaningful.

Precisely.

The GNAT package I have is based on GCC 2.8.1, the C compiler of which
is ancient and does not work properly with GNU libc 2.2.x.  It is
effectively useless.

zw

Re: Ada files now checked in

[Zack Weinberg]

On Fri, Oct 05, 2001 at 04:55:14PM -0400, Geert Bosch wrote:
> 
> Robert and I suggested a fourth version:
>   Build GNAT using the newly generated GCC driver, requiring only access
>   to the gnat1/gnatbind executables.

This is what I was talking about when I said

>> I can jump through extensive hoops to construct a private bootstrap
>> compiler which speaks both C and Ada and use that.

It requires you to perform a partial build, install the results, drop
binaries into the installation tree, and repeat; and it does not
accomplish the goal, which is to test construction of the complete
tree, _including_ Ada, with the vendor-provided tools.

> I must say that I do not understand the issue. Either you have a
> GCC version with an Ada front end, or you don't.
>
> In the first case, you set the CC environment to your GCC driver
> with Ada support (if configure cannot figure this out). 

You are assuming that the GCC driver with Ada support can handle C,
which is not necessarily the case.  As it happens, the one on my
system does include a cc1 - but it's 2.8.1-based, and therefore does
not work with glibc 2.2.x, so it might as well not exist.

Turn it around: The changes I made to ada/Makefile.in are
straightforward and obvious, and they make the build work out-of-box
for a large category of users that would otherwise have to go to
considerable extra trouble.  Why do you object so strenuously?

zw

Re: Ada files now checked in

[Geert Bosch]

On Fri, 5 Oct 2001, Zack Weinberg wrote:
  
  You are assuming that the GCC driver with Ada support can handle C,
  which is not necessarily the case.  As it happens, the one on my
  system does include a cc1 - but it's 2.8.1-based, and therefore does
  not work with glibc 2.2.x, so it might as well not exist.

So, you're saying that GCC can be bootstrapped with about any compiler, 
but not with a somewhat older version of itself?
  
  Turn it around: The changes I made to ada/Makefile.in are
  straightforward and obvious, and they make the build work out-of-box
  for a large category of users that would otherwise have to go to
  considerable extra trouble.  Why do you object so strenuously?

I don't object strenuously, but I have never ran into problems starting
out with GCC 2.8.1 and I have build GNAT on dozens of different platforms.
Anyway, I don't feel strongly at all about this issue, but I'd like
to try it out first and see how it works for me before commenting on
it any more.

  -Geert

Re: Ada files now checked in

[Zack Weinberg]

On Fri, Oct 05, 2001 at 06:17:41PM -0400, Geert Bosch wrote:
> 
> On Fri, 5 Oct 2001, Zack Weinberg wrote:
>   
>   You are assuming that the GCC driver with Ada support can handle C,
>   which is not necessarily the case.  As it happens, the one on my
>   system does include a cc1 - but it's 2.8.1-based, and therefore does
>   not work with glibc 2.2.x, so it might as well not exist.
> 
> So, you're saying that GCC can be bootstrapped with about any compiler, 
> but not with a somewhat older version of itself?

Only because 2.8.1 is incompatible with glibc 2.2.x.  More
specifically, it has a bunch of bugs that get tripped up by glibc's
aggressively modern header files.

zw

Re: Ada files now checked in

[Joseph S. Myers]

On Fri, 5 Oct 2001, Zack Weinberg wrote:

> Each add-on language (Ada, Pascal, etc)
> has its own driver, which knows only about its own language.

Incidentally, what is the status of GNU Pascal's readiness for integration
into GCC?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Daniel Jacobowitz]

On Fri, Oct 05, 2001 at 01:39:43PM -0700, Zack Weinberg wrote:
> Or I can ignore Ada until the system compiler becomes one that
> understands it.  This probably won't happen until 2003 or so.  I
> guarantee you this is the choice most people will make.
> 
> I should point out that the distribution maintainers may choose to
> continue off-loading Ada into a separate package, if they have the
> choice between that and jumping through the above-mentioned hoops to
> build the C compiler.  Thus you may be *permanently* stuck with the
> dual driver situation, and therefore with a dramatically reduced
> potential user base, if you refuse to give us a transition plan away
> from it.

FWIW, Debian has pretty much decided to do that.  Requiring an Ada
compiler for every bootstrap of the C compiler would introduce a lot of
complexity, especially given the number of our platforms on which Ada
isn't available - Linux/Alpha in particular seems to be problematic.

Is there any reason that the gcc driver from a 3.1 install which did
not include --enable-languages=ada should be unable to drive gnat1,
though?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Ada files now checked in

[Richard Kenner]

    With the appended patch, using the Debian packages of gnat 3.13p, I
    can get as far as where it trips over the absence of .spt files and/or
    xsinfo/xnmake/xtreeprs.  I believe this is the problem Laurent is
    addressing?

Sort of.  The real problem is that "touch" commands are missing since the
files are there.

I don't even begin to understand your patch, though.

Re: Ada files now checked in

[Zack Weinberg]

On Thu, Oct 04, 2001 at 02:24:36PM -0400, Richard Kenner wrote:
>     With the appended patch, using the Debian packages of gnat 3.13p, I
>     can get as far as where it trips over the absence of .spt files and/or
>     xsinfo/xnmake/xtreeprs.  I believe this is the problem Laurent is
>     addressing?
> 
> Sort of.  The real problem is that "touch" commands are missing since the
> files are there.

I tend to agree with the people who are saying that these files ought
to be generated in the build directory during the bootstrap.

> I don't even begin to understand your patch, though.

Sorry, I should have explained it the first time.

Ignore the change to aclocal.m4 for the moment.  The remainder of the
patch is straightforward.  It does two things: 

1. Any compilation of an Ada source file (.ads or .adb) might have to
use a different program from the one used to compile C source.  This
program is given the makefile variable ADAC (for "ada compiler"),
which is set by the configure script.  All the rules that formerly
used $(CC) to compile Ada are changed to use $(ADAC) instead.

2. Since gnat 3.13 objects to -W options, compilation command lines
for Ada must not include them.  However, compilation of C in the ada
subdirectory should include -W options.  

They are appearing because the top level Makefile sets submake CFLAGS
to "$(CFLAGS) $(WARN_CFLAGS)" (look for the definition of
ORDINARY_FLAGS_TO_PASS).  This is fine for C, but for Ada we want just
the toplevel CFLAGS (which is where -g and -O switches appear).  In
ada/Make-lang.in, therefore, I cause ADA_CFLAGS to be set to $(CFLAGS)
in the sub-make invocation.  ada/Makefile.in is then changed to use
just ADA_CFLAGS in ALL_ADAFLAGS and MOST_ADAFLAGS.  All $(ADAC)
invocations use one of those two, so we are now safe.

As a side effect ADA_CFLAGS is no longer available for overriding by
target Makefile fragments.  The only ones that do are pa/t-* which all
set -mdisable-indexing.  Does anyone know what that switch means?

Now, the aclocal.m4 gook has the sole purpose of setting ADAC and
GNATBIND correctly.  GNATBIND is easy - just call AC_CHECK_TOOL.
(AC_CHECK_PROG was being used, but that will pick the wrong program in
a cross-compilation.)  ADAC is trickier.  The core is this loop:

for cand in ${ac_tool_prefix}$user_adac $user_adac      \
            ${ac_tool_prefix}gcc        gcc             \
            ${ac_tool_prefix}gnatgcc    gnatgcc         \
            ${ac_tool_prefix}cc         cc              \
            ${ac_tool_prefix}gnatcc     gnatcc          ; do
  # There is a bug in all released versions of GCC which causes the
  # driver to exit successfully when the appropriate language module
  # has not been installed.  This is fixed in 2.95.4, 3.0.2, and 3.1.
  # Therefore we must check for the error message as well as an
  # unsuccessful exit.
  errors=`$cand -c conftest.adb 2>&1 || echo failure`
  if test x"$errors" = x; then
    gcc_cv_prog_adac=$cand
    break
  fi
  gcc_cv_prog_adac=no
done

(oops, the last two lines should be switched.)  It iterates over a
series of four (normally) possible candidates for the Ada compiler
driver.  Each is asked to compile a trivial Ada procedure.  The first
one that exits successfully and produces no output is taken to work.
We then set up ADAC appropriately.

The stuff with ${ac_tool_prefix} is to simulate the effect of
AC_CHECK_TOOL: if we were cross compiling we would probably want
something named powerpc-eabi-gnatgcc, for instance.

zw

Re: Ada files now checked in

[Geert Bosch]

On Thu, 4 Oct 2001, Zack Weinberg wrote:

  2. Since gnat 3.13 objects to -W options, compilation command lines
  for Ada must not include them.  However, compilation of C in the ada
  subdirectory should include -W options.  

Also, in stage2 and stage3, we want to use the -W options for Ada files. 
It is not the case that they are not used, since what happens is that
GNAT has the back end recognize its options (everything except -gnat* and
a few others), and processes the front-end options itself.

We work hard to keep the compiler warning free, and it is way too easy to 
start introducing new uninitialized variables and the like without using
-Wuninitialized. Also the warnings are useful to us, as they have caught 
some lingering bugs that would have been hard to find otherwise.

  -Geert

Re: Ada files now checked in

[Zack Weinberg]

On Thu, Oct 04, 2001 at 03:09:48PM -0400, Geert Bosch wrote:
> 
> 
> On Thu, 4 Oct 2001, Zack Weinberg wrote:
> 
>   2. Since gnat 3.13 objects to -W options, compilation command lines
>   for Ada must not include them.  However, compilation of C in the ada
>   subdirectory should include -W options.  
> 
> Also, in stage2 and stage3, we want to use the -W options for Ada files. 
> It is not the case that they are not used, since what happens is that
> GNAT has the back end recognize its options (everything except -gnat* and
> a few others), and processes the front-end options itself.
> 
> We work hard to keep the compiler warning free, and it is way too easy to 
> start introducing new uninitialized variables and the like without using
> -Wuninitialized. Also the warnings are useful to us, as they have caught 
> some lingering bugs that would have been hard to find otherwise.

Oh.  I thought they were all completely ignored.

The simplest way to handle this would probably be to stick the -W
options that are relevant to GNAT into ADAFLAGS and/or SOME_ADAFLAGS.
As long as these are options recognized universally (and it sounds
like the important one is -Wall, which is), there would be no problem.

Of the current list of warnings applied to C code:

LOOSE_WARN = -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
STRICT2_WARN = -Wtraditional -pedantic -Wno-long-long

I think only -W, -Wall, and perhaps -Wwrite-strings are relevant.  Can
you confirm this?

zw

Re: Ada files now checked in

[Florian Weimer]

Geert Bosch <bosch@gnat.com> writes:

> Also, in stage2 and stage3, we want to use the -W options for Ada files. 

In June 2000, Robert Dewar expressed rather strong reservations
concerning the -W options together with the Ada frontend (more false
positives, GCC backend doesn't know much about Ada semantics, and so
on).  Are these problems no longer relevant?  (At least warnings about
unused variables do not properly demangle the name, BTW.)

Re: Ada files now checked in

[Geert Bosch]

On Fri, 5 Oct 2001, Florian Weimer wrote:
  In June 2000, Robert Dewar expressed rather strong reservations
  concerning the -W options together with the Ada frontend (more false
  positives, GCC backend doesn't know much about Ada semantics, and so
  on).  Are these problems no longer relevant?  (At least warnings about
  unused variables do not properly demangle the name, BTW.)
  
Two things have happened. First, the GCC warnings have improved
considerably and secondly, we have changed GNAT to get rid/work around
the remaining warnings.

  -Geert

Re: Ada files now checked in

[Zack Weinberg]

On Thu, Oct 04, 2001 at 02:24:36PM -0400, Richard Kenner wrote:
> 
> Sort of.  The real problem is that "touch" commands are missing since the
> files are there.

Um, no, they're not - well, sinfo.h and einfo.h are not, anyway.

zw

Re: Ada files now checked in

[Florian Weimer]

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

> Sort of.  The real problem is that "touch" commands are missing since the
> files are there.

Doesn't CVS reset the file modification time to the time the file was
committed to the repository?  This means that the "touch" trick is a
bit fragile.

Well, perhaps someone could rewrite the helper programs in Perl. ;-)

Re: Ada files now checked in

[Richard Henderson]

On Sat, Oct 06, 2001 at 01:38:37PM +0200, Florian Weimer wrote:
> Doesn't CVS reset the file modification time to the time the file was
> committed to the repository?

No.


r~

Re: Ada files now checked in

[Richard Kenner]

    Also note, that we probably could generate binder files (the ones that
    call all initialization procedures in the right order etc.) and
    provide these as part of full releases, so just the "gnat1" executable
    is needed.

Those files are (slightly) machine-dependent, so it would be easiler to
supply a gnatbind than those files.

Re: Ada files now checked in

[Richard Kenner]

    I'm taking the position that we want "make bootstrap" from the top
    level to Just Work provided appropriate tools are available in the
    user's PATH. 

Correct.  "Appropriate tools" here means a complete GNAT installation.
But if you don't have it, the *first time* you build it, there is
another way with less.

Re: Ada files now checked in

[Zack Weinberg]

On Thu, Oct 04, 2001 at 01:29:30PM -0400, Richard Kenner wrote:
>     I'm taking the position that we want "make bootstrap" from the top
>     level to Just Work provided appropriate tools are available in the
>     user's PATH. 
> 
> Correct.  "Appropriate tools" here means a complete GNAT installation.
> But if you don't have it, the *first time* you build it, there is
> another way with less.

With the appended patch, using the Debian packages of gnat 3.13p, I
can get as far as where it trips over the absence of .spt files and/or
xsinfo/xnmake/xtreeprs.  I believe this is the problem Laurent is
addressing?

zw

top level:
	* aclocal.m4 (gcc_AC_PROG_GNAT): New.
	* configure.in: Use it.
ada:
	* Make-lang.in (ADA_FLAGS_TO_PASS): Override ADA_CFLAGS.
	* Makefile.in (ADAC): New variable set by autoconf.
	(ALL_ADAFLAGS, MOST_ADAFLAGS): Do not include CFLAGS.
	(.adb.o, .ads.o, a-numaux.o, a-teioed.o, s-interr.o,
	s-taskin.o, sdefault.o, s-tasdeb.o, s-vaflop.o, a-except.o,
	s-assert.o, s-stalib.o, s-memory.o, memtrack.o, mlib-tgt.o):
	Use $(ADAC) not $(CC) in commands.
	(gnattools): Don't use recursive make.

===================================================================
Index: configure.in
--- configure.in	2001/09/29 18:22:03	1.542
+++ configure.in	2001/10/04 18:05:08
@@ -469,7 +469,7 @@ gcc_AC_C_COMPILE_ENDIAN
 gcc_AC_C_FLOAT_FORMAT
 
 # See if GNAT has been installed
-AC_CHECK_PROG(have_gnat, gnatbind, yes, no)
+gcc_AC_PROG_GNAT
 
 # See if we have the mktemp command.
 AC_CHECK_PROG(have_mktemp_command, mktemp, yes, no)
===================================================================
Index: aclocal.m4
--- aclocal.m4	2001/07/18 17:16:58	1.50
+++ aclocal.m4	2001/10/04 18:05:08
@@ -308,6 +308,50 @@ test -z "$INSTALL_DATA" && INSTALL_DATA=
 AC_SUBST(INSTALL_DATA)dnl
 ])
 
+dnl Test for GNAT.
+dnl We require the gnatbind program, and a compiler driver that
+dnl understands Ada.  Add entries to the list as appropriate.
+dnl Sets the shell variable have_gnat to yes or no as appropriate, and
+dnl substitutes GNATBIND and ADAC.
+AC_DEFUN([gcc_AC_PROG_GNAT],
+[AC_REQUIRE([AC_CHECK_TOOL_PREFIX])
+AC_CHECK_TOOL(GNATBIND, gnatbind, no)
+AC_CACHE_CHECK([for compiler driver that understands Ada],
+		 gcc_cv_prog_adac,
+[cat >conftest.adb <<EOF
+procedure conftest is begin null; end conftest;
+EOF
+gcc_cv_prog_adac=
+# Have to do ac_tool_prefix and user overrides by hand.
+user_adac=$ADAC
+for cand in ${ac_tool_prefix}$user_adac	$user_adac	\
+	    ${ac_tool_prefix}gcc	gcc		\
+	    ${ac_tool_prefix}gnatgcc	gnatgcc		\
+	    ${ac_tool_prefix}cc		cc		\
+	    ${ac_tool_prefix}gnatcc	gnatcc		; do
+  # There is a bug in all released versions of GCC which causes the
+  # driver to exit successfully when the appropriate language module
+  # has not been installed.  This is fixed in 2.95.4, 3.0.2, and 3.1.
+  # Therefore we must check for the error message as well as an
+  # unsuccessful exit.
+  errors=`$cand -c conftest.adb 2>&1 || echo failure`
+  if test x"$errors" = x; then
+    gcc_cv_prog_adac=$cand
+    break
+  fi
+  gcc_cv_prog_adac=no
+done
+rm -f conftest.*])
+ADAC=$gcc_cv_prog_adac
+AC_SUBST(ADAC)
+
+if test x$GNATBIND != xno && test x$ADAC != xno; then
+  have_gnat=yes
+else
+  have_gnat=no
+fi
+])
+
 #serial 1
 dnl This test replaces the one in autoconf.
 dnl Currently this macro should have the same name as the autoconf macro
===================================================================
Index: ada/Make-lang.in
--- ada/Make-lang.in	2001/10/02 13:46:42	1.1
+++ ada/Make-lang.in	2001/10/04 18:05:08
@@ -54,6 +54,7 @@ ADA_RTL_OBJ_DIR = $(libsubdir)/adalib
 THREAD_KIND=native
 GNATBIND = gnatbind
 ADA_FLAGS_TO_PASS = \
+	"ADA_CFLAGS=$(CFLAGS)" \
 	"ADA_FOR_BUILD=$(ADA_FOR_BUILD)" \
 	"ADA_INCLUDE_DIR=$(ADA_INCLUDE_DIR)" \
 	"ADA_RTL_OBJ_DIR=$(ADA_RTL_OBJ_DIR)" \
===================================================================
Index: ada/Makefile.in
--- ada/Makefile.in	2001/10/02 13:46:42	1.1
+++ ada/Makefile.in	2001/10/04 18:05:09
@@ -79,6 +79,7 @@ X_CPPFLAGS =
 T_CPPFLAGS =
 
 CC = cc
+ADAC = @ADAC@
 BISON = bison
 BISONFLAGS =
 ECHO = echo
@@ -108,8 +109,8 @@ SOME_ADAFLAGS =-gnata
 FORCE_DEBUG_ADAFLAGS = -g
 GNATLIBFLAGS = -gnatpg
 GNATLIBCFLAGS= -g -O2
-ALL_ADAFLAGS = $(CFLAGS) $(ADA_CFLAGS) $(ADAFLAGS)
-MOST_ADAFLAGS = $(CFLAGS) $(ADA_CFLAGS) $(SOME_ADAFLAGS)
+ALL_ADAFLAGS = $(ADA_CFLAGS) $(ADAFLAGS)
+MOST_ADAFLAGS = $(ADA_CFLAGS) $(SOME_ADAFLAGS)
 THREAD_KIND=native
 GMEM_LIB=
 MISCLIB =
@@ -268,9 +269,9 @@ ADA_INCLUDES_FOR_SUBDIR = -I. -I$(fsrcdi
 .c.o:
 	$(CC) -c $(ALL_CFLAGS) $(ADA_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $<
 .adb.o:
-	$(CC) -c $(ALL_ADAFLAGS) $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) $(ADA_INCLUDES) $<
 .ads.o:
-	$(CC) -c $(ALL_ADAFLAGS) $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) $(ADA_INCLUDES) $<
 
 # This tells GNU make version 3 not to export all the variables
 # defined in this file into the environment.
@@ -836,11 +837,11 @@ ifeq ($(strip $(filter-out %86 interix,$
 
 # Work around for gcc optimization bug wrt cxa5a09
 a-numaux.o  : a-numaux.adb a-numaux.ads                                     
-	$(CC) -c $(ALL_ADAFLAGS) -O2 $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) -O2 $(ADA_INCLUDES) $<
 
 # Work around for gcc optimization bug wrt cxf3a01
 a-teioed.o  : a-teioed.adb a-teioed.ads                   
-	$(CC) -c $(ALL_ADAFLAGS) -O0 $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) -O0 $(ADA_INCLUDES) $<
 
 endif
 
@@ -960,7 +961,7 @@ ifeq ($(strip $(filter-out m68k% wrs vx%
 
 # ??? work around a gcc -O2 bug on m68k
 s-interr.o  : s-interr.adb s-interr.ads
-	$(CC) -c $(ALL_ADAFLAGS) -O1 $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) -O1 $(ADA_INCLUDES) $<
 endif
 
 ifeq ($(strip $(filter-out powerpc% wrs vx%,$(targ))),)
@@ -1140,7 +1141,7 @@ ifeq ($(strip $(filter-out %86 solaris2%
 
 # ??? work around a gcc -O3 bug on x86
 a-numaux.o  : a-numaux.adb a-numaux.ads
-	$(CC) -c $(ALL_ADAFLAGS) -O2 $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) -O2 $(ADA_INCLUDES) $<
 endif
 
 ifeq ($(strip $(filter-out %86 linux%,$(arch) $(osys))),)
@@ -1265,7 +1266,7 @@ a-tcbinf.o: s-tpgetc.ali
 
 # force debug info so that workshop can find the All_Tasks_List symbol
 s-taskin.o: s-taskin.adb s-taskin.ads
-	$(CC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) $(ADA_INCLUDES) $<
 endif
 
 ifeq ($(strip $(filter-out hppa% hp hpux%,$(targ))),)
@@ -1484,7 +1485,7 @@ ifeq ($(strip $(filter-out cygwin32% min
 
 # ??? work around a gcc -O3 bug on x86
 a-numaux.o  : a-numaux.adb a-numaux.ads
-	$(CC) -c $(ALL_ADAFLAGS) -O2 $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) -O2 $(ADA_INCLUDES) $<
 endif
 
 # The runtime library for gnat comprises two directories.  One contains the
@@ -2076,12 +2077,7 @@ gnatbl.o: gnatbl.c adaint.h
 	  true; \
 	fi
 
-gnattools: force
-	$(MAKE) \
-	   "CC=$(CC)" "ALL_CFLAGS=$(ALL_CFLAGS)" "INCLUDE=$(INCLUDES)" \
-	   "LDFLAGS=$(LDFLAGS)" \
-	   "MISCLIB=$(MISCLIB)" "exeext=$(exeext)" \
-	   ../gnatbl$(exeext) ../gnatchop$(exeext) ../gnatcmd$(exeext) \
+gnattools: ../gnatbl$(exeext) ../gnatchop$(exeext) ../gnatcmd$(exeext) \
 	   ../gnatkr$(exeext) ../gnatlink$(exeext) \
 	   ../gnatls$(exeext) ../gnatmake$(exeext) ../gnatmem$(exeext) \
 	   ../gnatprep$(exeext) ../gnatpsta$(exeext) ../gnatpsys$(exeext) \
@@ -2464,40 +2460,43 @@ ADA_TREE_H = ada-tree.h ada-tree.def
 
 sdefault.o : sdefault.ads sdefault.adb types.ads unchdeal.ads \
    system.ads s-exctab.ads s-stalib.ads unchconv.ads 
-	$(CC) -c -O2 $(MOST_ADAFLAGS) $(ADA_INCLUDES) sdefault.adb
+	$(ADAC) -c -O2 $(MOST_ADAFLAGS) $(ADA_INCLUDES) sdefault.adb
 
 # force debugging information on s-tasdeb.o so that it is always
 # possible to set conditional breakpoints on tasks.
 
 s-tasdeb.o  : s-tasdeb.adb s-tasdeb.ads
-	$(CC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) $(ADA_INCLUDES) $<
 
 # force debugging information on s-vaflop.o so that it is always
 # possible to call the VAX float debug print routines.
 # force at least -O so that the inline assembly works.
 
 s-vaflop.o  : s-vaflop.adb s-vaflop.ads
-	$(CC) -c -O $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) $(ADA_INCLUDES) $<
+	$(ADAC) -c -O $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) \
+	 $(ADA_INCLUDES) $<
 
 # force debugging information on a-except.o so that it is always
 # possible to set conditional breakpoints on exceptions.
 # use -O1 otherwise gdb isn't able to get a full backtrace on mips targets.
 
 a-except.o  : a-except.adb a-except.ads
-	$(CC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O1 -fno-inline \
+	$(ADAC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O1 -fno-inline \
 	 $(ADA_INCLUDES) $<
 
 # force debugging information on s-assert.o so that it is always
 # possible to set breakpoint on assert failures.
 
 s-assert.o  : s-assert.adb s-assert.ads a-except.ads
-	$(CC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O2 $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O2 \
+	 $(ADA_INCLUDES) $<
 
 # force debugging information on s-stalib.o so that it is always
 # possible to set breakpoints on exceptions.
 
 s-stalib.o  : s-stalib.adb s-stalib.ads
-	$(CC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O2 $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O2 \
+	 $(ADA_INCLUDES) $<
 
 # force debugging information and no optimization on s-memory.o so that it 
 # is always possible to set breakpoint on __gnat_malloc and __gnat_free
@@ -2505,10 +2504,12 @@ s-stalib.o  : s-stalib.adb s-stalib.ads
 # memtrack.adb, and used by the post-mortem analysis with gnatmem.
 
 s-memory.o  : s-memory.adb s-memory.ads memtrack.o
-	$(CC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O0 $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O0 \
+	 $(ADA_INCLUDES) $<
 
 memtrack.o  : memtrack.adb s-memory.ads
-	$(CC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O0 $(ADA_INCLUDES) $<
+	$(ADAC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O0 \
+	 $(ADA_INCLUDES) $<
 
 # Need to keep the frame pointer in this file to pop the stack properly on
 # some targets.
@@ -2599,7 +2600,7 @@ stamp-tool_src_dir:
 	touch stamp-tool_src_dir
 
 mlib-tgt.o : stamp-tool_src_dir
-	$(CC) -c -Itools $(ALL_ADAFLAGS) $(ADA_INCLUDES) tools/mlib-tgt.adb
+	$(ADAC) -c -Itools $(ALL_ADAFLAGS) $(ADA_INCLUDES) tools/mlib-tgt.adb
 
 # GNAT DEPENDENCIES
 # regular dependencies

Re: Ada files now checked in

[dewar]

but the "Just Work" can still be achieved without needing a prebuilt binary
of the driver as far as I can see (though I am not an expert in the make
file intricacies :-)

Re: Ada files now checked in

[dewar]

<<I think you need to provide a driver binary as well (there does seem
to be one in gnat-3.13p-i686-pc-linux-gnu-bin.tar.gz), and the
Makefiles need to understand that "gcc" may not be able to compile
Ada.  (Yes, I am willing to help with this, time permitting.)
>>

But why would there be any difficulty in building this driver as part of
the build procedure, it does not require an Ada compiler, so I see no
reason to have a precompiled binary here, but perhaps I am missing
something.

Re: Ada files now checked in

[Geert Bosch]

On Thu, 4 Oct 2001 dewar@gnat.com wrote:
  But why would there be any difficulty in building this driver as part of
  the build procedure, it does not require an Ada compiler, so I see no
  reason to have a precompiled binary here, but perhaps I am missing
  something.
  
This would indeed be best, although we don't have support for doing this in
the Makefile yet. What we usually do in such cases is to first build/install
a recent GCC with just the C front end (but drivers for all languages), and
then use that as a base to build GNAT.

  -Geert

Re: Ada files now checked in

[Richard Kenner]

    > Note that you only need the gnat1 and gnatbind binaries.

    People keep saying this but I don't think it's true.  You cannot
    simply drop gnat1 into /usr/lib/gcc-lib/TARGET/VERSION; the driver
    won't have the specs it needs to run it.  

Correct, but you can build one of those since everything is written in C.

    Also, even if it did work, a normal user couldn't do that, since they
    do not have write privileges to that directory.

True, but the way you do it is build everything but Ada, install it
where you do have privileges (aftr all, if you can't put it anywhere,
why are you building it?), then put gnat1 and gnatbind there, build a
new driver, and continue.

Yes, this is not trivial, but it also isn't that hard.

Re: Ada files now checked in

[Zack Weinberg]

On Thu, Oct 04, 2001 at 12:29:54PM -0400, Richard Kenner wrote:
...
> True, but the way you do it is build everything but Ada, install it
> where you do have privileges (aftr all, if you can't put it anywhere,
> why are you building it?), then put gnat1 and gnatbind there, build a
> new driver, and continue.
> 
> Yes, this is not trivial, but it also isn't that hard.

Oh, I see now.  You're coming at this from the perspective that manual
intervention in the middle of the build (yes, it could be automated)
is acceptable.  I'm taking the position that we want "make bootstrap"
from the top level to Just Work provided appropriate tools are
available in the user's PATH.  This is what users of the public tree
expect, and what will be required if you want Ada to be included in
the normal testing cycle for language-independent changes.  Given the
large number of bugs that seem to have test cases only in Ada, I think
that is a desirable goal.

zw

Re: Ada files now checked in

[Geert Bosch]

On Thu, 4 Oct 2001, Zack Weinberg wrote:
  Oh, I see now.  You're coming at this from the perspective that manual
  intervention in the middle of the build (yes, it could be automated)
  is acceptable.  I'm taking the position that we want "make bootstrap"
  from the top level to Just Work provided appropriate tools are
  available in the user's PATH.  This is what users of the public tree
  expect, and what will be required if you want Ada to be included in
  the normal testing cycle for language-independent changes.  Given the
  large number of bugs that seem to have test cases only in Ada, I think
  that is a desirable goal.
  
Agreed, as soon as dust settles down a bit this would be something to
improve. Fortunately, GCC 3.1 is still a bit away, so we have time to
do this.

Also note, that we probably could generate binder files (the ones that
call all initialization procedures in the right order etc.) and provide
these as part of full releases, so just the "gnat1" executable is needed.

  -Geert

Re: Ada files now checked in

[dewar]

<<The 4 tools needed to generate these files are written in Ada, each
one has only one source file, and they compile in under a second on my
low end PC). If there are no objection, I'll propose a patch to add
their automatic generation in the Makefile, and they will be generated
in the build directory (by using the build compiler like many other
source-generating tools in the GCC build process). (2000 Paris time
since I need to go to work now :).
>>

I agree it is a good idea to add this patch

Re: Ada files now checked in

[dewar]

<<[I'm not that familiar with Ada, and as a low-level sort of person I
tend to think it ought to be possible to write even complex programs
in a language that completely bypass the vendor-provided runtime.  This
may be Not The Way These Things Are Done in Ada.]
>>

Indeed this is Not The Way These Things Are Done in Ada :-)

To be fair, the compiler does minimize the use of runtime routines, but
it still makes use of many of them, including the complete exception
handling apparatus (which most definitely cannot be replaced by
"direct use of the C runtime libraries". Other examples are secondary
stack handling for functions returning variable length objects (certainly
not something C is used to), the various wide character handling routines,
System.Storage_Elements, enumeration image output. It's not a big list.

But the compiler itself also uses non-vanilla features. an example is
pragma Assert which is used all over the place, but is not part of
Standard Ada.

Re: Ada files now checked in

[dewar]

<<Why do you have this policy?  It seems liable to cause nothing but
trouble.  I'm even a bit surprised it should be necessary given that
there don't seem to be much in the way of language extensions in GNAT;
I would think you could write conforming Ada95 and have no trouble.
Or is the issue bugs in earlier revisions?
>>

GNAT is nowhere near vanilla Ada 95, it uses many pragmas and attributes
that are implemented by GNAT. A rewrite in vanilla Ada 95 would require
a huge amount of work. Sometimes we add new pragmas and attributes
specifically to help, e.g. with the runtime (an example is the critical
use of pragma Unsuppress in some library routines).

So far it has not caused trouble at all. What we do need is canonical
starting point gnat1 and gnatbind executables available for starting
the bootstrap, and we intend to provide these on the libre site.

Re: Ada files now checked in

[dewar]

<<I know.  I was against requiring GNU make for it, but lost that fight.
There is a valid reason for not requiring GNU make for GCC itself (so you
can build GCC to build GNU make), but no such problem with Ada.
>>

One of the reasons for using GNU make, and using its features is that this
greatly eased the handling of the VMS version of GNAT.

Re: Ada files now checked in

[dewar]

<<Do ACT people have some time to spare to format/check/send me the part
of the internal test suite that is ok for public use (prefered way:
available by ftp on some server)?
>>

We will make these tests available incrementally as we get to formatting
and checking them properly.

Re: Ada files now checked in

[mike stump]

> Date: Tue, 2 Oct 01 21:50:05 EDT
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> To: mrs@windriver.com
> Cc: gcc@gcc.gnu.org

>     This breaks (can break) multi builds when one source tree is used by
>     two or more build systems.

> No, because, like c-parse.c, the contents of the files are a function only
> of sources and not of the target, host, or build machine.

This means that you have never seen a build fail.  I am sorry you
haven't had the opportunity.  For example (from memory), when a
Windows build generates a cp/parse.c file on Windows using Windows
linefeed conventions and that file winds up in the source tree, and
the UNIX build then sees the file is up to date, and doesn't rebuild
it, and uses that file, and fails because of the linefeed convention
the builds have in the past, broken.  Only a clean enough rebuild
fixes it.  Luckily, the Windows compiler doesn't get distressed at the
UNIX linefeed convention, so as long as the UNIX builds goes faster
than the Windows build, or runs before it, the builds work.

Now, you can tell me the problem has been since been fixed, but it
sounds more like you wanted to tell me the problem didn't exist.  That
is futile.

Further, I expected you to see the obvious race condition in even
generating the file, even if they are otherwise identical.  In one
build, you write cp/parse.c (and if not that file, at least one of the
other files), in the other build, you open it, truncate it, write half
of it, and then back in the first build, you read and compile that
file, viola, you die.

You can tell me it doesn't exist, but this too is futile, it did
exist.  I have no reason to believe that the problem has been fixed.
I'm sure these sorts of race conditions exist still.  A quick audit
shows that the cp/parse.[ch] race problems seem to be virtually
eliminated, this is good.  But, if you look closely, and actually
audit for a race condition, you will see that even now, as good as the
Makefile is, there is still a race condition present.  It can be
eliminated with just a little bit more work.  To me, the race
condition is obvious.

To work, you have to ensure that the generation of the files cannot
differ between all possible builds, or that should it differ, that
those differences are not material, and that the generation has no
race conditions.

We cannot hope to make the software better, if we cannot understand
its shortcomings.

Re: Ada files now checked in

[Richard Kenner]

    This breaks (can break) multi builds when one source tree is used by
    two or more build systems.

No, because, like c-parse.c, the contents of the files are a function only
of sources and not of the target, host, or build machine.

Re: Ada files now checked in

[mike stump]

> Date: Tue, 2 Oct 01 17:29:46 EDT
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> To: guerby@acm.org
> Cc: gcc@gcc.gnu.org

>     I noticed these two files are generated in the original source
>     directory, I believe they should be generated in the build directory
>     since I assume this is standard build policy not to touch the original
>     source directory (I build in a clean directory separate from the CVS
>     sources as adviced by the GCC build instructions).

> I'd argue they should be in the source directory just like c-parse.c is
> in the original source directory and the reason is that the tools to build
> them may not be accessable and so these are checked in files.

This breaks (can break) multi builds when one source tree is used by
two or more build systems.

:-(

When it falls over around here, we just say, oh well, please just try
an incremental rebuild.  Would be nice, if it just worked.

My other favorite, is ranlib during install:

rm bla.a
ar ... bla.a ...
ranlib bla.a

This also fails for mostly the same reason, though, this fails because
of the sharing of install tree and not the source tree.  If each
operation were reasonably build/host independent and reasonably
atomic, the issue would go away.

Re: Ada files now checked in

[Richard Kenner]

    bootstrap complete, but comparison failures. make gnatlib_and_tools
    dies on a bug box talking about set_mem_alias_set, I assume this is in
    Richard Kenner's court given recent traffic on the subject :).

Hmm... It doesn't do that on Alpha and when I try that file on i386
cross-compiler, I get an unrecognized insn, which appears to be
another breakage.

Maybe best to let things stabilize ...

Re: Ada files now checked in

[Richard Kenner]

    I noticed these two files are generated in the original source
    directory, I believe they should be generated in the build directory
    since I assume this is standard build policy not to touch the original
    source directory (I build in a clean directory separate from the CVS
    sources as adviced by the GCC build instructions).

I'd argue they should be in the source directory just like c-parse.c is
in the original source directory and the reason is that the tools to build
them may not be accessable and so these are checked in files.

Re: Ada files now checked in

[Laurent Guerby]

Now that there is no SPITBOL in the way, may be we should add stuff
into the Makefile to build the 4 SPITBOL-in-Ada tools needed by the
build process. The only requirement is to have a recent GNAT
installed, but this is not a new requirement :).

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada files now checked in

[Laurent Guerby]

stage2 suceeded, stage3 running. Last thing before I go to bed, on the
Ada part of the front-end there are only three warnings generated,
they look valid and could be easily silenced:

stage1/xgcc -Bstage1/ -B/home/guerby/work/gcc/install/i686-pc-linux-gnu/bin/ -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic   -gnatpg -gnata -I- -I. -I../../../gcc/gcc/ada ../../../gcc/gcc/ada/checks.adb
../../../gcc/gcc/ada/checks.adb: In function `checks__determine_range':
../../../gcc/gcc/ada/checks.adb:1882: warning: `hbound' might be used uninitialized in this function

stage1/xgcc -Bstage1/ -B/home/guerby/work/gcc/install/i686-pc-linux-gnu/bin/ -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic   -gnatpg -gnata -I- -I. -I../../../gcc/gcc/ada ../../../gcc/gcc/ada/layout.adb
../../../gcc/gcc/ada/layout.adb: In function `layout__get_max_size':
../../../gcc/gcc/ada/layout.adb:594: warning: `snod' might be used uninitialized in this function
../../../gcc/gcc/ada/layout.adb: In function `layout__layout_array_type':
../../../gcc/gcc/ada/layout.adb:855: warning: `snod' might be used uninitialized in this function

See you tomorrow.

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada files now checked in

[Laurent Guerby]

bootstrap complete, but comparison failures. make gnatlib_and_tools
dies on a bug box talking about set_mem_alias_set, I assume this is in
Richard Kenner's court given recent traffic on the subject :).

-- 
Laurent Guerby <guerby@acm.org>

ada/ada.o differs
ada/ali-util.o differs
ada/ali.o differs
ada/alloc.o differs
ada/atree.o differs
ada/back_end.o differs
ada/bcheck.o differs
ada/binde.o differs
ada/binderr.o differs
ada/bindgen.o differs
ada/bindusg.o differs
ada/butil.o differs
ada/casing.o differs
ada/checks.o differs
ada/comperr.o differs
ada/csets.o differs
ada/cstand.o differs
ada/debug.o differs
ada/debug_a.o differs
ada/einfo.o differs
ada/elists.o differs
ada/errout.o differs
ada/eval_fat.o differs
ada/exp_aggr.o differs
ada/exp_attr.o differs
ada/exp_ch11.o differs
ada/exp_ch12.o differs
ada/exp_ch13.o differs
ada/exp_ch2.o differs
ada/exp_ch3.o differs
ada/exp_ch4.o differs
ada/exp_ch5.o differs
ada/exp_ch6.o differs
ada/exp_ch7.o differs
ada/exp_ch8.o differs
ada/exp_ch9.o differs
ada/exp_code.o differs
ada/exp_dbug.o differs
ada/exp_disp.o differs
ada/exp_dist.o differs
ada/exp_fixd.o differs
ada/exp_imgv.o differs
ada/exp_intr.o differs
ada/exp_pakd.o differs
ada/exp_prag.o differs
ada/exp_smem.o differs
ada/exp_strm.o differs
ada/exp_tss.o differs
ada/exp_util.o differs
ada/exp_vfpt.o differs
ada/expander.o differs
ada/fname-uf.o differs
ada/fname.o differs
ada/freeze.o differs
ada/frontend.o differs
ada/g-hesora.o differs
ada/g-htable.o differs
ada/g-os_lib.o differs
ada/g-speche.o differs
ada/get_targ.o differs
ada/gnat.o differs
ada/gnat1drv.o differs
ada/gnatbind.o differs
ada/gnatvsn.o differs
ada/hlo.o differs
ada/hostparm.o differs
ada/impunit.o differs
ada/inline.o differs
ada/interfac.o differs
ada/itypes.o differs
ada/krunch.o differs
ada/layout.o differs
ada/lib-load.o differs
ada/lib-util.o differs
ada/lib-writ.o differs
ada/lib-xref.o differs
ada/lib.o differs
ada/live.o differs
ada/memtrack.o differs
ada/namet.o differs
ada/nlists.o differs
ada/nmake.o differs
ada/opt.o differs
ada/osint.o differs
ada/output.o differs
ada/par.o differs
ada/repinfo.o differs
ada/restrict.o differs
ada/rident.o differs
ada/rtsfind.o differs
ada/s-assert.o differs
ada/s-except.o differs
ada/s-exctab.o differs
ada/s-imgenu.o differs
ada/s-mastop.o differs
ada/s-memory.o differs
ada/s-parame.o differs
ada/s-secsta.o differs
ada/s-soflin.o differs
ada/s-sopco3.o differs
ada/s-sopco4.o differs
ada/s-sopco5.o differs
ada/s-stache.o differs
ada/s-stalib.o differs
ada/s-stoele.o differs
ada/s-strops.o differs
ada/s-traceb.o differs
ada/s-unstyp.o differs
ada/s-wchcnv.o differs
ada/s-wchcon.o differs
ada/s-wchjis.o differs
ada/scans.o differs
ada/scn.o differs
ada/sdefault.o differs
ada/sem.o differs
ada/sem_aggr.o differs
ada/sem_attr.o differs
ada/sem_case.o differs
ada/sem_cat.o differs
ada/sem_ch10.o differs
ada/sem_ch11.o differs
ada/sem_ch12.o differs
ada/sem_ch13.o differs
ada/sem_ch2.o differs
ada/sem_ch3.o differs
ada/sem_ch4.o differs
ada/sem_ch5.o differs
ada/sem_ch6.o differs
ada/sem_ch7.o differs
ada/sem_ch8.o differs
ada/sem_ch9.o differs
ada/sem_disp.o differs
ada/sem_dist.o differs
ada/sem_elab.o differs
ada/sem_elim.o differs
ada/sem_eval.o differs
ada/sem_intr.o differs
ada/sem_maps.o differs
ada/sem_mech.o differs
ada/sem_prag.o differs
ada/sem_res.o differs
ada/sem_smem.o differs
ada/sem_type.o differs
ada/sem_util.o differs
ada/sem_vfpt.o differs
ada/sem_warn.o differs
ada/sinfo-cn.o differs
ada/sinfo.o differs
ada/sinput-l.o differs
ada/sinput.o differs
ada/snames.o differs
ada/sprint.o differs
ada/stand.o differs
ada/stringt.o differs
ada/style.o differs
ada/stylesw.o differs
ada/switch.o differs
ada/system.o differs
ada/table.o differs
ada/targparm.o differs
ada/tbuild.o differs
ada/tree_gen.o differs
ada/tree_io.o differs
ada/treepr.o differs
ada/treeprs.o differs
ada/ttypef.o differs
ada/ttypes.o differs
ada/types.o differs
ada/uintp.o differs
ada/uname.o differs
ada/urealp.o differs
ada/usage.o differs
ada/validsw.o differs
ada/widechar.o differs
make[1]: *** [compare] Error 1
make[1]: Leaving directory `/home/guerby/work/gcc/build/gcc'
make: *** [bootstrap] Error 2

../../xgcc -B../../ -c -g -O2  -gnatpg -I. -I/home/guerby/work/gcc/gcc/gcc/ada a-nllcef.ads
+===========================GNAT BUG DETECTED==============================+
| 5.00w (20010924) (i686-pc-linux-gnu) GCC error:                          |
| Internal compiler error in set_mem_alias_set, at emit-rtl.c:1722         |
| Error detected at a-ngcefu.adb:601:52 [a-nllcef.ads:21:1]                |
| Please submit bug report by email to report@gnat.com.                    |
| Use a subject line meaningful to you and us to track the bug.            |
| (include your customer number #nnn in the subject line).                 |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
| (use plain ASCII or MIME attachment, or FTP to your customer directory). |
| See README.GNATPRO for full info on procedure for submitting bugs.       |
+==========================================================================+

Please include these source files with error report


compilation abandoned
make[2]: *** [a-nllcef.o] Error 1
make[2]: Leaving directory `/home/guerby/work/gcc/build/gcc/ada/rts'

Re: Ada files now checked in

[Joseph S. Myers]

On Wed, 3 Oct 2001, Laurent Guerby wrote:

> +===========================GNAT BUG DETECTED==============================+
> | 5.00w (20010924) (i686-pc-linux-gnu) GCC error:                          |
> | Internal compiler error in set_mem_alias_set, at emit-rtl.c:1722         |
> | Error detected at a-ngcefu.adb:601:52 [a-nllcef.ads:21:1]                |
> | Please submit bug report by email to report@gnat.com.                    |
> | Use a subject line meaningful to you and us to track the bug.            |
> | (include your customer number #nnn in the subject line).                 |
> | Include the entire contents of this bug box in the report.               |
> | Include the exact gcc or gnatmake command that you entered.              |
> | Also include sources listed below in gnatchop format                     |
> | (concatenated together with no headers between files).                   |
> | (use plain ASCII or MIME attachment, or FTP to your customer directory). |
> | See README.GNATPRO for full info on procedure for submitting bugs.       |
> +==========================================================================+

As previously discussed (e.g.,
<URL: http://gcc.gnu.org/ml/gcc/2001-05/msg01358.html >), Ada should act
like a part of standard GCC and bug reports should be directed to the
public GCC GNATS database, not to a company internal system.  I have
therefore added a GNATS category "ada" to the GCC GNATS database (on the
assumption that, at least initially, there is no need for a finer
classification of Ada-related bug reports into front end / library / tools
/ ..., but that Ada does merit its own category).  If bug reports in this
category should go to report@gnat.com, *in addition* to the public GCC
database and mailing lists, then GNATS can be set up to send them there
(similarly to how Java bug reports go to java-prs as well as gcc-bugs and
gcc-prs) - as long as that address doesn't have an autoresponder set up in
a way that would confuse GNATS or cause mail loops.

I will attend to updating gccbug.in and gnats.html for the new category,
but one of the Ada maintainers should deal with making that front end give
bug reporting instructions more appropriate to a free software project
developed in a bazaar fashion (as GCC is, whether or not you expect much
public contribution to the Ada parts of GCC) than the above instructions
for customers with support contracts.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Geert Bosch]

On Wed, 3 Oct 2001, Joseph S. Myers wrote:
  I will attend to updating gccbug.in and gnats.html for the new category,
  but one of the Ada maintainers should deal with making that front end give
  bug reporting instructions more appropriate to a free software project
  developed in a bazaar fashion (as GCC is, whether or not you expect much
  public contribution to the Ada parts of GCC) than the above instructions
  for customers with support contracts.

Yes, this is high on my list of things to do.

  -Geert

Re: Ada files now checked in

[Florian Weimer]

Laurent Guerby <guerby@acm.org> writes:

> ada/ada.o differs
> ada/ali-util.o differs

I've examined a couple of these files, and it seems the differences
occur only in the debugging information, code and data are the same.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: Ada files now checked in

[Joseph S. Myers]

On Tue, 2 Oct 2001, Richard Kenner wrote:

>     I noticed these two files are generated in the original source
>     directory, I believe they should be generated in the build directory
>     since I assume this is standard build policy not to touch the original
>     source directory (I build in a clean directory separate from the CVS
>     sources as adviced by the GCC build instructions).
> 
> I'd argue they should be in the source directory just like c-parse.c is
> in the original source directory and the reason is that the tools to build
> them may not be accessable and so these are checked in files.

The rules for generated files *ought* to be (this may change if / when
maintainer-mode is more widely used in GCC):

* Generated files are in CVS iff they are needed to run configure and
build from a CVS checkout, given maintainer tools (Bison, gettext, perl,
...) already installed.  They might also be in CVS if precise tool
versions are required to build them.  (This should be the same as the rule
in the GNU Coding Standards for what gets deleted in maintainer-clean.)

* contrib/gcc_update touches all generated files in CVS as necessary to
ensure that a build does not modify any file from CVS unless the sources
for that generated file have been changed.

* Generated files not in CVS go in the source directory iff we don't
require people building GCC release distributions to have the necessary
tools to generate them installed.  For example, people building releases
don't need Bison, but those building snapshots or CVS do.

Once we define - presumably by updates to doc/install.texi - what tools
are required to build the Ada front end in each case, from CVS and from
releases, this will lead to a conclusion as to what files should go in the
source directory.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Laurent Guerby]

> The rules for generated files *ought* to be (this may change if / when
> maintainer-mode is more widely used in GCC):
>
> * Generated files are in CVS iff they are needed to run configure and
> build from a CVS checkout, given maintainer tools (Bison, gettext, perl,
> ...) already installed.  They might also be in CVS if precise tool
> versions are required to build them.  (This should be the same as the rule
> in the GNU Coding Standards for what gets deleted in maintainer-clean.)

The two files do not match this criteria.

> * contrib/gcc_update touches all generated files in CVS as necessary to
> ensure that a build does not modify any file from CVS unless the sources
> for that generated file have been changed.
> 
> * Generated files not in CVS go in the source directory iff we don't
> require people building GCC release distributions to have the necessary
> tools to generate them installed.  For example, people building releases
> don't need Bison, but those building snapshots or CVS do.

The 4 tools needed to generate these files are written in Ada, each
one has only one source file, and they compile in under a second on my
low end PC). If there are no objection, I'll propose a patch to add
their automatic generation in the Makefile, and they will be generated
in the build directory (by using the build compiler like many other
source-generating tools in the GCC build process). (2000 Paris time
since I need to go to work now :).

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada files now checked in

[Richard Kenner]

    I forgot to say I also removed all traces of files ending in .spt in
    ada/Makefile target dependencies, AFAIK they are not in CVS and not
    used anymore.

Yes, that should be done.  They are in ACT's CVS, but are indeed not used
any more (since it's hard to get Spitbol compilers nowadays), so I didn't
put them into the GCC CVS.

Re: Ada files now checked in

[Richard Kenner]

    ../attribs.o: In function `decl_attributes':
/home/guerby/work/gcc/build/gcc/../../gcc/gcc/attribs.c:265: undefined reference to `insert_default_attributes'

Right.  That's caused by a recent GCC change.  Add a dummy function of that
name into ada/misc.c.  This will come over in the first tree resynchronization.

Re: Ada files now checked in

[Laurent Guerby]

Thanks, I added

void
insert_default_attributes (decl)
     tree decl;
{
}

to ada/misc.c, with that stage1 finishes, the next problem looks
related to -Wno-long-long, I've removed it from the Makefile
(STRICT2_WARN) and the build is moving on.

-- 
Laurent Guerby <guerby@acm.org>

make[2]: Leaving directory `/home/guerby/work/gcc/build/gcc'
echo timestamp > stage1_copy
echo stage2_build > stage_last
make CC="stage1/xgcc -Bstage1/ -B/home/guerby/work/gcc/install/i686-pc-linux-gnu/bin/" \
	 STAGE_PREFIX=stage1/ \
	 HOST_CC="gcc" CFLAGS="-g -O2" LDFLAGS="" WARN_CFLAGS="\$(GCC_WARN_CFLAGS)" STRICT_WARN="-Wtraditional -pedantic -Wno-long-long" libdir=/home/guerby/work/gcc/install/lib LANGUAGES="c gcov ada" MAKEOVERRIDES= OUTPUT_OPTION="-o \$@"
make[2]: Entering directory `/home/guerby/work/gcc/build/gcc'
gcc -c  -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include ../../gcc/gcc/gengenrtl.c
cc1: Invalid option `-Wno-long-long'
/usr/include/bits/string2.h: In function `__stpcpy_small':
In file included from /usr/include/string.h:346,
                 from ../../gcc/gcc/system.h:121,
                 from ../../gcc/gcc/gengenrtl.c:23:
/usr/include/bits/string2.h:611: warning: pointer targets in return differ in signedness
make[2]: *** [gengenrtl.o] Error 1
make[2]: Leaving directory `/home/guerby/work/gcc/build/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/home/guerby/work/gcc/build/gcc'
make: *** [bootstrap] Error 2

Re: Ada files now checked in

[Richard Kenner]

    I tried to find a Makefile target for building xnmake but found none,
    may be some essential generated file is not included or up to date in
    CVS?

There isn't any.  As far as I know, it's done manually with gnatmake.

But the touches you did should work around that.

    ../../../gcc/gcc/ada/decl.c:298: `E_Component' undeclared (first use in this function)

einfo.h and sinfo.h are the new versions of a-einfo.h and a-sinfo.h.

Re: Ada files now checked in

[Laurent Guerby]

Ok, I did:

mkdir /some/where/tmp
cp xnmake.adb xeinfo.adb xsinfo.adb xtreeprs.adb /some/where/tmp
cd /some/where/tmp
gnatmake xnmake
gnatmake xeinfo 
gnatmake xsinfo
gnatmake xtreeprs
cp xnmake xeinfo xsinfo xtreeprs /some/where/in/path

Then it died a bit after, this one seems to be some kind of GCC/GNAT
problem.

(It looks like the CVS server is overloaded, I get on update:
Fatal error, aborting.
load average of 17 is too high
)

-- 
Laurent Guerby <guerby@acm.org>

gcc  -DIN_GCC    `echo -g  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional  |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'`   -o ../gnat1 b_gnat1.o adaint.o cstreams.o cio.o targtyps.o decl.o misc.o utils.o utils2.o trans.o cuintp.o argv.o raise.o init.o tracebak.o ada.o a-charac.o a-chlat1.o a-except.o s-memory.o s-traceb.o s-mastop.o s-except.o ali.o alloc.o atree.o butil.o casing.o checks.o comperr.o csets.o cstand.o debug.o debug_a.o einfo.o elists.o errout.o eval_fat.o exp_attr.o exp_ch11.o exp_ch12.o exp_ch13.o exp_ch2.o exp_ch3.o exp_ch4.o exp_ch5.o exp_ch6.o exp_ch7.o exp_ch8.o exp_ch9.o exp_code.o exp_dbug.o exp_disp.o exp_dist.o exp_fixd.o exp_aggr.o exp_imgv.o exp_intr.o exp_pakd.o exp_prag.o exp_smem.o exp_strm.o exp_tss.o exp_util.o exp_vfpt.o expander.o fname.o fname-uf.o freeze.o frontend.o gnat.o g-hesora.o g-htable.o g-os_lib.o g-speche.o get_targ.o gnatvsn.o hlo.o hostparm.o impunit.o interfac.o itypes.o inline.o krunch.o lib.o layout.o lib-load.o lib-util.o lib-xref.o lib-writ.o live.o namet.o nlists.o nmake.o opt.o osint.o output.o par.o repinfo.o restrict.o rident.o rtsfind.o s-assert.o s-parame.o s-stache.o s-stalib.o s-imgenu.o s-stoele.o s-soflin.o s-exctab.o s-secsta.o s-wchcnv.o s-wchcon.o s-wchjis.o s-unstyp.o scans.o scn.o sdefault.o sem.o sem_aggr.o sem_attr.o sem_cat.o sem_ch10.o sem_ch11.o sem_ch12.o sem_ch13.o sem_ch2.o sem_ch3.o sem_ch4.o sem_ch5.o sem_ch6.o sem_ch7.o sem_ch8.o sem_ch9.o sem_case.o sem_disp.o sem_dist.o sem_elab.o sem_elim.o sem_eval.o sem_intr.o sem_maps.o sem_mech.o sem_prag.o sem_res.o sem_smem.o sem_type.o sem_util.o sem_vfpt.o sem_warn.o sinfo-cn.o sinfo.o sinput.o sinput-l.o snames.o sprint.o stand.o stringt.o style.o switch.o stylesw.o validsw.o system.o table.o targparm.o tbuild.o tree_gen.o tree_io.o treepr.o treeprs.o ttypef.o ttypes.o types.o uintp.o uname.o urealp.o usage.o widechar.o back_end.o gnat1drv.o ../prefix.o ../main.o ../attribs.o ../libbackend.a  ../../libiberty/libiberty.a 
../attribs.o: In function `decl_attributes':
/home/guerby/work/gcc/build/gcc/../../gcc/gcc/attribs.c:265: undefined reference to `insert_default_attributes'
make[3]: *** [../gnat1] Error 1
make[3]: Leaving directory `/home/guerby/work/gcc/build/gcc/ada'
make[2]: *** [gnat1] Error 2
make[2]: Leaving directory `/home/guerby/work/gcc/build/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/home/guerby/work/gcc/build/gcc'
make: *** [bootstrap] Error 2

Re: Ada files now checked in

[Laurent Guerby]

After poking around a bit, I found a cp/decl.c with code for
insert_default_attributes. I did configure --enable-languages=c,ada
(to avoid a too long bootstrap on my poor P2 350MHz :), is C++
required to build GNAT?

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada files now checked in

[Laurent Guerby]

> mkdir /some/where/tmp
> cp xnmake.adb xeinfo.adb xsinfo.adb xtreeprs.adb /some/where/tmp
> cd /some/where/tmp
> gnatmake xnmake
> gnatmake xeinfo 
> gnatmake xsinfo
> gnatmake xtreeprs
> cp xnmake xeinfo xsinfo xtreeprs /some/where/in/path

I forgot to say I also removed all traces of files ending in .spt in
ada/Makefile target dependencies, AFAIK they are not in CVS and not
used anymore.

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada files now checked in

[Laurent Guerby]

> einfo.h and sinfo.h are the new versions of a-einfo.h and a-sinfo.h.

I noticed these two files are generated in the original source
directory, I believe they should be generated in the build directory
since I assume this is standard build policy not to touch the original
source directory (I build in a clean directory separate from the CVS
sources as adviced by the GCC build instructions).

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada files now checked in

[Richard Kenner]

    I observe that the Makefile requires GNU make, which is contrary to
    current policy (though I am in favor of changing that policy).

I know.  I was against requiring GNU make for it, but lost that fight.
There is a valid reason for not requiring GNU make for GCC itself (so you
can build GCC to build GNU make), but no such problem with Ada.

    Yes, the packaged gnat is 2.8.1-based.  I would like to be able to
    build starting from nothing but what is packaged, if at all possible.

It's really not, unfortunately, since the GNAT sources are free to use
features added to the compiler in the last version.

    (Am I correct in thinking that -pedantic, -Wtraditional, and
    -Wno-long-long are simply ignored by the current Ada front end?)

Correct.  In fact, all -W is ignored.

Re: Ada files now checked in

[Joseph S. Myers]

On Tue, 2 Oct 2001, Richard Kenner wrote:

>     Yes, the packaged gnat is 2.8.1-based.  I would like to be able to
>     build starting from nothing but what is packaged, if at all possible.
> 
> It's really not, unfortunately, since the GNAT sources are free to use
> features added to the compiler in the last version.

Then the configure test in gcc/configure.in for whether GNAT is installed
needs to be more precise - it should check whether the version of GNAT
currently installed is sufficiently recent, so that Ada is not built when
the installed GNAT is too old.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Zack Weinberg]

On Tue, Oct 02, 2001 at 03:44:36PM -0400, Richard Kenner wrote:
> 
>     Yes, the packaged gnat is 2.8.1-based.  I would like to be able to
>     build starting from nothing but what is packaged, if at all possible.
> 
> It's really not, unfortunately, since the GNAT sources are free to use
> features added to the compiler in the last version.

Why do you have this policy?  It seems liable to cause nothing but
trouble.  I'm even a bit surprised it should be necessary given that
there don't seem to be much in the way of language extensions in GNAT;
I would think you could write conforming Ada95 and have no trouble.
Or is the issue bugs in earlier revisions?

>     (Am I correct in thinking that -pedantic, -Wtraditional, and
>     -Wno-long-long are simply ignored by the current Ada front end?)
> 
> Correct.  In fact, all -W is ignored.

... and there's a host of -gnatfoo options which largely duplicate
existing -f and -W options.  Ick.

However, that makes *that* particular problem trivial to solve; since
they will be ignored anyway, simply leave $(WARN_CFLAGS) out of
$(ALL_ADAFLAGS).  Well, it's a bit more complicated due to the maze of
variables in ada/Makefile.in.

zw

Re: Ada files now checked in

[Geert Bosch]

On Tue, 2 Oct 2001, Zack Weinberg wrote:
  Why do you have this policy?  It seems liable to cause nothing but
  trouble.  I'm even a bit surprised it should be necessary given that
  there don't seem to be much in the way of language extensions in GNAT;
  I would think you could write conforming Ada95 and have no trouble.
  Or is the issue bugs in earlier revisions?

There are various reasons for this. Most of the issues are in the run time,
where in the end one must be sure that the implementation of high-level
features does not itself rely on those features. In some places, we have
decided to add GNAT-specific attributes (which is allowed by the Ada standard)
that we mostly use for implementing the Ada run time using Ada. For examples
of this, see the system.ads file.
  
For these and other reasons it is impractical to implement the compiler
and run time in 100% standard Ada. We always have guaranteed that every 
version of the compiler can be built with the previous released public 
version, and in practice this policy never has been a problem.

Regards,
  Geert

Re: Ada files now checked in

[Zack Weinberg]

On Tue, Oct 02, 2001 at 10:46:48PM -0400, Geert Bosch wrote:
> On Tue, 2 Oct 2001, Zack Weinberg wrote:
>   Why do you have this policy?  It seems liable to cause nothing but
>   trouble.  I'm even a bit surprised it should be necessary given that
>   there don't seem to be much in the way of language extensions in GNAT;
>   I would think you could write conforming Ada95 and have no trouble.
>   Or is the issue bugs in earlier revisions?
> 
> There are various reasons for this. Most of the issues are in the run time,
> where in the end one must be sure that the implementation of high-level
> features does not itself rely on those features. In some places, we have
> decided to add GNAT-specific attributes (which is allowed by the Ada standard)
> that we mostly use for implementing the Ada run time using Ada. For examples
> of this, see the system.ads file.

Hmm, there's a distinction to be drawn between the compiler and the
runtime.  It is reasonable for the runtime to have this sort of deep
dependency.  The compiler itself really shouldn't need to, IMO.

You're presumably lumping them together because the compiler needs its
own runtime.  We could - we might even want to - minimize the number
of things that the compiler uses from the runtime, replacing them for
instance with direct use of the C runtime libraries.  That'd be a
tradeoff between work done to create the stubs, work done in the
future to maintain them, and saved effort on the part of people who
"just want to build the compiler."  I'm just speculating, here; I'm
not necessarily advocating any such thing be done.

[I'm not that familiar with Ada, and as a low-level sort of person I
tend to think it ought to be possible to write even complex programs
in a language that completely bypass the vendor-provided runtime.  This
may be Not The Way These Things Are Done in Ada.]

Relatedly, I've been wondering if it makes sense to move out the
things built by "make gnatlib_and_tools" to a libada directory at top
level, as is done for the other languages.

> For these and other reasons it is impractical to implement the compiler
> and run time in 100% standard Ada. We always have guaranteed that every 
> version of the compiler can be built with the previous released public 
> version, and in practice this policy never has been a problem.

Well, define "previous released public version".  The one I can get at
easily is 3.13p-8 which seems to have been based on gcc 2.8.1.  Is
that the appropriate version to use to build what's been checked into
GCC CVS?

zw

Re: Ada files now checked in

[Joseph S. Myers]

On Tue, 2 Oct 2001, Zack Weinberg wrote:

> Relatedly, I've been wondering if it makes sense to move out the
> things built by "make gnatlib_and_tools" to a libada directory at top
> level, as is done for the other languages.

Clearly, "make gnatlib_and_tools" ought to be part of a "make bootstrap"  
at toplevel, wherever the files are located, to avoid complicating the
build process.  Similarly, all these libraries and tools should be
installed by "make install".

How does the present system for the Ada libraries handle multilibs?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Geert Bosch]

On Tue, 2 Oct 2001, Zack Weinberg wrote:
  Well, define "previous released public version".  The one I can get at
  easily is 3.13p-8 which seems to have been based on gcc 2.8.1.  Is
  that the appropriate version to use to build what's been checked into
  GCC CVS?
  
If that compiler is similar enough to the 3.13p that can be found at
ftp://cs.nyu.edu/pub/gnat , it should work fine. Note that you only need
the gnat1 and gnatbind binaries.
  
   -Geert

Re: Ada files now checked in

[Zack Weinberg]

On Wed, Oct 03, 2001 at 07:38:39AM -0400, Geert Bosch wrote:

> Note that you only need the gnat1 and gnatbind binaries.

People keep saying this but I don't think it's true.  You cannot
simply drop gnat1 into /usr/lib/gcc-lib/TARGET/VERSION; the driver
won't have the specs it needs to run it.  Also, even if it did work, a
normal user couldn't do that, since they do not have write privileges
to that directory.

I think you need to provide a driver binary as well (there does seem
to be one in gnat-3.13p-i686-pc-linux-gnu-bin.tar.gz), and the
Makefiles need to understand that "gcc" may not be able to compile
Ada.  (Yes, I am willing to help with this, time permitting.)

zw

Re: Ada files now checked in

[dewar]

<<Is there a canonical version of GNAT for Red Hat Linux 7 that should
be used?
>>

We will be preparing canonical binary versions of gnat1 and gnatbind
available on the libre site at www.act-europe.fr precisely for the
purpose of starting bootstraps.

Re: Ada files now checked in

[Richard Kenner]

    2. -Wno-long-long is not acceptable to gnat1.

You may have an old version.  Replace it with the one you built.
I'd forgotten this was added relatively recently.

Re: Ada files now checked in

[dewar]

<<   As a high-priority matter, both contribute.html and cvswrite.html need
   to be updated as well to make it clear whether and when an Ada
   bootstrap is required for changes outside of the Ada front end and
   libraries.
>>

I discussed this with Mark and we agreed that we would not require this
for now. Later we may reconsider.

Robert Dewar
FSF maintainer for GNAT

Re: Ada files now checked in

[Richard Kenner]

    If gnat will build with 'configure' and 'make bootstrap', then the
    tester is testing it now.

It will only if GNAT is already on the tester's system.

Re: Ada files now checked in

[Geoff Keating]

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

>     If gnat will build with 'configure' and 'make bootstrap', then the
>     tester is testing it now.
> 
> It will only if GNAT is already on the tester's system.

It doesn't seem to be.

Is there a canonical version of GNAT for Red Hat Linux 7 that should
be used?

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Ada files now checked in

[Florian Weimer]

Geoff Keating <geoffk@geoffk.org> writes:

> Is there a canonical version of GNAT for Red Hat Linux 7 that should
> be used?

I don't know yet if the GNAT version in the CVS can be bootstrapped
with the latest publicly available GNAT binaries (version 3.13p).

If this is the case, you can use Juergen Pfeifers RPM distribution
(but you have to temporarily rename 'gnatgcc' to 'gcc', or pass
apropriate flags to make), or you can use the ACT binary distribution,
available at ftp://ftp.cs.nyu.edu/pub/gnat/ (IIRC, a HTTP mirror is at
http://de.gnuada.org/gnat/ ).

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: Ada files now checked in

[Richard Kenner]

    As a high-priority matter, both contribute.html and cvswrite.html need
    to be updated as well to make it clear whether and when an Ada
    bootstrap is required for changes outside of the Ada front end and
    libraries.  

I'd say it should *not* be required.  It's too much of a burden on
developers to have to build it, at least for a while.

    Will the automated regression tester now start testing Ada?  (Even
    before an Ada testsuite is available in CVS, simply testing that it
    bootstraps should be a useful addition to the regression tests,
    especially if many developers don't immediately start building Ada,
    but I don't know how much this would add to bootstrap times.)

It won't add that much time.  I'd say it probably should, but that
fixing such failures not be mandatory for a patch.  But it would be
good to at least *know* that it's broken.  Building the Ada library
(make gnatlib_and_tools) is also a good test.

Re: Ada files now checked in

[Joseph S. Myers]

On Tue, 2 Oct 2001, Richard Kenner wrote:

>     As a high-priority matter, both contribute.html and cvswrite.html need
>     to be updated as well to make it clear whether and when an Ada
>     bootstrap is required for changes outside of the Ada front end and
>     libraries.  
> 
> I'd say it should *not* be required.  It's too much of a burden on
> developers to have to build it, at least for a while.

I think that makes sense for now - but once there's an official FSF GCC
release (3.1) out that supports Ada that can be used as a bootstrap
compiler, this should be considered again.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Richard Kenner]

    1. On this system, the driver that understands Ada is called "gnatgcc".

The Makefile assumes that the "gcc" driver supports Ada.

    2. -Wno-long-long is not acceptable to gnat1.

Hmm.  I don't understand why I don't run into that.

    3. The complaint about a missing unchconv.ads does not go away if I
       correct (1) and (2); there is something wrong with the Makefile.

Do you have an unchconv.ads?  There was one that was checked in.

Re: Ada files now checked in

[Zack Weinberg]

On Tue, Oct 02, 2001 at 01:09:16PM -0400, Richard Kenner wrote:
>     1. On this system, the driver that understands Ada is called "gnatgcc".
> 
> The Makefile assumes that the "gcc" driver supports Ada.

Right.  This is more in the nature of a heads-up that it is difficult
to build starting from the packaged gcc and gnat on probably a lot of
systems.

I observe that the Makefile requires GNU make, which is contrary to
current policy (though I am in favor of changing that policy).

>     2. -Wno-long-long is not acceptable to gnat1.
> 
> Hmm.  I don't understand why I don't run into that.
...
> You may have an old version.  Replace it with the one you built.
> I'd forgotten this was added relatively recently.

Yes, the packaged gnat is 2.8.1-based.  I would like to be able to
build starting from nothing but what is packaged, if at all possible.

Shouldn't be hard to specialize things a bit so it works; I'll see
what can be done.  (Am I correct in thinking that -pedantic,
-Wtraditional, and -Wno-long-long are simply ignored by the current
Ada front end?)

>     3. The complaint about a missing unchconv.ads does not go away if I
>        correct (1) and (2); there is something wrong with the Makefile.
> 
> Do you have an unchconv.ads?  There was one that was checked in.

I must have run a checkout halfway through the import; I have one now.

zw

Re: Ada files now checked in

[Richard Kenner]

    Could you please add/submit a news item to/for our main web page?

    (The web pages are under CVS control, in the wwwdocs module.)

I don't know how to access that, but I'll try to get to it sometime

Re: Ada files now checked in

[Joseph S. Myers]

On Tue, 2 Oct 2001, Richard Kenner wrote:

>     Could you please add/submit a news item to/for our main web page?
> 
>     (The web pages are under CVS control, in the wwwdocs module.)
> 
> I don't know how to access that, but I'll try to get to it sometime

As a high-priority matter, both contribute.html and cvswrite.html need to
be updated as well to make it clear whether and when an Ada bootstrap is
required for changes outside of the Ada front end and libraries.  (That
is, the SC should decide this, but until it is decided it is unclear what
should be tested.  Similarly, it should be clarified when testing on
platforms that do not support all front ends or libraries (e.g., platforms
with no libgcj support) suffices.)

Will the automated regression tester now start testing Ada?  (Even before
an Ada testsuite is available in CVS, simply testing that it bootstraps
should be a useful addition to the regression tests, especially if many
developers don't immediately start building Ada, but I don't know how much
this would add to bootstrap times.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Geoff Keating]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> On Tue, 2 Oct 2001, Richard Kenner wrote:
> 
> >     Could you please add/submit a news item to/for our main web page?
> > 
> >     (The web pages are under CVS control, in the wwwdocs module.)
> > 
> > I don't know how to access that, but I'll try to get to it sometime
> 
> As a high-priority matter, both contribute.html and cvswrite.html need to
> be updated as well to make it clear whether and when an Ada bootstrap is
> required for changes outside of the Ada front end and libraries.  (That
> is, the SC should decide this, but until it is decided it is unclear what
> should be tested.  Similarly, it should be clarified when testing on
> platforms that do not support all front ends or libraries (e.g., platforms
> with no libgcj support) suffices.)
> 
> Will the automated regression tester now start testing Ada?  (Even before
> an Ada testsuite is available in CVS, simply testing that it bootstraps
> should be a useful addition to the regression tests, especially if many
> developers don't immediately start building Ada, but I don't know how much
> this would add to bootstrap times.)

If gnat will build with 'configure' and 'make bootstrap', then the
tester is testing it now.

It's somewhat a hypothetical situation at present, because the native
boostrap is broken; I'm looking at that right now.
-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Ada files now checked in

[dewar]

I will make sure we do a big serch and fix this.

Ada files now checked in

[Richard Kenner]

They are in the subdirectory "gcc/ada".  If you have GNAT already on your
machine, rerunning configure will up to build them.

Re: Ada files now checked in

[Gerald Pfeifer]

On Tue, 2 Oct 2001, Richard Kenner wrote:
> They are in the subdirectory "gcc/ada".  If you have GNAT already on
> your machine, rerunning configure will up to build them.

Could you please add/submit a news item to/for our main web page?

(The web pages are under CVS control, in the wwwdocs module.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Ada files now checked in

[Gerald Pfeifer]

I found that this code uses Linux instead of GNU/Linux in several
places; given GCC's status and role, this should be fixed.


adaint.c

  /* Dummy function to satisfy g-trasym.o.
   Currently Solaris sparc, HP/UX, IRIX, Linux, Tru64 & Windows provide a
   non-dummy version of this procedure in libaddr2line.a */

gmem.c

   NOTE: This capability is currently supported on the following targets:

   DEC Unix
   SGI Irix
   Linux x86
   Solaris (sparc and x86) (*)
   Windows 98/95/NT (x86)

cio.c

   /* Don't use macros on linux since they cause incompatible changes between
      glibc 2.0 and 2.1 */

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Ada files now checked in

[Geert Bosch]

On Tue, 2 Oct 2001, Gerald Pfeifer wrote:
  
  Could you please add/submit a news item to/for our main web page?

I'll prepare a patch for that.

  -Geert

Re: Ada files now checked in

[Zack Weinberg]

On Tue, Oct 02, 2001 at 11:16:38AM -0400, Richard Kenner wrote:
> They are in the subdirectory "gcc/ada".  If you have GNAT already on your
> machine, rerunning configure will up to build them.

There appear to be some problems.

make[2]: Entering directory `/home/zack/src/b/gcc_vanilla/gcc/ada'
gcc -c -g  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -gnatpg -gnata -I- -I. -I../../../../gcc_vanilla/gcc/ada ../../../../gcc_vanilla/gcc/ada/ada.ads
gcc: ../../../../gcc_vanilla/gcc/ada/ada.ads: Ada compiler not installed on this system
gcc -c -g  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -gnatpg -gnata -I- -I. -I../../../../gcc_vanilla/gcc/ada ../../../../gcc_vanilla/gcc/ada/a-charac.ads
gcc: ../../../../gcc_vanilla/gcc/ada/a-charac.ads: Ada compiler not installed on this system
gcc -c -g  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -gnatpg -gnata -I- -I. -I../../../../gcc_vanilla/gcc/ada ../../../../gcc_vanilla/gcc/ada/a-chlat1.ads
gcc: ../../../../gcc_vanilla/gcc/ada/a-chlat1.ads: Ada compiler not installed on this system
make[2]: *** No rule to make target `unchconv.ads', needed by `a-except.o'.  Stop.
make[2]: Leaving directory `/home/zack/src/b/gcc_vanilla/gcc/ada'
make[1]: *** [gnat1] Error 2
make[1]: Leaving directory `/home/zack/src/b/gcc_vanilla/gcc'
make: *** [stage1_build] Error 2

1. On this system, the driver that understands Ada is called "gnatgcc".
   I'm not sure why plain "gcc" doesn't treat this as an error.
2. -Wno-long-long is not acceptable to gnat1.
3. The complaint about a missing unchconv.ads does not go away if I
   correct (1) and (2); there is something wrong with the Makefile.

zw

Re: Ada files now checked in

[Laurent Guerby]

Great news!

Do ACT people have some time to spare to format/check/send me the part
of the internal test suite that is ok for public use (prefered way:
available by ftp on some server)?

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada files now checked in

[Laurent Guerby]

I did "touch treeprs.ads a-[es]info.h nmake.ad[bs]" (as documented in
the regular GNAT release tarballs, documentation not yet installed in
CVS I assume) to get over the first error but I got into the second
one.

This is on a RedHat 6.1 system, gcc is the one from GNAT 3.14a1 binary
customer release tarball.

I tried to find a Makefile target for building xnmake but found none,
may be some essential generated file is not included or up to date in
CVS?

-- 
Laurent Guerby <guerby@acm.org>

<first error>

make bootstrap
...
make -C ada "AR_FLAGS_FOR_TARGET=" "AR_CREATE_FOR_TARGET=` if [ -f /home/guerby/work/gcc/build/gcc/../binutils/ar ] ; then echo /home/guerby/work/gcc/build/gcc/../binutils/ar ; else if [ "i686-pc-linux-gnu" = "i686-pc-linux-gnu" ] ; then echo ar; else t='s,^,i686-pc-linux-gnu-,'; echo ar | sed -e $t ; fi; fi`  rc" "AR_EXTRACT_FOR_TARGET=` if [ -f /home/guerby/work/gcc/build/gcc/../binutils/ar ] ; then echo /home/guerby/work/gcc/build/gcc/../binutils/ar ; else if [ "i686-pc-linux-gnu" = "i686-pc-linux-gnu" ] ; then echo ar; else t='s,^,i686-pc-linux-gnu-,'; echo ar | sed -e $t ; fi; fi`  x" "AR_FOR_TARGET=` if [ -f /home/guerby/work/gcc/build/gcc/../binutils/ar ] ; then echo /home/guerby/work/gcc/build/gcc/../binutils/ar ; else if [ "i686-pc-linux-gnu" = "i686-pc-linux-gnu" ] ; then echo ar; else t='s,^,i686-pc-linux-gnu-,'; echo ar | sed -e $t ; fi; fi`" "BISON=bison" "BISONFLAGS=" "CFLAGS=-g  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional " "GCC_FOR_TARGET=./xgcc -B./ -B/home/guerby/work/gcc/install/i686-pc-linux-gnu/bin/ -isystem /home/guerby/work/gcc/install/i686-pc-linux-gnu/include" "LDFLAGS=" "FLEX=flex" "FLEXFLAGS=" "LN=ln" "LN_S=ln -s" "MAKEINFO=makeinfo " "MAKEINFOFLAGS=" "MAKEOVERRIDES=" "RANLIB_FOR_TARGET=` if [ -f /home/guerby/work/gcc/build/gcc/../binutils/ranlib ] ; then echo /home/guerby/work/gcc/build/gcc/../binutils/ranlib ; else if [ "i686-pc-linux-gnu" = "i686-pc-linux-gnu" ] ; then echo ranlib; else t='s,^,i686-pc-linux-gnu-,'; echo ranlib | sed -e $t ; fi; fi`" "RANLIB_TEST_FOR_TARGET=[ -f ` if [ -f /home/guerby/work/gcc/build/gcc/../binutils/ranlib ] ; then echo /home/guerby/work/gcc/build/gcc/../binutils/ranlib ; else if [ "i686-pc-linux-gnu" = "i686-pc-linux-gnu" ] ; then echo ranlib; else t='s,^,i686-pc-linux-gnu-,'; echo ranlib | sed -e $t ; fi; fi` ] || ( [ "i686-pc-linux-gnu" = "i686-pc-linux-gnu" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" "SHELL=/bin/sh" "STAGE_PREFIX=" "exeext=" "build_exeext=" "objext=.o" "exec_prefix=/home/guerby/work/g!
cc/install" "prefix=/home/guerby/work/gcc/install" "local_prefix=/usr/local" "gxx_include_dir=/home/guerby/work/gcc/install/lib/gcc-lib/i686-pc-linux-gnu/3.1/../../../..`echo /home/guerby/work/gcc/install | sed -e 's|^/home/guerby/work/gcc/install||' -e 's|/[^/]*|/..|g'`/include/g++-v3" "tooldir=/home/guerby/work/gcc/install/i686-pc-linux-gnu" "gcc_tooldir=/home/guerby/work/gcc/install/lib/gcc-lib/i686-pc-linux-gnu/3.1/../../../../i686-pc-linux-gnu" "bindir=/home/guerby/work/gcc/install/bin" "libsubdir=/home/guerby/work/gcc/install/lib/gcc-lib/i686-pc-linux-gnu/3.1" "datadir=/home/guerby/work/gcc/install/share" "localedir=/home/guerby/work/gcc/install/share/locale" "CC=gcc" "ADA_FOR_BUILD=" "ADA_INCLUDE_DIR=/home/guerby/work/gcc/install/lib/gcc-lib/i686-pc-linux-gnu/3.1/adainclude" "ADA_RTL_OBJ_DIR=/home/guerby/work/gcc/install/lib/gcc-lib/i686-pc-linux-gnu/3.1/adalib" "ADAFLAGS=-gnatpg -gnata" "ADA_FOR_TARGET=" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" \
	../gnat1
make[3]: Entering directory `/home/guerby/work/gcc/build/gcc/ada'
make[3]: *** No rule to make target `xnmake.spt', needed by `../../../gcc/gcc/ada/nmake.ads'.  Stop.
make[3]: Leaving directory `/home/guerby/work/gcc/build/gcc/ada'
make[2]: *** [gnat1] Error 2
make[2]: Leaving directory `/home/guerby/work/gcc/build/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/home/guerby/work/gcc/build/gcc'
make: *** [bootstrap] Error 2

<second error>

../../../gcc/gcc/ada/decl.c:298: `E_Component' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:299: `E_Label' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:299: `E_Constant' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:301: `Type_Kind__First' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:301: `Type_Kind__Last' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:312: warning: implicit declaration of function `Is_Statically_Allocated'
../../../gcc/gcc/ada/decl.c:317: warning: implicit declaration of function `Has_Gigi_Rep_Item'
../../../gcc/gcc/ada/decl.c:338: warning: implicit declaration of function `Expression'
../../../gcc/gcc/ada/decl.c:339: warning: implicit declaration of function `No_Initialization'
../../../gcc/gcc/ada/decl.c:351: warning: implicit declaration of function `Renamed_Object'
../../../gcc/gcc/ada/decl.c:368: `E_Exception' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:373: warning: implicit declaration of function `Is_VMS_Exception'
../../../gcc/gcc/ada/decl.c:379: warning: implicit declaration of function `Interface_Name'
../../../gcc/gcc/ada/decl.c:412: warning: implicit declaration of function `Base_Type'
../../../gcc/gcc/ada/decl.c:414: `E_Record_Subtype_With_Private' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:414: `E_Record_Type_With_Private' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:415: warning: implicit declaration of function `Original_Record_Component'
../../../gcc/gcc/ada/decl.c:432: warning: implicit declaration of function `Corresponding_Discriminant'
../../../gcc/gcc/ada/decl.c:433: warning: implicit declaration of function `Is_Tagged_Type'
../../../gcc/gcc/ada/decl.c:437: warning: implicit declaration of function `First_Discriminant'
../../../gcc/gcc/ada/decl.c:438: warning: implicit declaration of function `First_Girder_Discriminant'
../../../gcc/gcc/ada/decl.c:469: warning: implicit declaration of function `Is_Protected_Type'
../../../gcc/gcc/ada/decl.c:493: `E_Loop_Parameter' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:494: `E_Out_Parameter' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:495: `E_Variable' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:504: warning: implicit declaration of function `Is_True_Constant'
../../../gcc/gcc/ada/decl.c:506: `N_Object_Declaration' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:516: warning: implicit declaration of function `Renamed_Entity'
../../../gcc/gcc/ada/decl.c:523: warning: implicit declaration of function `Etype'
../../../gcc/gcc/ada/decl.c:559: warning: implicit declaration of function `Has_Biased_Representation'
../../../gcc/gcc/ada/decl.c:617: warning: implicit declaration of function `Is_Constr_Subt_For_UN_Aliased'
../../../gcc/gcc/ada/decl.c:618: warning: implicit declaration of function `Is_Array_Type'
../../../gcc/gcc/ada/decl.c:623: warning: implicit declaration of function `Known_Alignment'
../../../gcc/gcc/ada/decl.c:625: warning: implicit declaration of function `Alignment'
../../../gcc/gcc/ada/decl.c:638: warning: implicit declaration of function `Is_Atomic'
../../../gcc/gcc/ada/decl.c:677: warning: implicit declaration of function `Has_Atomic_Components'
../../../gcc/gcc/ada/decl.c:697: warning: implicit declaration of function `Is_Volatile'
../../../gcc/gcc/ada/decl.c:698: warning: implicit declaration of function `Is_Exported'
../../../gcc/gcc/ada/decl.c:770: `E_Class_Wide_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:777: warning: implicit declaration of function `Materialize_Entity'
../../../gcc/gcc/ada/decl.c:1041: warning: implicit declaration of function `Address_Taken'
../../../gcc/gcc/ada/decl.c:1042: warning: implicit declaration of function `Is_Aliased'
../../../gcc/gcc/ada/decl.c:1055: warning: implicit declaration of function `Has_Nested_Block_With_Handler'
../../../gcc/gcc/ada/decl.c:1063: warning: implicit declaration of function `Unknown_Alignment'
../../../gcc/gcc/ada/decl.c:1083: `E_Void' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1088: `E_Enumeration_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1092: warning: implicit declaration of function `First_Literal'
../../../gcc/gcc/ada/decl.c:1113: warning: implicit declaration of function `Is_Unsigned_Type'
../../../gcc/gcc/ada/decl.c:1122: warning: implicit declaration of function `Next_Literal'
../../../gcc/gcc/ada/decl.c:1124: warning: implicit declaration of function `Enumeration_Rep'
../../../gcc/gcc/ada/decl.c:1143: `E_Signed_Integer_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1144: `E_Ordinary_Fixed_Point_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1145: `E_Decimal_Fixed_Point_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1151: `E_Modular_Integer_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1159: warning: implicit declaration of function `Is_Packed_Array_Type'
../../../gcc/gcc/ada/decl.c:1160: warning: implicit declaration of function `RM_Size'
../../../gcc/gcc/ada/decl.c:1178: warning: implicit declaration of function `Modulus'
../../../gcc/gcc/ada/decl.c:1215: `E_Signed_Integer_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1216: `E_Enumeration_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1217: `E_Modular_Integer_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1218: `E_Ordinary_Fixed_Point_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1219: `E_Decimal_Fixed_Point_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1237: warning: implicit declaration of function `Ancestor_Subtype'
../../../gcc/gcc/ada/decl.c:1239: warning: implicit declaration of function `Type_Low_Bound'
../../../gcc/gcc/ada/decl.c:1240: warning: implicit declaration of function `Type_High_Bound'
../../../gcc/gcc/ada/decl.c:1312: `E_Floating_Point_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1315: warning: implicit declaration of function `Vax_Float'
../../../gcc/gcc/ada/decl.c:1320: warning: implicit declaration of function `Digits_Value'
../../../gcc/gcc/ada/decl.c:1331: `E_Floating_Point_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1398: `E_String_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1399: `E_Array_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1405: warning: implicit declaration of function `Number_Dimensions'
../../../gcc/gcc/ada/decl.c:1469: warning: implicit declaration of function `First_Index'
../../../gcc/gcc/ada/decl.c:1471: warning: implicit declaration of function `Implementation_Base_Type'
../../../gcc/gcc/ada/decl.c:1474: warning: implicit declaration of function `Next_Index'
../../../gcc/gcc/ada/decl.c:1541: warning: implicit declaration of function `Component_Type'
../../../gcc/gcc/ada/decl.c:1547: warning: implicit declaration of function `Component_Size'
../../../gcc/gcc/ada/decl.c:1549: warning: implicit declaration of function `Is_Bit_Packed_Array'
../../../gcc/gcc/ada/decl.c:1551: warning: implicit declaration of function `Has_Component_Size_Clause'
../../../gcc/gcc/ada/decl.c:1570: warning: implicit declaration of function `Has_Volatile_Components'
../../../gcc/gcc/ada/decl.c:1576: warning: implicit declaration of function `Unknown_Component_Size'
../../../gcc/gcc/ada/decl.c:1593: warning: implicit declaration of function `Has_Aliased_Components'
../../../gcc/gcc/ada/decl.c:1598: warning: implicit declaration of function `Packed_Array_Type'
../../../gcc/gcc/ada/decl.c:1658: `E_String_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1659: `E_Array_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:1674: warning: implicit declaration of function `Is_Constrained'
../../../gcc/gcc/ada/decl.c:2085: warning: implicit declaration of function `Is_Packed'
../../../gcc/gcc/ada/decl.c:2090: `E_String_Literal_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2094: `Private_Kind__First' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2094: `Private_Kind__Last' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2104: warning: implicit declaration of function `String_Literal_Low_Bound'
../../../gcc/gcc/ada/decl.c:2105: warning: implicit declaration of function `String_Literal_Length'
../../../gcc/gcc/ada/decl.c:2152: `E_Record_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2175: warning: implicit declaration of function `Type_Definition'
../../../gcc/gcc/ada/decl.c:2181: warning: implicit declaration of function `Component_Alignment'
../../../gcc/gcc/ada/decl.c:2182: `Calign_Storage_Unit' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2184: warning: implicit declaration of function `Has_Specified_Layout'
../../../gcc/gcc/ada/decl.c:2188: `N_Derived_Type_Definition' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2192: warning: implicit declaration of function `First_Entity'
../../../gcc/gcc/ada/decl.c:2194: warning: implicit declaration of function `Next_Entity'
../../../gcc/gcc/ada/decl.c:2197: warning: implicit declaration of function `Component_Clause'
../../../gcc/gcc/ada/decl.c:2205: warning: implicit declaration of function `Record_Extension_Part'
../../../gcc/gcc/ada/decl.c:2208: warning: implicit declaration of function `Parent_Subtype'
../../../gcc/gcc/ada/decl.c:2271: warning: implicit declaration of function `Has_Discriminants'
../../../gcc/gcc/ada/decl.c:2274: warning: implicit declaration of function `Next_Girder_Discriminant'
../../../gcc/gcc/ada/decl.c:2301: warning: implicit declaration of function `Is_Unchecked_Union'
../../../gcc/gcc/ada/decl.c:2338: warning: implicit declaration of function `Component_List'
../../../gcc/gcc/ada/decl.c:2344: warning: implicit declaration of function `Is_By_Reference_Type'
../../../gcc/gcc/ada/decl.c:2370: warning: implicit declaration of function `Is_Limited_Record'
../../../gcc/gcc/ada/decl.c:2389: `E_Class_Wide_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2394: warning: implicit declaration of function `Equivalent_Type'
../../../gcc/gcc/ada/decl.c:2403: `E_Record_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2409: warning: implicit declaration of function `Cloned_Subtype'
../../../gcc/gcc/ada/decl.c:2458: `Record_Kind__First' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2458: `Record_Kind__Last' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2459: warning: implicit declaration of function `Is_For_Access_Subtype'
../../../gcc/gcc/ada/decl.c:2462: warning: implicit declaration of function `Girder_Constraint'
../../../gcc/gcc/ada/decl.c:2463: warning: implicit declaration of function `Discriminant_Constraint'
../../../gcc/gcc/ada/decl.c:2685: `E_Access_Subprogram_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2696: warning: implicit declaration of function `Directly_Designated_Type'
../../../gcc/gcc/ada/decl.c:2712: `E_Allocator_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2713: `E_Access_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2714: `E_Access_Attribute_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2715: `E_Anonymous_Access_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2716: `E_General_Access_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:2743: warning: implicit declaration of function `Root_Type'
../../../gcc/gcc/ada/decl.c:2748: warning: implicit declaration of function `Is_Concurrent_Type'
../../../gcc/gcc/ada/decl.c:2749: warning: implicit declaration of function `Corresponding_Record_Type'
../../../gcc/gcc/ada/decl.c:2850: warning: implicit declaration of function `Is_Record_Type'
../../../gcc/gcc/ada/decl.c:2938: warning: implicit declaration of function `Freeze_Node'
../../../gcc/gcc/ada/decl.c:2962: warning: implicit declaration of function `Is_Frozen'
../../../gcc/gcc/ada/decl.c:3034: `E_Subprogram_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3035: `E_Function' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3036: `E_Procedure' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3058: warning: implicit declaration of function `Is_Inlined'
../../../gcc/gcc/ada/decl.c:3062: warning: implicit declaration of function `Is_Pure'
../../../gcc/gcc/ada/decl.c:3063: warning: implicit declaration of function `No_Return'
../../../gcc/gcc/ada/decl.c:3079: warning: implicit declaration of function `Alias'
../../../gcc/gcc/ada/decl.c:3081: `E_Enumeration_Literal' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3088: warning: implicit declaration of function `First_Formal'
../../../gcc/gcc/ada/decl.c:3090: warning: implicit declaration of function `Next_Formal_With_Extras'
../../../gcc/gcc/ada/decl.c:3102: warning: implicit declaration of function `Returns_By_Ref'
../../../gcc/gcc/ada/decl.c:3134: warning: implicit declaration of function `Has_Foreign_Convention'
../../../gcc/gcc/ada/decl.c:3156: warning: implicit declaration of function `Is_Valued_Procedure'
../../../gcc/gcc/ada/decl.c:3158: warning: implicit declaration of function `Mechanism'
../../../gcc/gcc/ada/decl.c:3196: `E_In_Parameter' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3379: warning: implicit declaration of function `Function_Returns_With_DSP'
../../../gcc/gcc/ada/decl.c:3452: `E_Incomplete_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3453: `E_Private_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3454: `E_Limited_Private_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3456: `E_Private_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3457: `E_Limited_Private_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3469: warning: implicit declaration of function `Underlying_Full_View'
../../../gcc/gcc/ada/decl.c:3523: `E_Task_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3524: `E_Protected_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3525: `E_Protected_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3538: `E_Block' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3539: `E_Loop' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3546: warning: unreachable code at beginning of switch statement
../../../gcc/gcc/ada/decl.c:3833: warning: implicit declaration of function `Associated_Node_For_Itype'
../../../gcc/gcc/ada/decl.c: In function `elaborate_entity':
../../../gcc/gcc/ada/decl.c:3850: `E_Signed_Integer_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3851: `E_Modular_Integer_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3852: `E_Enumeration_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3853: `E_Ordinary_Fixed_Point_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3854: `E_Decimal_Fixed_Point_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3855: `E_Floating_Point_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3864: warning: implicit declaration of function `Raises_Constraint_Error'
../../../gcc/gcc/ada/decl.c:3873: `E_Record_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3880: `N_Derived_Type_Definition' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3885: `E_Record_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3886: `E_Private_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3887: `E_Limited_Private_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3888: `E_Record_Subtype_With_Private' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3900: warning: implicit declaration of function `Next_Discriminant'
../../../gcc/gcc/ada/decl.c:3903: warning: implicit declaration of function `Is_Access_Type'
../../../gcc/gcc/ada/decl.c:3910: warning: unreachable code at beginning of switch statement
../../../gcc/gcc/ada/decl.c: In function `mark_out_of_scope':
../../../gcc/gcc/ada/decl.c:3924: `Class_Wide_Kind__First' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3924: `Class_Wide_Kind__Last' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3924: `Concurrent_Kind__First' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3924: `Concurrent_Kind__Last' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3925: `Private_Kind__First' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3925: `Private_Kind__Last' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3926: `E_Block' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3926: `E_Entry' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3927: `E_Entry_Family' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3927: `E_Function' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3928: `E_Generic_Function' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3928: `E_Generic_Package' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3929: `E_Generic_Procedure' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3929: `E_Loop' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3929: `E_Operator' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3930: `E_Package' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3930: `E_Package_Body' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3931: `E_Procedure' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3931: `E_Record_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3932: `E_Record_Subtype' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3932: `E_Subprogram_Body' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3932: `E_Subprogram_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3945: `Formal_Kind__First' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:3945: `Formal_Kind__Last' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c: In function `make_dummy_type':
../../../gcc/gcc/ada/decl.c:4023: warning: implicit declaration of function `Is_Class_Wide_Type'
../../../gcc/gcc/ada/decl.c:4025: `E_Class_Wide_Type' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4029: `Incomplete_Or_Private_Kind__First' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4029: `Incomplete_Or_Private_Kind__Last' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c: In function `build_attr_list':
../../../gcc/gcc/ada/decl.c:4087: warning: implicit declaration of function `First_Rep_Item'
../../../gcc/gcc/ada/decl.c:4088: warning: implicit declaration of function `Next_Rep_Item'
../../../gcc/gcc/ada/decl.c:4089: `N_Pragma' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4093: warning: implicit declaration of function `Pragma_Argument_Associations'
../../../gcc/gcc/ada/decl.c:4099: `N_String_Literal' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4115: warning: implicit declaration of function `Chars'
../../../gcc/gcc/ada/decl.c: In function `elaborate_expression':
../../../gcc/gcc/ada/decl.c:4221: `N_Identifier' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4221: warning: implicit declaration of function `Entity'
../../../gcc/gcc/ada/decl.c:4221: `E_Discriminant' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c: In function `maybe_pad_type':
../../../gcc/gcc/ada/decl.c:4589: `E_Component' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4589: `E_Discriminant' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4591: warning: implicit declaration of function `Last_Bit'
../../../gcc/gcc/ada/decl.c:4592: warning: implicit declaration of function `Size_Clause'
../../../gcc/gcc/ada/decl.c:4603: warning: implicit declaration of function `Is_Internal'
../../../gcc/gcc/ada/decl.c: In function `choices_to_gnu':
../../../gcc/gcc/ada/decl.c:4629: `N_Range' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4630: warning: implicit declaration of function `Low_Bound'
../../../gcc/gcc/ada/decl.c:4631: warning: implicit declaration of function `High_Bound'
../../../gcc/gcc/ada/decl.c:4644: `N_Subtype_Indication' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4645: warning: implicit declaration of function `Range_Expression'
../../../gcc/gcc/ada/decl.c:4645: warning: implicit declaration of function `Constraint'
../../../gcc/gcc/ada/decl.c:4657: `N_Identifier' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4658: `N_Expanded_Name' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4663: `E_Enumeration_Literal' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4663: `E_Constant' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4679: `N_Character_Literal' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4680: `N_Integer_Literal' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4686: `N_Others_Choice' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4690: warning: unreachable code at beginning of switch statement
../../../gcc/gcc/ada/decl.c: In function `gnat_to_gnu_field':
../../../gcc/gcc/ada/decl.c:4723: warning: implicit declaration of function `Strict_Alignment'
../../../gcc/gcc/ada/decl.c:4739: warning: implicit declaration of function `Known_Static_Esize'
../../../gcc/gcc/ada/decl.c:4761: warning: implicit declaration of function `Component_Bit_Offset'
../../../gcc/gcc/ada/decl.c:4778: warning: implicit declaration of function `First_Bit'
../../../gcc/gcc/ada/decl.c:4923: `E_Discriminant' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:4925: warning: implicit declaration of function `Discriminant_Number'
../../../gcc/gcc/ada/decl.c: In function `components_to_record':
../../../gcc/gcc/ada/decl.c:4982: warning: implicit declaration of function `Component_Items'
../../../gcc/gcc/ada/decl.c:5011: warning: implicit declaration of function `Variant_Part'
../../../gcc/gcc/ada/decl.c:5016: warning: implicit declaration of function `Variants'
../../../gcc/gcc/ada/decl.c:5037: warning: implicit declaration of function `Name'
../../../gcc/gcc/ada/decl.c:5079: warning: implicit declaration of function `Discrete_Choices'
../../../gcc/gcc/ada/decl.c: In function `annotate_value':
../../../gcc/gcc/ada/decl.c:5284: warning: comparison between signed and unsigned
../../../gcc/gcc/ada/decl.c: In function `annotate_rep':
../../../gcc/gcc/ada/decl.c:5374: `E_Component' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:5375: `E_Discriminant' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c: In function `validate_size':
../../../gcc/gcc/ada/decl.c:5461: `E_Component' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c:5461: `E_Discriminant' undeclared (first use in this function)
../../../gcc/gcc/ada/decl.c: In function `set_rm_size':
../../../gcc/gcc/ada/decl.c:5599: warning: implicit declaration of function `Is_Discrete_Or_Fixed_Point_Type'
../../../gcc/gcc/ada/decl.c: In function `validate_alignment':
../../../gcc/gcc/ada/decl.c:5726: warning: implicit declaration of function `Alignment_Clause'
../../../gcc/gcc/ada/decl.c:5740: warning: implicit declaration of function `From_At_Mod'
../../../gcc/gcc/ada/decl.c: In function `check_ok_for_atomic':
../../../gcc/gcc/ada/decl.c:5811: `N_Pragma' undeclared (first use in this function)
make[3]: *** [decl.o] Error 1
make[3]: Leaving directory `/home/guerby/work/gcc/build/gcc/ada'
make[2]: *** [gnat1] Error 2
make[2]: Leaving directory `/home/guerby/work/gcc/build/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/home/guerby/work/gcc/build/gcc'
make: *** [bootstrap] Error 2

Re: Ada files now checked in

[Joseph S. Myers]

On Tue, 2 Oct 2001, Richard Kenner wrote:

> They are in the subdirectory "gcc/ada".  If you have GNAT already on your
> machine, rerunning configure will up to build them.

Where is the manual for this front end?  Surely it must have one, but the
ada.info and ada.dvi targets in ada/Make-lang.in are dummies.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Joseph S. Myers]

On Tue, 2 Oct 2001, Richard Kenner wrote:

> They are in the subdirectory "gcc/ada".  If you have GNAT already on your
> machine, rerunning configure will up to build them.

These files seem to include RCS $Revision$ ids.  Could those be removed?
(See http://gcc.gnu.org/ml/libstdc++/2001-09/msg00111.html for discussion
of the problems associated with them.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada files now checked in

[Geert Bosch]

On Wed, 3 Oct 2001, Joseph S. Myers wrote:
  
  These files seem to include RCS $Revision$ ids.  Could those be removed?
  (See http://gcc.gnu.org/ml/libstdc++/2001-09/msg00111.html for discussion
  of the problems associated with them.)

In the coming days we will be focusing on finding efficient ways of
contributing ongoing changes made by Ada Core Technologies internally
to the FSF GCC tree. Given the volume of these changes and the fact
that we need to apply all those changes, we are definately interested 
in minimizing unnecessary differences and reducing the amount of work. 

I read the thread you referenced and am aware of the issue that you raise,
but since that is a pretty big change, right now doing something in that
direction would definately be counterproductive. For now, checking out
files using the -kk CVS option is most effective.

  -Geert