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

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>

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

[Michael Ritzert]

Hi Laurent,

Am Donnerstag, 27. März 2003 23:06 schrieb Laurent Guerby:
> I don't see such comparison failures on x86-linux,
> what is the version of the GNAT compiler you're starting with?

Reading specs from /usr/local/lib/gcc-lib/i386-unknown-freebsd4.5/2.8.1/specs
gcc version 2.8.1

I just started a bootstrap with gcc HEAD as the Ada compiler. I don't know 
what it's worth given the suspicion that it's faulty, but one can still try.

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

I will do so later with the compilers produces by the bootstraps with 2.8.1 
and HEAD.

Michael

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

[Ritzert]

Hi Laurent,

Michael Ritzert wrote:
>  I just started a bootstrap with gcc HEAD as the Ada
> compiler. I don't know 
>  what it's worth given the suspicion that it's faulty,
> but one can still try.

The bootstrap finished without an error. The ACATS results I get (for
both compilers):
 acats4gnat results cz 3 /        4
acats4gnat results a 62 /       75
acats4gnat results c2 33 /       34
acats4gnat results c3 332 /      356
acats4gnat results c4 328 /      340
acats4gnat results c5 93 /       95
acats4gnat results c6 78 /       81
acats4gnat results c7 48 /       53
acats4gnat results c8 119 /      141
acats4gnat results c9 3 /      256
acats4gnat results ca 72 /       74
acats4gnat results cb 32 /       43
acats4gnat results cc 105 /      118
acats4gnat results cd 166 /      178
acats4gnat results ce 259 /      265
acats4gnat results cxa 85 /       88
acats4gnat results cxb 30 /       30
acats4gnat results cxc 2 /       15
acats4gnat results cxd 0 /       39
acats4gnat results cxe 1 /        1
acats4gnat results cxf 20 /       20
acats4gnat results cxg 8 /       29
acats4gnat results cxh 0 /        4
acats4gnat results d 4 /        4
acats4gnat results e 11 /       11
acats4gnat results l 24 /       29

Michael

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

[Laurent Guerby]

On Sat, 2003-03-29 at 16:10, Ritzert@t-online.de wrote:
> The bootstrap finished without an error. The ACATS results I get (for
> both compilers):

Looks not that bad, but since ACATS is mostly feature per feature
that doesn't mean that much :).

> acats4gnat results c9 3 /      256

I assume the tasking runtime is not supported on your platform
(c9 are tasking tests). The additional (vs linux) failures you get on
are probably due to tasking too (there are tasking constructs
in a lot of tests outside c9).

If you're interested in a finer analysis please send me
privately the output of the run_all.sh script
(compressed it should be less than 150kB).

BTW, did you need to change anything to the script?

-- 
Laurent Guerby <guerby@acm.org>