Re: EGCS-970929 and GNAT-3.10p?

Re: EGCS-970929 and GNAT-3.10p?

[Greg Galloway]

On Wed, 8 Oct 1997, Jeffrey A Law wrote:
>
> 
>   Greg Galloway wrote:
>   > 
>   > Is it possible to (re)build GNAT-3.10p with EGCS-970929 instead of
>   > GCC-2.7.2.1?
> We don't know.  Nobody's actually tried it...  Well, maybe one person,
> but I don't know what version of GNAT and EGCS he was working with or
> how much time he spent on it.
>
>   > The gnat-3.10p-src/gcc-2721.dif seems to contain patches
>   > that have already been applied to EGCS.
> Most, if not all of those patches should be in EGCS.
> 
> However, other changes made since gcc-2.7 may prevent GNAT from building.

The first show stopper with egcs+gnat is the routine get_inner_reference()
which is defined in gcc/tree.h as taking 8 arguments.  It is called from
gcc/ada/a-trans.c with only 7 arguments.

Thanks for the offer to help,

Greg
----
Gregory L. Galloway
Research Scientist I

http://eoeml.gtri.gatech.edu/home/gregg/

Re: EGCS-970929 and GNAT-3.10p?

[Jim Wilson]

	The first show stopper with egcs+gnat is the routine get_inner_reference()
	which is defined in gcc/tree.h as taking 8 arguments.  It is called from
	gcc/ada/a-trans.c with only 7 arguments.

This is a change made to the front-end/back-end interface since the gcc 2.7.2
release which has not been merged into the gnat releases yet.

To workaround it, add a line
	int alignment;
and then add to the end of the get_inner_reference call
	, &alignment

The gnat-3.11 sources incidentally already (or will) have this change.

Jim

Re: EGCS-970929 and GNAT-3.10p?

[Jeffrey A Law]

  In message < 199710092311.QAA26595@cygnus.com >you write:
  > 	The first show stopper with egcs+gnat is the routine get_inner_reference()
  > 	which is defined in gcc/tree.h as taking 8 arguments.  It is called from
  > 	gcc/ada/a-trans.c with only 7 arguments.
  > 
  > This is a change made to the front-end/back-end interface since the gcc 2.7.2
  > release which has not been merged into the gnat releases yet.
  > 
  > To workaround it, add a line
  > 	int alignment;
  > and then add to the end of the get_inner_reference call
  > 	, &alignment
  > 
  > The gnat-3.11 sources incidentally already (or will) have this change.
Odd, I picked up gnat-3.10p and it has the 8th argument for the call
to get_inner_reference in a-trans.c

jeff

Re: EGCS-970929 and GNAT-3.10p?

[Jim Wilson]

	Odd, I picked up gnat-3.10p and it has the 8th argument for the call
	to get_inner_reference in a-trans.c

It is in my copy too.  It is gnat-3.9 (and earlier) that are missing the new
8th argument to the get_inner_reference call.

Jim

Re: EGCS-970929 and GNAT-3.10p?

[Greg Galloway]

> 	Odd, I picked up gnat-3.10p and it has the 8th argument for the call
> 	to get_inner_reference in a-trans.c
>
> It is in my copy too.  It is gnat-3.9 (and earlier) that are missing the new
> 8th argument to the get_inner_reference call.
>
> Jim

It was gnat-3.07.  I was trying to bootstrap from 3.05 through 3.07, 3.09,
to 3.10p on an alpha-dec-osf3.2.  We're not running osf4.0 yet.

Greg

Re: EGCS-970929 and GNAT-3.10p?

[Jeffrey A Law]

  In message < 199710161953.PAA25018@nospokes.gtri.gatech.edu >you write:
  > It was gnat-3.07.  I was trying to bootstrap from 3.05 through 3.07, 3.09,
  > to 3.10p on an alpha-dec-osf3.2.  We're not running osf4.0 yet.
Ahh.

Well, I've got a successful bootstrap of gnat on hppa1.1-hp-hpux10.20 using
the 3.10p sources + egcs (971016 snapshot -- should be on the ftp server
now, announcement soon).

jeff

EGCS-970929 and GNAT-3.10p?

[Greg Galloway]

