Re: ACATS & GCC testsuite

Re: ACATS & GCC testsuite

[Richard Kenner]

    I'm not sure why autogen is needed for testing, the
    only thing you need is dejagnu and then "make -k check"
    just works. (I have dejagnu-1.4.2-6 on my RedHat 8.0 machine).

But you also have to do a full build and doing it in maintainer-mode is
best.  Those require automake, autogen, and autoheader.

    > I'm not sure which message you're paraphrasing here, but I'm sure
    > there must be a miscommunication here. It is of course extremely
    > valuable if any regressions are caught when they occur!

    http://gcc.gnu.org/ml/gcc/2003-01/msg01299.html

Note that the "total waste of time" was *your* wording, not mine!  I was
agreeing with it due to the reason Geert gave yesterday: tracking down the
ACAS failures most likely will duplicate work already done.

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Fri, 2003-03-28 at 11:40, Richard Kenner wrote:
>     I'm not sure why autogen is needed for testing, the
>     only thing you need is dejagnu and then "make -k check"
>     just works. (I have dejagnu-1.4.2-6 on my RedHat 8.0 machine).
> 
> But you also have to do a full build and doing it in maintainer-mode is
> best.  Those require automake, autogen, and autoheader.

What are the arguments behind "best" here? Are the ACT releases built in
maintainer-mode? Same question for binary distributors like Linux
vendors? 

When I do testing I'd like to test it in a configuration
where I'm as close as possible as what a user of our source-based
release would do. Other testing scenario are useful, but far less than
this one IMHO.

That's why I by far prefer to have the testing being done
after install, and not in build like it is done for GCC
via DejaGNU now. It looks like I have no chance
of changing this sad state of affair, but well I
can still make a separate package for Ada.

Not testing in real world release conditions is a good way to get
into major trouble (red faces and all the stuff) for
no good reason.

Doing other kind of testing is nice but not essential.

BTW <http://gcc.gnu.org/install/configure.html> says:

--enable-maintainer-mode
        The build rules that regenerate the GCC master message catalog
        gcc.pot are normally disabled. This is because it can only be
        rebuilt if the complete source tree is present. If you have
        changed the sources and want to rebuild the catalog, configuring
        with --enable-maintainer-mode will enable this. Note that you
        need a recent version of the gettext tools to do so. 
        
        
Is it up to date? Looks like it's mentionning only
translation stuff. (I've never used maintainer mode.)

>     http://gcc.gnu.org/ml/gcc/2003-01/msg01299.html
> 
> Note that the "total waste of time" was *your* wording, not mine!  I was
> agreeing with it due to the reason Geert gave yesterday: tracking down the
> ACAS failures most likely will duplicate work already done.

Sorry if my wording did imply you used these words, I was
refering to the real world net end result: my partial tracking of those
issues a few monthes ago was a total waste of my volunteer time.

-- 
Laurent Guerby <guerby@acm.org>

Re: ACATS & GCC testsuite

[Daniel Jacobowitz]

On Fri, Mar 28, 2003 at 12:34:33PM +0100, Laurent Guerby wrote:
> On Fri, 2003-03-28 at 11:40, Richard Kenner wrote:
> >     I'm not sure why autogen is needed for testing, the
> >     only thing you need is dejagnu and then "make -k check"
> >     just works. (I have dejagnu-1.4.2-6 on my RedHat 8.0 machine).
> > 
> > But you also have to do a full build and doing it in maintainer-mode is
> > best.  Those require automake, autogen, and autoheader.
> 
> What are the arguments behind "best" here? Are the ACT releases built in
> maintainer-mode? Same question for binary distributors like Linux
> vendors? 
> 
> When I do testing I'd like to test it in a configuration
> where I'm as close as possible as what a user of our source-based
> release would do. Other testing scenario are useful, but far less than
> this one IMHO.
> 
> That's why I by far prefer to have the testing being done
> after install, and not in build like it is done for GCC
> via DejaGNU now. It looks like I have no chance
> of changing this sad state of affair, but well I
> can still make a separate package for Ada.

There's a script in contrib to test an installed compiler.  Right now
it only works for gcc/g++/g77, not any of the libraries; and you need
to add "rootme" to the generated site.exp to use it for C++; but it
does work, and I use it frequently.

> --enable-maintainer-mode
>         The build rules that regenerate the GCC master message catalog
>         gcc.pot are normally disabled. This is because it can only be
>         rebuilt if the complete source tree is present. If you have
>         changed the sources and want to rebuild the catalog, configuring
>         with --enable-maintainer-mode will enable this. Note that you
>         need a recent version of the gettext tools to do so. 
>         
>         
> Is it up to date? Looks like it's mentionning only
> translation stuff. (I've never used maintainer mode.)

No, it's not up to date (and I think that was never really accurate...)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Fri, 2003-03-28 at 15:50, Daniel Jacobowitz wrote:
> There's a script in contrib to test an installed compiler.  Right now
> it only works for gcc/g++/g77, not any of the libraries; and you need
> to add "rootme" to the generated site.exp to use it for C++; but it
> does work, and I use it frequently.

Thanks for the information, couldn't get it to work anyway.

> > --enable-maintainer-mode
> >         The build rules that regenerate the GCC master message catalog
> >         gcc.pot are normally disabled. This is because it can only be
> >         rebuilt if the complete source tree is present. If you have
> >         changed the sources and want to rebuild the catalog, configuring
> >         with --enable-maintainer-mode will enable this. Note that you
> >         need a recent version of the gettext tools to do so. 
> >         
> >         
> > Is it up to date? Looks like it's mentionning only
> > translation stuff. (I've never used maintainer mode.)
> 
> No, it's not up to date (and I think that was never really accurate...)

Since I've no idea what is maintainer mode about, I can't fix it.

-- 
Laurent Guerby <guerby@acm.org>

Re: ACATS & GCC testsuite

[Daniel Jacobowitz]

On Fri, Mar 28, 2003 at 05:40:37AM -0500, Richard Kenner wrote:
>     I'm not sure why autogen is needed for testing, the
>     only thing you need is dejagnu and then "make -k check"
>     just works. (I have dejagnu-1.4.2-6 on my RedHat 8.0 machine).
> 
> But you also have to do a full build and doing it in maintainer-mode is
> best.  Those require automake, autogen, and autoheader.

Why is it "best"?  Most other maintainers find it unnecessary unless
you're working with the generated files, and generally even if you are
you can just regenerate the ones you need.

It's simpler, quicker, and more consistent not to.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: ACATS & GCC testsuite

[Richard Kenner]

    5.00a is 3.2 based, and is not exactly current. The cvs sources are really
    the (not necessarily fully working, on a day to day basis) bleeding edge
    development sources, so it is better to wait to submit integration patches
    based on this cvs tree as soon as it is up (should be this coming week).

In addition, you won't have the revision histories from the 5.00a sources,
but will from the CVS tree.

Re: ACATS & GCC testsuite

[Robert Dewar]

> Do you mean that it's okay for people to submit integration
> patches from the published sources? I have 5.00a as an ACT customer,
> should I start from there?


5.00a is 3.2 based, and is not exactly current. The cvs sources are really
the (not necessarily fully working, on a day to day basis) bleeding edge
development sources, so it is better to wait to submit integration patches
based on this cvs tree as soon as it is up (should be this coming week).

Re: ACATS & GCC testsuite

[Richard Kenner]

    Why is it "best"?  

Because it does the most testing.

Re: ACATS & GCC testsuite

[Daniel Jacobowitz]

On Fri, Mar 28, 2003 at 09:57:31AM -0500, Richard Kenner wrote:
>     Why is it "best"?  
> 
> Because it does the most testing.

Hardly.  It "tests" your installed versions of at least:
  automake, autoconf, autogen, gettext, msgfmt

Presumably if you have modified any of their input files (excepting the
intl tools here) you've rerun them already anyway!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: ACATS & GCC testsuite

[Robert Dewar]

> > but if any new failures occur they represent real regressions.
> 
> Agreed. That will be very nice to start with zero regression
> on the Ada side. 

Just so nothing gets missed here, Geert's point, which I am not sure was clear
was that it is valuable to have ACATS regression testing installed right now,
since any *new* regressions are always problems, regardless of what versions of
sources are involved.

Re: ACATS & GCC testsuite

[Richard Kenner]

    > It's not the length of time of the install, but that I might not want to
    > install a new compiler at that point.  

    I'm curious about the reasons of not installing if not for time/space.

Because I want to keep my base compiler as one that is very stable.
If I don't, it's possible I could lose bootstrapping ability.

Re: ACATS & GCC testsuite

[Matthieu Moy]

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

> Because I want to keep my base compiler as one that is very stable.
> If I don't, it's possible I could lose bootstrapping ability.
>

Then, configure with --prefix=$HOME/gcc or something like that.

set your PATH and LD_LIBRARY_PATH, and it works. 

make  install  does  not  necessarily  means  overriding  the  default
compiler. 

-- 
Matthieu MOY
Ph. D Student at STMicroelectronics and Verimag -- SysAr Team

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Fri, 2003-03-28 at 13:01, Richard Kenner wrote:
>     I'm curious about the reasons of not installing if not for time/space.
> 
> Because I want to keep my base compiler as one that is very stable.
> If I don't, it's possible I could lose bootstrapping ability.

Ah I see, when I build I specify the base compiler used
(currently using the RH 8 compiler for C/Ada, but
I have most ACT public and customer releases installed also),
where to build (somewhere/build-TIMESTAMP) and where to install
(somewhere/install-TIMESTAMP), I never configure to the base
compiler. I assume you target some root only location.

I've a few dozens installed compilers, any other scheme wouldn't work
at all. The scheme is quite handy to do regression search,
testing build with various base compilers or testing
the new testsuite with old builds, etc... Everything's
automated (with hook for patch) so uncaught mistakes 
are unlikely.

Are other developper always configuring to root or is
Richard's practice uncommon?

-- 
Laurent Guerby <guerby@acm.org>

Re: ACATS & GCC testsuite

[Richard Kenner]

    That's a developper argument, and it's not that strong:
    testing C takes 43 minutes, Ada 44 minutes, and install is 1 minute
    and less than 70 MB (that two years of daily builds
    on a 40GB el cheapo disk, easy to spot regression then :).

It's not the length of time of the install, but that I might not want to
install a new compiler at that point.  Yes, otherwise doing the testing
doesn't test "make install", but it tests everything else.

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Fri, 2003-03-28 at 12:56, Richard Kenner wrote:
> It's not the length of time of the install, but that I might not want to
> install a new compiler at that point.  

I'm curious about the reasons of not installing if not for time/space.


-- 
Laurent Guerby <guerby@acm.org>

Re: ACATS & GCC testsuite

[Richard Kenner]

    What are the arguments behind "best" here? Are the ACT releases built in
    maintainer-mode? Same question for binary distributors like Linux
    vendors? 

The issue isn't how releases are built, but what's required to verify that
a patch doesn't break anything.

    That's why I by far prefer to have the testing being done after
    install, and not in build like it is done for GCC via DejaGNU now. 

No, builds seem right.  I don't want to have to install a compiler in
order to test it.

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Fri, 2003-03-28 at 12:44, Richard Kenner wrote:
>     What are the arguments behind "best" here? Are the ACT releases built in
>     maintainer-mode? Same question for binary distributors like Linux
>     vendors? 
> 
> The issue isn't how releases are built, but what's required to verify that
> a patch doesn't break anything.
> 
>     That's why I by far prefer to have the testing being done after
>     install, and not in build like it is done for GCC via DejaGNU now. 
> 
> No, builds seem right.  I don't want to have to install a compiler in
> order to test it.

That's a developper argument, and it's not that strong:
testing C takes 43 minutes, Ada 44 minutes, and install is 1 minute
and less than 70 MB (that two years of daily builds
on a 40GB el cheapo disk, easy to spot regression then :).

All the bad things of in build testing can still happen,
and they do happen, see the recent make install breakage
on Ada.

These things are adding to the release bill, you might
not be concerned, but others certainly are.


-- 
Laurent Guerby <guerby@acm.org>

Re: ACATS & GCC testsuite

[Zack Weinberg]

Laurent Guerby <guerby@acm.org> writes:

>>     That's why I by far prefer to have the testing being done after
>>     install, and not in build like it is done for GCC via DejaGNU now. 
>> 
>> No, builds seem right.  I don't want to have to install a compiler in
>> order to test it.
>
> That's a developper argument, and it's not that strong:
> testing C takes 43 minutes, Ada 44 minutes, and install is 1 minute
> and less than 70 MB (that two years of daily builds
> on a 40GB el cheapo disk, easy to spot regression then :).

When developing a patch I frequently sit in a cycle like this:

<edit edit edit>
$ make cc1
$ make check-gcc RUNTESTFLAGS="only/the/subset/I/care/about.exp"
FAIL: ...

<repeat>

I would not mind much if final acceptance testing for patches was done
on an installed tree, but I'll be unhappy if you break the above.

zw

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Wed, 2003-04-02 at 22:45, Zack Weinberg wrote:
> When developing a patch I frequently sit in a cycle like this:
> 
> <edit edit edit>
> $ make cc1
> $ make check-gcc RUNTESTFLAGS="only/the/subset/I/care/about.exp"
> FAIL: ...
> 
> <repeat>
> 
> I would not mind much if final acceptance testing for patches was done
> on an installed tree, but I'll be unhappy if you break the above.

The first part of packaging ACATS is configuring the source,
know what to tweak and remove in the mass of tests
and track updates in the suite (quite low volume anyway).

Once it is done, running the test is just compiling
support sources (all the tests are using a few
common packages), then looping over the tests
doing gnatmake, run, check for "PASSED" in output.

I'll package the ACATS sources to be suitable
for integration in CVS and provide a simple
contrib script to run and report the status
with an installed compiler.

Any testing framework should be able to pick up the thing
easily from there. As I said in a previous email, I no longer 
intent to figure out configure, Makefile & DejaGNU in build trickery, 
so if someone has the knowledge to add such a thing, please feel free to do so. 
(Plus it will have to be redone if the GCC build structure change
and / or if the Ada runtime change.)

A simple Ada test showing support precompile and then
build'n run a test:

$ gcc -c support.adb
$ gnatmake test_ada
$ ./test_ada
PASSED test_ada


$ cat support.ads
package Support is
   procedure Report (S : in String; Passed : in Boolean);
end Support;
$ cat support.adb
with Ada.Text_IO;
package body Support is
   procedure Report (S : in String; Passed : in Boolean) is
   begin
      if Passed then
         Ada.Text_IO.Put_Line ("PASSED " & S);
      else
         Ada.Text_IO.Put_Line ("FAILED " & S);
      end if;
   end Report;
end Support;
$ cat test_ada.adb
with Support;
procedure Test_Ada is
begin
   Support.Report ("test_ada", True);
end Test_Ada;
$



-- 
Laurent Guerby <guerby@acm.org>

Ada: Bootstrap failure on i386-unknown-freebsd4.7

[Michael Ritzert]

Hi all,

since some time my bootstrap dies with:

Bootstrap comparison failure!
ada/treepr.o differs

Looking at the files, the differences are mostly of this kind:

gcc/stage2/ada/treepr.o:
00000280 <treepr__print_entity_info>:
[...]
     2d2:       e8 fc ff ff ff          call   2d3 
<treepr__print_entity_info+0x53>
     2d7:       ff 15 00 00 00 00       call   *0x0
     2dd:       59                      pop    %ecx <<
     2de:       5b                      pop    %ebx <<
     2df:       50                      push   %eax


gcc/ada/treepr.o:
00000280 <treepr__print_entity_info>:
[...]
     2d2:       e8 fc ff ff ff          call   2d3 
<treepr__print_entity_info+0x53>
     2d7:       ff 15 00 00 00 00       call   *0x0
     2dd:       5a                      pop    %edx <<
     2de:       59                      pop    %ecx <<
     2df:       50                      push   %eax


In the build logs (I was on vacation and didn't notice this earlier), I see:
-bash-2.05b$ grep '\.o differs' 2003-03-*fail
2003-03-15-1.txt.fail:ada/repinfo.o differs
2003-03-15-1.txt.fail:ada/treepr.o differs
2003-03-17-1.txt.fail:ada/repinfo.o differs
2003-03-17-1.txt.fail:ada/treepr.o differs
2003-03-18-1.txt.fail:ada/repinfo.o differs
2003-03-18-1.txt.fail:ada/treepr.o differs
2003-03-19-1.txt.fail:ada/repinfo.o differs
2003-03-19-1.txt.fail:ada/treepr.o differs
2003-03-21-1.txt.fail:ada/treepr.o differs
2003-03-22-1.txt.fail:ada/treepr.o differs
2003-03-23-1.txt.fail:ada/treepr.o differs
2003-03-24-1.txt.fail:ada/treepr.o differs
2003-03-25-1.txt.fail:ada/treepr.o differs
2003-03-26-1.txt.fail:ada/treepr.o differs
2003-03-26-2.txt.fail:ada/treepr.o differs
2003-03-27-1.txt.fail:ada/treepr.o differs

so it first broke on 2003-03-15, then succeeded two times later on (on the 
16th and 20th). I put the file containing the changes I got between the build 
of the 14th and 15th at 
http://www.globe-tec.de/~ritzert/2003-03-15-1.ChangeLogs.gz and the two 
object files at http://www.globe-tec.de/~ritzert/ada-fail.tar.gz .

Michael

Re: Ada: Bootstrap failure on i386-unknown-freebsd4.7

[Laurent Guerby]

Hi Michael,

I don't see such comparison failures on x86-linux,
what is the version of the GNAT compiler you're starting with?
Did you try to run ACATS with the built compiler?
<http://perso.wanadoo.fr/guerby/ftp/acats4gnat-0.5.tgz>

-- 
Laurent Guerby <guerby@acm.org>

ACATS & GCC testsuite (Was Re: Ada: Bootstrap failure on i386-unknown-freebsd4.7)

[Arnaud Charlet]

> Did you try to run ACATS with the built compiler?
> <http://perso.wanadoo.fr/guerby/ftp/acats4gnat-0.5.tgz>

BTW, what is the status of integrating the ACATS as part of the GCC test suite ?

Arno

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Thu, 2003-03-27 at 23:10, Arnaud Charlet wrote:
> > Did you try to run ACATS with the built compiler?
> > <http://perso.wanadoo.fr/guerby/ftp/acats4gnat-0.5.tgz>
> 
> BTW, what is the status of integrating the ACATS as part of the GCC test suite ?

I know that the version of GNAT based on 3.2 delivered to customers
fixes the 40 or so ACATS tests failing in the current
public CVS (since I'm an ACT customer, but I also
know it has other problems :). 

Integrated ACATS testing has zero interest
until there are effective interactions between the ACT tree
and the public tree, see Richard Kenner's response
to my request on wether ACT outsiders could help
chasing Ada regressions (answer: no, total waste
of volunteer time). I'm currently
spending my limited free time on other projects
but will be happy to resume my efforts when it's useful.

The current ACATS setup has been used by some people
to check various ports (some of them not supported
by ACT), I update it when new ACATS releases are made (a few weeks ago
BTW) and I run it regularly on my home machine.

My last email to Geert and Robert on the topic (ada/5909) was
sent one month ago, without reply unless I missed it.

-- 
Laurent Guerby <guerby@acm.org>

Re: ACATS & GCC testsuite

[Geert Bosch]

On Thursday, Mar 27, 2003, at 17:34 America/New_York, Laurent Guerby 
wrote:
> I know that the version of GNAT based on 3.2 delivered to customers
> fixes the 40 or so ACATS tests failing in the current
> public CVS (since I'm an ACT customer, but I also
> know it has other problems :).

In the last few weeks (since the beta-release you speak about), we
have taken the following steps to contributing our GNAT changes to
the FSF GCC tree, and be able to do this on a more regular basis in
the future:

   - Put into place infrastructure that allows us to develop
     GNAT on the GCC HEAD branch in parallel with the last stable
     release version

   - Updated front end / back end interface as required for the
     extensive changes made in this area since GCC 3.2

   - Merged in changes made to FSF tree with ACT changes, and
     adapted our procedures to match those used by rest of GCC
     project (no $Revision lines in headers, for example)

   - Checked in two bug fixes for the back end, which are required
     by the Ada sources we are contributing

We are now at the stage that we can successfully bootstrap the
latest GCC with the latest GNAT sources. The tasks to be completed
in the coming weeks are the following:

   - Porting remaining back end patches against GCC 3.2.2 that could not
     go into that release to current GCC

   - Merging in our changes of GNAT back into the FSF repository

These last two action items will be done in parallel and first Ada
patches will go in this week. The makefiles are the biggest challenge
for this last item. Problems with setting up the GCC test suite
(see my message in http://gcc.gnu.org/ml/gcc/2003-03/msg01134.html)
are holding up integrating the back end patches.

> Integrated ACATS testing has zero interest
> until there are effective interactions between the ACT tree
> and the public tree, see Richard Kenner's response
> to my request on wether ACT outsiders could help
> chasing Ada regressions (answer: no, total waste
> of volunteer time).

I'm not sure which message you're paraphrasing here, but I'm sure
there must be a miscommunication here. It is of course extremely
valuable if any regressions are caught when they occur!

> I'm currently spending my limited free time on other projects
> but will be happy to resume my efforts when it's useful.

I think it would be very useful to have ACATS testing
capability for GCC at any time. If you prefer to wait
until after sources have been merged, so we'll start out with
few or no failures, that is fine. However, having regression
tests is useful at any point. If we have 40 failures now, it
may indeed not make sense for volunteers to go hunt at them
at this point while ACT is working on integrating the fixes,
but if any new failures occur they represent real regressions.

> The current ACATS setup has been used by some people
> to check various ports (some of them not supported
> by ACT), I update it when new ACATS releases are made (a few weeks ago
> BTW) and I run it regularly on my home machine.
That's good to know, thanks for your work here.

> My last email to Geert and Robert on the topic (ada/5909) was
> sent one month ago, without reply unless I missed it.

While I try to keep up with all GCC mail, I think I must have missed
your message. I just checked ada/5909 and don't see your message there
either, so could you resend it? If you don't receive a reply on a
message within a week or so, please ping me again.

   -Geert

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Fri, 2003-03-28 at 01:03, Geert Bosch wrote:
> On Thursday, Mar 27, 2003, at 17:34 America/New_York, Laurent Guerby 
> wrote:
> > I know that the version of GNAT based on 3.2 delivered to customers
> > fixes the 40 or so ACATS tests failing in the current
> > public CVS (since I'm an ACT customer, but I also
> > know it has other problems :).
> 
> In the last few weeks (since the beta-release you speak about), we
> have taken the following steps to contributing our GNAT changes to
> the FSF GCC tree, and be able to do this on a more regular basis in
> the future:
> 
>    - Put into place infrastructure that allows us to develop
>      GNAT on the GCC HEAD branch in parallel with the last stable
>      release version
> 
>    - Updated front end / back end interface as required for the
>      extensive changes made in this area since GCC 3.2
> 
>    - Merged in changes made to FSF tree with ACT changes, and
>      adapted our procedures to match those used by rest of GCC
>      project (no $Revision lines in headers, for example)
> 
>    - Checked in two bug fixes for the back end, which are required
>      by the Ada sources we are contributing

Great news!

> We are now at the stage that we can successfully bootstrap the
> latest GCC with the latest GNAT sources. The tasks to be completed
> in the coming weeks are the following:
> 
>    - Porting remaining back end patches against GCC 3.2.2 that could not
>      go into that release to current GCC
> 
>    - Merging in our changes of GNAT back into the FSF repository
>
> These last two action items will be done in parallel and first Ada
> patches will go in this week. The makefiles are the biggest challenge
> for this last item. Problems with setting up the GCC test suite
> (see my message in http://gcc.gnu.org/ml/gcc/2003-03/msg01134.html)
> are holding up integrating the back end patches.

I'm not sure why autogen is needed for testing, the
only thing you need is dejagnu and then "make -k check"
just works. (I have dejagnu-1.4.2-6 on my RedHat 8.0 machine).

gcc/configure has the following line:

    echo "configure generated by autoconf version 2.13"


> > Integrated ACATS testing has zero interest
> > until there are effective interactions between the ACT tree
> > and the public tree, see Richard Kenner's response
> > to my request on wether ACT outsiders could help
> > chasing Ada regressions (answer: no, total waste
> > of volunteer time).
> 
> I'm not sure which message you're paraphrasing here, but I'm sure
> there must be a miscommunication here. It is of course extremely
> valuable if any regressions are caught when they occur!

http://gcc.gnu.org/ml/gcc/2003-01/msg01299.html

I did trace some of them for a while, but none of my emails
were answered, and there was no point in answering them
after N>10 monthes of desynchronization between the
public and GCC tree :). 

http://gcc.gnu.org/ml/gcc/2002-12/msg00972.html
http://gcc.gnu.org/ml/gcc/2002-12/msg00969.html
http://gcc.gnu.org/ml/gcc/2003-01/msg01285.html

> > I'm currently spending my limited free time on other projects
> > but will be happy to resume my efforts when it's useful.
> 
> I think it would be very useful to have ACATS testing
> capability for GCC at any time. If you prefer to wait
> until after sources have been merged, so we'll start out with
> few or no failures, that is fine. However, having regression
> tests is useful at any point. If we have 40 failures now, it
> may indeed not make sense for volunteers to go hunt at them
> at this point while ACT is working on integrating the fixes,
> but if any new failures occur they represent real regressions.

Agreed. That will be very nice to start with zero regression
on the Ada side. 

One thing I need to check is the modification made to ACATS
by ACT if any. Could you send me the following ACATS
configuration files that should have been customized by ACT:

macro.dfs
fcndecl.ada
impdef.a
impdefc.a
impdefd.a
impdefe.a
impdefg.a
impdefh.a

I have my own versions made a while ago, but I believe
impdefc.a must have changed since my setup doesn't
work any more (generation of interrupt).

(Alternatively, you can send me the raw ACT ACATS scripts and files I'll
figure out the needed part and check with ACT if
I spot things that shouldn't be published).

> il to Geert and Robert on the topic (ada/5909) was
> > sent one month ago, without reply unless I missed it.
> 
> While I try to keep up with all GCC mail, I think I must have missed
> your message. I just checked ada/5909 and don't see your message there
> either, so could you resend it? If you don't receive a reply on a
> message within a week or so, please ping me again.

Resent privately (this was a private message with
essentially the same content as my previous one
on gcc@gcc.gnu.org).

-- 
Laurent Guerby <guerby@acm.org>

Re: ACATS & GCC testsuite

[Geert Bosch]

On Friday, Mar 28, 2003, at 02:27 America/New_York, Laurent Guerby 
wrote:
> One thing I need to check is the modification made to ACATS
> by ACT if any. Could you send me the following ACATS
> configuration files that should have been customized by ACT:
>
> macro.dfs
> fcndecl.ada
> impdef.a
> impdefc.a
> impdefd.a
> impdefe.a
> impdefg.a
> impdefh.a
>

I'll make sure the latest versions of these files will get sent ASAP.

   -Geert

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Fri, 2003-03-28 at 16:00, Geert Bosch wrote:
> I'll make sure the latest versions of these files will get sent ASAP.

Gail sent me the files, I'm checking against the old ones I'm using,
but it looks like nothing changed much :). Thanks!

A question, is the Ada.Interrupts stuff supposed to work
when using native threads on Linux 2.4? Looks like I have the same
impdefc but ACATS tests do not pass.

-- 
Laurent Guerby <guerby@acm.org>

Re: ACATS & GCC testsuite

[Arnaud Charlet]

> A question, is the Ada.Interrupts stuff supposed to work
> when using native threads on Linux 2.4? Looks like I have the same

It somewhat work manually, but the ACATS tests do not pass,
the signal handling of linuxthreads is too non conformant to POSIX.

Arno

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Sat, 2003-03-29 at 09:48, Arnaud Charlet wrote:
> > A question, is the Ada.Interrupts stuff supposed to work
> > when using native threads on Linux 2.4? Looks like I have the same
> 
> It somewhat work manually, but the ACATS tests do not pass,
> the signal handling of linuxthreads is too non conformant to POSIX.

Ok, thanks for the information, I won't insist on these tests then. BTW
did you get a chance to look at the new thread
stuff for linux, looks like there are two
projects but I never took the time to read the details...

-- 
Laurent Guerby <guerby@acm.org>

Re: ACATS & GCC testsuite

[Arnaud Charlet]

> Ok, thanks for the information, I won't insist on these tests then. BTW
> did you get a chance to look at the new thread
> stuff for linux, looks like there are two
> projects but I never took the time to read the details...

Yes, the IBM new thread implementation for linux look promising.
We're waiting for its official integration in linux distributions, as well as
proper support for it in gdb (always the part that tends to be
neglected) to add support in GNAT.

Arno

Re: ACATS & GCC testsuite

[Andreas Jaeger]

Arnaud Charlet <charlet@ACT-Europe.FR> writes:

>> Ok, thanks for the information, I won't insist on these tests then. BTW
>> did you get a chance to look at the new thread
>> stuff for linux, looks like there are two
>> projects but I never took the time to read the details...
>
> Yes, the IBM new thread implementation for linux look promising.

NGPT is dead, IBM recently announced that they stopped development.
You should look at NPTL instead.

> We're waiting for its official integration in linux distributions, as well as
> proper support for it in gdb (always the part that tends to be
> neglected) to add support in GNAT.

There're initial patches for NPTL flying around for gdb,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: ACATS & GCC testsuite

[Arnaud Charlet]

> NGPT is dead, IBM recently announced that they stopped development.
> You should look at NPTL instead.

Interesting. So this shows that I actually should not look at anything
until they are integrated and supported :-)

Anyone knows the reason for stopping development of this library ?

> There're initial patches for NPTL flying around for gdb,

Thanks for the information. So we will continue keeping an eye on it...
and wait some more, since NTPL does not seem to be quite ready yet.

Anyway, good to see that most people agree that the current linux threads
implementation is not viable.

Arno

Re: ACATS & GCC testsuite

[Andreas Jaeger]

Arnaud Charlet <charlet@ACT-Europe.FR> writes:

>> NGPT is dead, IBM recently announced that they stopped development.
>> You should look at NPTL instead.
>
> Interesting. So this shows that I actually should not look at anything
> until they are integrated and supported :-)
>
> Anyone knows the reason for stopping development of this library ?

NPTL is superior to NGPT and there's no need for two concurrenting
implementations.

>> There're initial patches for NPTL flying around for gdb,
>
> Thanks for the information. So we will continue keeping an eye on it...
> and wait some more, since NTPL does not seem to be quite ready yet.

But neither was NGPT - it only worked on a few platforms.

> Anyway, good to see that most people agree that the current linux threads
> implementation is not viable.

It's not that bad - but it's not POSIX compliant,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: ACATS & GCC testsuite

[Kai Henningsen]

aj@suse.de (Andreas Jaeger)  wrote on 30.03.03 in <u8isu0q4zo.fsf@gromit.moeb>:

> Arnaud Charlet <charlet@ACT-Europe.FR> writes:

> >> There're initial patches for NPTL flying around for gdb,
> >
> > Thanks for the information. So we will continue keeping an eye on it...
> > and wait some more, since NTPL does not seem to be quite ready yet.
>
> But neither was NGPT - it only worked on a few platforms.

Well, I understand NPTL is a joint work of the glibc (Ulrich) and linux- 
kernel (Ingo) people, with changes on both sides and, I gather, rather  
excellent performance numbers. However, I doubt it's much good on 2.4 or  
older kernels (I suspect it just falls back to the old LinuxThreads  
behaviour), and the 2.5 kernel versions with the necessary support haven't  
yet grown into a stable (2.6) version.

MfG Kai

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Sun, 2003-03-30 at 11:51, Arnaud Charlet wrote:
> Yes, the IBM new thread implementation for linux look promising.

I thought they stopped and the other one was taken (NG something,
from the glibc people IIRC).

> We're waiting for its official integration in linux distributions, as well as
> proper support for it in gdb (always the part that tends to be
> neglected) to add support in GNAT.

While we're on it, I don't monitor gdb, is the huge ACT patch
getting commited in the gdb public tree?

-- 
Laurent Guerby <guerby@acm.org>

Re: ACATS & GCC testsuite

[Arnaud Charlet]

> While we're on it, I don't monitor gdb, is the huge ACT patch
> getting commited in the gdb public tree?

We're working on it, integrating a huge patch is no trivial work as you
certainly know. In the mean time, our sources are available
at libre.act-europe.fr/GDB.

I am also happy to announce that for similar reasons, ACT's up to date
GNAT sources will also be made available via anonymous cvs from
libre-act-europe.fr next week.

This way, other people will be able to help merging our changes and
contributing changes more easily.

Arno

Re: ACATS & GCC testsuite

[Laurent Guerby]

On Sun, 2003-03-30 at 14:20, Arnaud Charlet wrote:
> I am also happy to announce that for similar reasons, ACT's up to date
> GNAT sources will also be made available via anonymous cvs from
> libre-act-europe.fr next week.
> 
> This way, other people will be able to help merging our changes and
> contributing changes more easily.

Do you mean that it's okay for people to submit integration
patches from the published sources? I have 5.00a as an ACT customer,
should I start from there?

-- 
Laurent Guerby <guerby@acm.org>