Is it possible to (re)build GNAT-3.10p with EGCS-970929 instead of
GCC-2.7.2.1?  The gnat-3.10p-src/gcc-2721.dif seems to contain patches
that have already been applied to EGCS.  I say `seems' because I have
not checked every last one of them.  I would like to get the benefits
of EGCS with respect to C++ and FORTRAN without loosing Ada.  I'm also
trying to build using the gcc/gnat binaries from cs.nyu.edu:/pub/gnat.

I'm trying to build for mips-irix6.3, mips-irix5.3, rs6k-aix3.2,
alpha-osf3.2, sparc-solaris2.5, and sparc-sunos4.1.3.

I've got a segmentation violation from collect2 during the link for cc1
for mips-irix5.3, and a misaligned data error compiling gmon-sol2.c
for sparc-solaris2.5.

Has anyone else attempted this?

Thanks,

Greg
----
Gregory L. Galloway
Research Scientist I

http://eoeml.gtri.gatech.edu/home/gregg/

Re: EGCS-970929 and GNAT-3.10p?

[Jeffrey A Law]

  In message < 199710082117.RAA06460@nospokes.gtri.gatech.edu >you write:
  > 
  > Is it possible to (re)build GNAT-3.10p with EGCS-970929 instead of
  > GCC-2.7.2.1?
We don't know.  Nobody's actually tried it...  Well, maybe one person,
but I don't know what version of GNAT and EGCS he was working with or
how much time he spent on it.

  > The gnat-3.10p-src/gcc-2721.dif seems to contain patches
  > that have already been applied to EGCS.
Most, if not all of those patches should be in EGCS.

However, other changes made since gcc-2.7 may prevent GNAT from building.

  > not checked every last one of them.  I would like to get the benefits
  > of EGCS with respect to C++ and FORTRAN without loosing Ada.  I'm also
  > trying to build using the gcc/gnat binaries from cs.nyu.edu:/pub/gnat.
Folding in GNAT is one of our long term goals; anything you can do to help
us reach that goal would be greatly appreciated.

I'll help as much as I can :-)

  > I'm trying to build for mips-irix6.3, mips-irix5.3, rs6k-aix3.2,
  > alpha-osf3.2, sparc-solaris2.5, and sparc-sunos4.1.3.
I'd pick one platform and stick with it until you can get something that
works.

  > I've got a segmentation violation from collect2 during the link for cc1
  > for mips-irix5.3, and a misaligned data error compiling gmon-sol2.c
  > for sparc-solaris2.5.
There's been a report of some problems with mips-sgi-irix5.2 which
occur due to -lmalloc.  I don't know if those might be related to your
irix5.3 problems.

As for the misaligned data error -- can you provide some more details?
What program got the misaligned data error?

jeff

Re: EGCS-970929 and GNAT-3.10p?

[Joel Sherrill]

On Wed, 8 Oct 1997, Jeffrey A Law wrote:

> 
>   In message < 199710082117.RAA06460@nospokes.gtri.gatech.edu >you write:
>   > 
>   > Is it possible to (re)build GNAT-3.10p with EGCS-970929 instead of
>   > GCC-2.7.2.1?
> We don't know.  Nobody's actually tried it...  Well, maybe one person,
> but I don't know what version of GNAT and EGCS he was working with or
> how much time he spent on it.

If that one person is me, then I have been trying to build gnat-3.10p with
the gcc2 test snapshots lately.  My early attempts at building with egcs
were not successful and I did not look into them vey far since I needed to
test egcs on non-Ada platforms at the time.  gnat-3.10p + testgcc-970803
seems to work OK except for a configuration problem in which a variable in
the generated ada/Makefile (target_alias) does not get substituted
correctly.

I may have some time next week to try this again.  I have been testing to
the sparc-rtems cross target on a linux box.

>   > The gnat-3.10p-src/gcc-2721.dif seems to contain patches
>   > that have already been applied to EGCS.
> Most, if not all of those patches should be in EGCS.
> 
> However, other changes made since gcc-2.7 may prevent GNAT from building.

I did not investigate much but it seemed that the egcs reorganization
compared to gcc 2.7.2.x may have broken something.  I need to try this all
again to confirm it though.  

>   > not checked every last one of them.  I would like to get the benefits
>   > of EGCS with respect to C++ and FORTRAN without loosing Ada.  I'm also
>   > trying to build using the gcc/gnat binaries from cs.nyu.edu:/pub/gnat.
> Folding in GNAT is one of our long term goals; anything you can do to help
> us reach that goal would be greatly appreciated.
> 
> I'll help as much as I can :-)

egcs is a bit father along now.  Perhaps it time for me to dust off
egcs+gnat.

>   > I'm trying to build for mips-irix6.3, mips-irix5.3, rs6k-aix3.2,
>   > alpha-osf3.2, sparc-solaris2.5, and sparc-sunos4.1.3.
> I'd pick one platform and stick with it until you can get something that
> works.

That's the only way to do it.

--joel

Re: EGCS-970929 and GNAT-3.10p?

[Jim Wilson]

	gnat-3.10p + testgcc-970803
	seems to work OK except for a configuration problem in which a variable in
	the generated ada/Makefile (target_alias) does not get substituted
	correctly.

This Makefile variable underwent a name change a few months ago, so this isn't
too surprising.  It should be easy to workaround.

	I did not investigate much but it seemed that the egcs reorganization
	compared to gcc 2.7.2.x may have broken something.  I need to try this all
	again to confirm it though.  

I don't believe that there is anything EGCS specific here.  It is just that
gnat-3.10p was released a few months ago, and does not include all of the
front-end/back-end interface changes that have been made since the gcc 2.7.2
release.  Many of these problems will likely be fixed by the gnat-3.11 release.

Jim

Re: EGCS-970929 and GNAT-3.10p?

[Jeffrey A Law]

  In message < Pine.BSF.3.96.971009075906.24865J-100000@vespucci.advicom.net >you write:
  > If that one person is me, then I have been trying to build gnat-3.10p with
  > the gcc2 test snapshots lately.
Yup.  I was referring to you :-)

  > My early attempts at building with egcs
  > were not successful and I did not look into them vey far since I
  > needed to test egcs on non-Ada platforms at the time.
Well, if you remember what went wrong I might be able to provide some
assistance now (I don't think I saved that message, I guess I could go
wander the archives...).

I started poking at gnat-3.10p with egcs a short while ago -- I got
gnat1 and gnattools built on the PA.  It then died building the
library due to a buglet in the gcc-2.7.2 PA binaries provided by
the GNAT folks.

After working around that and rebuilding, I got gnat1, gnattools
and gnatlib built OK, except for s-taprde, which got a warning
of some kind, then the build stopped.  I disabled that one object
(I've got better things to do right now :-) and the gnatlib build
finished.

I'm going to to a gnat 3-stage overnight, just to see what happens.

BTW -- is it just me, or is the Ada compiler extremely slow?


This was mostly a proof of concept and to give me some home grown gnat
binaries for bootstrapping purposes later.  I'm not going to try to
integrate GNAT into egcs right now (though we do want it long term).

When we do start thinking about integrating GNAT, the big issues will be:

  * GNAT is written in Ada, and thus requires GNAT binaries to bulid itself.

  * The build process isn't exactly "make; make install" :-)  We'll have
  to pull out the runtime and figure out how to deal with gnattools.  I
  suspect there'll be problems with GNAT in cross build environments too.

jeff

Re: EGCS-970929 and GNAT-3.10p?

[Klaus Kaempf]

> 
> I started poking at gnat-3.10p with egcs a short while ago -- I got
> gnat1 and gnattools built on the PA.  It then died building the
> library due to a buglet in the gcc-2.7.2 PA binaries provided by
> the GNAT folks.
> 
AFAIK the openVMS/Alpha backend of gcc is based on gnat-4.x and may
not run with gnat-3.x at all. This may be true for other backends too.

-- 
proGIS Software                 E-Mail: kkaempf@progis.de
Dipl.-Inform. Klaus K"ampf      Fax:    0241-47067-29
Jakobstr. 117                   Voice:  0241-47067-11
D-52064 Aachen                  WWW:	http://www.progis.de

Re: EGCS-970929 and GNAT-3.10p?

[Jeffrey A Law]

  In message < 9710161026.AA23945@progis.de >you write:
  > > 
  > > I started poking at gnat-3.10p with egcs a short while ago -- I got
  > > gnat1 and gnattools built on the PA.  It then died building the
  > > library due to a buglet in the gcc-2.7.2 PA binaries provided by
  > > the GNAT folks.
  > > 
  > AFAIK the openVMS/Alpha backend of gcc is based on gnat-4.x and may
  > not run with gnat-3.x at all. This may be true for other backends too.
It wouldn't suprise me if there's numerous numerous it doesn't work
with.  

jeff

Re: EGCS-970929 and GNAT-3.10p?

[Jim Wilson]

	BTW -- is it just me, or is the Ada compiler extremely slow?

It depends on what you are used to.  GNAT is considered fast, for an Ada
compiler.  I doubt that it compares favorably to a C compiler though.

Also, note the size of the source files and run time library.  It takes a
long time to bootstrap it in part because it is so large.

	* The build process isn't exactly "make; make install" :-)  We'll have
	to pull out the runtime and figure out how to deal with gnattools.  I
	suspect there'll be problems with GNAT in cross build environments too.

I am sure that there will be problems of this sort with getting GNAT integrated
into EGCS.

When I first started doing GNAT builds, it did not work for objdir != srcdir
builds.  I don't know if that has been fixed yet.

Jim

Re: EGCS-970929 and GNAT-3.10p?

[Jeffrey A Law]

  In message < 199710161930.MAA05133@cygnus.com >you write:
  > When I first started doing GNAT builds, it did not work for
  > objdir != srcdir builds.  I don't know if that has been fixed
  > yet.
That worked fine for me...

jeff

Re: EGCS-970929 and GNAT-3.10p?

[Joel Sherrill]

On Thu, 16 Oct 1997, Jim Wilson wrote:

> When I first started doing GNAT builds, it did not work for objdir != srcdir
> builds.  I don't know if that has been fixed yet.

You mean having a separate build directory?  This has worked for me for a
long time.

--joel

Re: EGCS-970929 and GNAT-3.10p?

[Joel Sherrill]

> Well, if you remember what went wrong I might be able to provide some
> assistance now (I don't think I saved that message, I guess I could go
> wander the archives...).

I have just finished a testing sweep trying to get gnat/rtems up to date
on a bunch of tools and see that it still worked on at least the sparc.  I
will attack building 3.10p on egcs RSN.  I have one problem with gnat
3.10p and the early August  testgcc snapshot I was working with.  The
substitution in Makefile.in as follows:

target=
target_alias=

Gets botched for target alias.  Both lines end up with target= on the LHS.
I am not an autoconf expert but it looks like the substitution in the
language subdirectories is done differently form the main gcc/Makefile.in.
Best I could tell no other language subdirectory used target_alias.  I
have had to hand edit the generated ada/Makefile.

Any one have any ideas why this substitution might be broken?

FYI the vanilla gnat source does not have any references to target_alias,
program_prefix, or program_transform_name.  That was part of ewhat I was
working on.

> I started poking at gnat-3.10p with egcs a short while ago -- I got
> gnat1 and gnattools built on the PA.  It then died building the
> library due to a buglet in the gcc-2.7.2 PA binaries provided by
> the GNAT folks.

I have noticed people in the past griping about the PA.  

> BTW -- is it just me, or is the Ada compiler extremely slow?

It probably looks that way since you probably have no idea how much work
it is doing. :) It is not really that slow as far as Ada compilers go.  

> This was mostly a proof of concept and to give me some home grown gnat
> binaries for bootstrapping purposes later.  I'm not going to try to
> integrate GNAT into egcs right now (though we do want it long term).

Public gnat's are not released very often so this should not be that much
trouble.  No development snapshots are publicly available.  If I ever give
anything other than that impression, please slap me around. :)

> When we do start thinking about integrating GNAT, the big issues will be:
> 
>   * GNAT is written in Ada, and thus requires GNAT binaries to bulid itself.

Yes.  

>   * The build process isn't exactly "make; make install" :-)  We'll have
>   to pull out the runtime and figure out how to deal with gnattools.  I
>   suspect there'll be problems with GNAT in cross build environments too.

The cross procedure is different and requires some changes to makefiles
and tools.  I am trying to work these out.

--joel

Re: EGCS-970929 and GNAT-3.10p?

[Jeffrey A Law]

  In message < Pine.BSF.3.96.971016075832.13079A-100000@vespucci.advicom.net >you write:
  > 3.10p and the early August  testgcc snapshot I was working with.  The
  > substitution in Makefile.in as follows:
  > 
  > target=
  > target_alias=
  > 
  > Gets botched for target alias.
Hmmm, my gcc/ada/Makefile doesn't have a reference to target_alias:

% grep target_alias Makefile
% grep target= Makefile
target=hppa1.1-hp-hpux10.20


   > Both lines end up with target= on the LHS.
  > I am not an autoconf expert but it looks like the substitution in the
  > language subdirectories is done differently form the main gcc/Makefile.in.
Quite possible -- that stuff has changed a lot recently.

  > FYI the vanilla gnat source does not have any references to target_alias,
  > program_prefix, or program_transform_name.  That was part of ewhat I was
  > working on.
Maybe that's why I don't have target_alias in the generated Makefile :-)

Yes, the lack of prefix & transform name will be an issue we'll
have to settle.  Part of the generic "fix Ada for cross platforms"
problem.


  > > I started poking at gnat-3.10p with egcs a short while ago -- I got
  > > gnat1 and gnattools built on the PA.  It then died building the
  > > library due to a buglet in the gcc-2.7.2 PA binaries provided by
  > > the GNAT folks.
  > 
  > I have noticed people in the past griping about the PA.  
It should be noted that once I got the first egcs based gnat binary running
it would successfully bootstrap with -O2 or no optimization -- no released
version of gnat can do that as far as I know! (some ada files have to be built
with optimization and others without)

Many of the PA gnat problems can be traced back to Kenner refusing to
fix some C code in the Ada front end which has undefined ANSI behavior.

  > It probably looks that way since you probably have no idea how much work
  > it is doing. :) It is not really that slow as far as Ada compilers go.  
:-) :-)  It certainly seems slow to me :-)


jeff

Re: EGCS-970929 and GNAT-3.10p?

[Richard Henderson]

On Thu, Oct 16, 1997 at 09:51:43AM -0600, Jeffrey A Law wrote:
>   > It probably looks that way since you probably have no idea how much work
>   > it is doing. :) It is not really that slow as far as Ada compilers go.  
> :-) :-)  It certainly seems slow to me :-)

I heard a story that the first program to be compiled in Ada was
a version of Hello World, and it took 76 minutes to build...


r~

Re: EGCS-970929 and GNAT-3.10p?

[Joel Sherrill]

On Thu, 16 Oct 1997, Richard Henderson wrote:

> On Thu, Oct 16, 1997 at 09:51:43AM -0600, Jeffrey A Law wrote:
> >   > It probably looks that way since you probably have no idea how much work
> >   > it is doing. :) It is not really that slow as far as Ada compilers go.  
> > :-) :-)  It certainly seems slow to me :-)
> 
> I heard a story that the first program to be compiled in Ada was
> a version of Hello World, and it took 76 minutes to build...

I have never heard that story but remember that the original Ada language
standard was approved in 1983 with the initial request for language
proposals dating back into the 70's.  So you are looking at a prototype
compiler on at best an early VAX. :)  

Things have come a long way since then.  Just look at the Linux vs
Ultrasparc C++ numbers posted on the list. :)

--joel

Re: EGCS-970929 and GNAT-3.10p?

[Toon Moene]

Joel Sherrill wrote:

> On Thu, 16 Oct 1997, Richard Henderson wrote:

>> I heard a story that the first program to be compiled in Ada was
>> a version of Hello World, and it took 76 minutes to build...

>  I have never heard that story but remember that the
>  original Ada language standard was approved in 1983 with
>  the initial request for language proposals dating back
>  into the 70's.  So you are looking at a prototype compiler
>  on at best an early VAX. :)

Heh, heh, _do_ I remember ...  Those discussions in the SIGPLAN  
notices in 78/79 on the Grand Unified Language *), which I read when  
I was a grad physics student (there was no CS department at that  
time, although Tanenbaum had his niche in the Mathematics  
Department, of course).

Fortunately, we know better now: Java !

[ I did play with the thought to build GNAT in combination with g77  
before the EGCS project emerged, simply to get a better grip on the  
regressions g77's backend patches might generate and because people  
were asking us (fortran@gnu.ai.mit.edu) how to build this  
combination.  I gave up on this once I read that the GNAT test suite  
is proprietary ;-( ]

Cheers,
Toon.

*) "Besides, the determined Real Programmer can write FORTRAN  
programs in any language" - Ed Post, Datamation, July '83.

Re: EGCS-970929 and GNAT-3.10p?

[Joel Sherrill]

> Fortunately, we know better now: Java !

That path has its own unique set of advantages and disadvantages.

> [ I did play with the thought to build GNAT in combination with g77  
> before the EGCS project emerged, simply to get a better grip on the  
> regressions g77's backend patches might generate and because people  
> were asking us (fortran@gnu.ai.mit.edu) how to build this  
> combination.  I gave up on this once I read that the GNAT test suite  
> is proprietary ;-( ]

A lot of the code used to test an Ada compiler is freely available.  For
example, the Ada Compiler Validatation suite is free.  The setup and
configuration of it is compiler dependent and that part is proprietary.
There are large bodies of performance suites like PIWG which are freely
available. 

--joel

Re: EGCS-970929 and GNAT-3.10p?

[Toon Moene]

Me:

> [ I did play with the thought to build GNAT in combination with g77  
> before the EGCS project emerged, simply to get a better grip on the  
> regressions g77's backend patches might generate and because people  
> were asking us (fortran@gnu.ai.mit.edu) how to build this
> combination.  I gave up on this once I read that the GNAT test
> suite is proprietary ;-( ]

Joel:

>  A lot of the code used to test an Ada compiler is freely
>  available.  For example, the Ada Compiler Validatation
>  suite is free.  The setup and configuration of it is
>  compiler dependent and that part is proprietary.  There
>  are large bodies of performance suites like PIWG which
>  are freely available.

Took me some time to get to the information I thought I had read -  
DejaNews to the rescue !

Power Search, Old database, search string "ada test suite dewar"  
gives you:

Subject: Re: Towards a free GNU Ada

Note that this kind of regression testing is out of reach
of informal fiddling. For one thing, the great majority of
the code in the critical regression suite is proprietary,
for example it includes large chuncks of the DEC test suite,
as well as a lot of customer code, that the customer has
been willing to entrust to us only on the basis that we will
carefully protect it. It is also the case that the
configuration control that is needed requires very strong
control and management.

Straight from the horse's mouth ...

Of course I needed the regression tests for what I wanted (see above).

HTH,
Toon.

Re: EGCS-970929 and GNAT-3.10p?

[Joel Sherrill]

On Thu, 23 Oct 1997, Toon Moene wrote:

> 
> Note that this kind of regression testing is out of reach
> of informal fiddling. For one thing, the great majority of
> the code in the critical regression suite is proprietary,
> for example it includes large chuncks of the DEC test suite,
> as well as a lot of customer code, that the customer has
> been willing to entrust to us only on the basis that we will
> carefully protect it. It is also the case that the
> configuration control that is needed requires very strong
> control and management.
> 
> Straight from the horse's mouth ...
> 
> Of course I needed the regression tests for what I wanted (see above).

Yes but the ACVC is the "official" testing suite used when a validation
certificate is issued.  It is freely available even if the setup and test
fixtures are not.

There is a lot of freely available Ada code to base test suite on.

--joel

Re: EGCS-970929 and GNAT-3.10p?

[Jim Wilson]

	There's been a report of some problems with mips-sgi-irix5.2 which
	occur due to -lmalloc.  I don't know if those might be related to your
	irix5.3 problems.

This is usually a bug in a free call someplace.  There have been
two of them recently, one in cp/except.c (find_exception_handler_labels)
and one in frame.c (__deregister_frame).  The latter was particularly nasty,
because it caused a failure while running functions in the .fini section,
and hence was hard to debug.  Both problems have been fixed already.  I am
not aware of any unfixed irix5 problems with -malloc.

Jim