sparc-linux results for 4.0.1 RC3

sparc-linux results for 4.0.1 RC3

[Christian Joensson]

hmm, I get a few libstdc++ testsuite failuers....

http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html

other than that, looks pretty fine.

-- 
Cheers,

/ChJ

Re: sparc-linux results for 4.0.1 RC3

[Eric Botcazou]

> hmm, I get a few libstdc++ testsuite failuers....
>
> http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
>
> other than that, looks pretty fine.

Did you get them with 4.0.0 too?  If no, the libstdc++ folks will have to say 
whether they are really regressions (the testsuite harness has changed).

-- 
Eric Botcazou

Re: sparc-linux results for 4.0.1 RC3

[Christian Joensson]

On 7/6/05, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:
> > hmm, I get a few libstdc++ testsuite failuers....
> >
> > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
> >
> > other than that, looks pretty fine.
> 
> Did you get them with 4.0.0 too?  If no, the libstdc++ folks will have to say
> whether they are really regressions (the testsuite harness has changed).

hmm, not quite...

http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01646.html

-- 
Cheers,

/ChJ

Re: sparc-linux results for 4.0.1 RC3

[Paolo Carlini]

Eric Botcazou wrote:

>>hmm, I get a few libstdc++ testsuite failuers....
>>
>>http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
>>
>>other than that, looks pretty fine.
>>    
>>
>Did you get them with 4.0.0 too?  If no, the libstdc++ folks will have to say 
>whether they are really regressions (the testsuite harness has changed).
>
Yes, I would definitely encourage a little more analysis. I'm rather
puzzled. We have got very nice testsuites on sparc-solaris and on
*-linux, in general, and those failures certainly are not expected.
However, missing additional details, it's very difficult to guess: can
be almost anything, from a weirdness in the installed localedata to a
defect of the testsuite harness, to a code generation bug, to a latent
bug in the generic code of the library exposed only by that target, and
only now.

Paolo.

Re: sparc-linux results for 4.0.1 RC3

[Paolo Carlini]

Paolo Carlini wrote:

>However, missing additional details, it's very difficult to guess: can
>be almost anything, from a weirdness in the installed localedata...
>
Probably we can exclude at least this first possibility: if I understand
well, everything related to glibc has not changed on the machine.

Paolo.

Re: sparc-linux results for 4.0.1 RC3

[Christian Joensson]

On 7/6/05, Christian Joensson <christian.joensson@gmail.com> wrote:
> On 7/6/05, Paolo Carlini <pcarlini@suse.de> wrote:
> > Christian Joensson wrote:
> >
> > >limiting this e-mail... I could also rebootstrap 4.0.0 if you think
> > >that'd be more useful... let me know what you would like...
> > >
> > Well, every possible independent check can be useful. Both
> > rebootstrapping 4.0.0 with your exact current machine certainly makes
> > sense (maybe it's obvious to you but for this kind of work, it suffices
> > a simple 'make' and only --enable-languages=c++, will take *a lot* less
> > time) and testing 4.0.1 with a machine as similar as possible to the one
> > you used at the time for 4.0.0.
> >
> > Also, of course I would like to see the libstdc++.log bits for the fails.
> 
> so, 4.0.0 c++ only is on the way... and here's the relevant(?)
> libstdc++.log bits:

So, 4.0.0 testsuite posted at:

http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00344.html

What would you like me to do now?

I could back off binutils to binutils-2.15.92.0.2-5 and rebootstrap
both 4.0.0 and 4.0.1 RC3 for c++ only...

-- 
Cheers,

/ChJ

Re: sparc-linux results for 4.0.1 RC3

[Christian Joensson]

On 7/7/05, Christian Joensson <christian.joensson@gmail.com> wrote:

I guess most was binutils issues... sorry, 4.0.1 seems fine to me on
sparc-linux:

http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00560.html

-- 
Cheers,

/ChJ

Re: sparc-linux results for 4.0.1 RC3

[Christian Joensson]

On 7/6/05, Paolo Carlini <pcarlini@suse.de> wrote:
> Eric Botcazou wrote:
> 
> >>hmm, I get a few libstdc++ testsuite failuers....
> >>
> >>http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
> >>
> >>other than that, looks pretty fine.
> >>
> >>
> >Did you get them with 4.0.0 too?  If no, the libstdc++ folks will have to say
> >whether they are really regressions (the testsuite harness has changed).
> >
> Yes, I would definitely encourage a little more analysis. I'm rather
> puzzled. We have got very nice testsuites on sparc-solaris and on
> *-linux, in general, and those failures certainly are not expected.
> However, missing additional details, it's very difficult to guess: can
> be almost anything, from a weirdness in the installed localedata to a
> defect of the testsuite harness, to a code generation bug, to a latent
> bug in the generic code of the library exposed only by that target, and
> only now.

let me roll back binutils to and rebootstrap... or would you say I
could very well wait for 4.0.1 and test that?

-- 
Cheers,

/ChJ

Re: sparc-linux results for 4.0.1 RC3

[Eric Botcazou]

> Yes, I would definitely encourage a little more analysis. I'm rather
> puzzled. We have got very nice testsuites on sparc-solaris and on
> *-linux, in general, and those failures certainly are not expected.

Is the

FAIL: abi_check

failure expected?  Should config/abi/sparc-linux-gnu/baseline_symbols.txt be 
somehow updated?

> However, missing additional details, it's very difficult to guess: can
> be almost anything, from a weirdness in the installed localedata to a
> defect of the testsuite harness, to a code generation bug, to a latent
> bug in the generic code of the library exposed only by that target, and
> only now.

Agreed, but were these tests simply run with the 4.0.0 testsuite?

-- 
Eric Botcazou

Re: sparc-linux results for 4.0.1 RC3

[Paolo Carlini]

Eric Botcazou wrote:

>>Yes, I would definitely encourage a little more analysis. I'm rather
>>puzzled. We have got very nice testsuites on sparc-solaris and on
>>*-linux, in general, and those failures certainly are not expected.
>>    
>>
>Is the
>
>FAIL: abi_check
>
>failure expected?  Should config/abi/sparc-linux-gnu/baseline_symbols.txt be 
>somehow updated?
>  
>
Yes, probably we should concentrate on that failure. It's the most
strange, probably, because Benjamin and Jakub (certainly a Sparc expert)
updated the sparc-linux baseline around mid of June. Maybe we should
involve Jakub too in the discussion, at least to confirm that on his
sparc-linux machines abi_check doesn't fail.

Jakub?

Paolo.

Re: sparc-linux results for 4.0.1 RC3

[Jakub Jelinek]

On Wed, Jul 06, 2005 at 04:33:43PM +0200, Paolo Carlini wrote:
> Eric Botcazou wrote:
> 
> >>Yes, I would definitely encourage a little more analysis. I'm rather
> >>puzzled. We have got very nice testsuites on sparc-solaris and on
> >>*-linux, in general, and those failures certainly are not expected.
> >>    
> >>
> >Is the
> >
> >FAIL: abi_check
> >
> >failure expected?  Should config/abi/sparc-linux-gnu/baseline_symbols.txt be 
> >somehow updated?
> >  
> >
> Yes, probably we should concentrate on that failure. It's the most
> strange, probably, because Benjamin and Jakub (certainly a Sparc expert)
> updated the sparc-linux baseline around mid of June. Maybe we should
> involve Jakub too in the discussion, at least to confirm that on his
> sparc-linux machines abi_check doesn't fail.

The best would be if Christian could post (bzip2ed) readelf -Ws of
the libstdc++.so that fails the abi_check.

	Jakub

Re: sparc-linux results for 4.0.1 RC3

[Paolo Carlini]

Jakub Jelinek wrote:

>The best would be if Christian could post (bzip2ed) readelf -Ws of
>the libstdc++.so that fails the abi_check.
>  
>
In fact, the excerpt from libstdc++.log that he sent privately doesn't
show the "check-abi Summary": as far as I know, abi_check can be
segfaulting (as is apparently happening for the other failures that he
reported).

Paolo.

Re: sparc-linux results for 4.0.1 RC3

[Christian Joensson]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

On 7/6/05, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Jul 06, 2005 at 04:33:43PM +0200, Paolo Carlini wrote:
> > Eric Botcazou wrote:
> >
> > >>Yes, I would definitely encourage a little more analysis. I'm rather
> > >>puzzled. We have got very nice testsuites on sparc-solaris and on
> > >>*-linux, in general, and those failures certainly are not expected.
> > >>
> > >>
> > >Is the
> > >
> > >FAIL: abi_check
> > >
> > >failure expected?  Should config/abi/sparc-linux-gnu/baseline_symbols.txt be
> > >somehow updated?
> > >
> > >
> > Yes, probably we should concentrate on that failure. It's the most
> > strange, probably, because Benjamin and Jakub (certainly a Sparc expert)
> > updated the sparc-linux baseline around mid of June. Maybe we should
> > involve Jakub too in the discussion, at least to confirm that on his
> > sparc-linux machines abi_check doesn't fail.
> 
> The best would be if Christian could post (bzip2ed) readelf -Ws of
> the libstdc++.so that fails the abi_check.

sure, attached, this is with HJ's binutils-2.16.90.0.3-1 for linux
tarball test release rpm built for corona.

again, would you rather I backed off to a binutils-2.15.92.0.2-5?

-- 
Cheers,

/ChJ

[-- Attachment #2: libstdc++.so.6.0.5-readelf-Ws.log.bz2 --]
[-- Type: application/x-bzip2, Size: 65020 bytes --]

Re: sparc-linux results for 4.0.1 RC3

[Eric Botcazou]

> sure, attached, this is with HJ's binutils-2.16.90.0.3-1 for linux
> tarball test release rpm built for corona.
>
> again, would you rather I backed off to a binutils-2.15.92.0.2-5?

I think it would be better to use Binutils releases when testing GCC releases, 
because that's what the users are supposed to do.  Binutils 2.16.x work fine 
on SPARC/Solaris so I presume they would work just fine on Linux too.

-- 
Eric Botcazou

Re: sparc-linux results for 4.0.1 RC3

[Matthias Klose]

Paolo Carlini writes:
> Eric Botcazou wrote:
> 
> >>hmm, I get a few libstdc++ testsuite failuers....
> >>
> >>http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
> >>
> >>other than that, looks pretty fine.
> >>    
> >>
> >Did you get them with 4.0.0 too?  If no, the libstdc++ folks will have to say 
> >whether they are really regressions (the testsuite harness has changed).
> >
> Yes, I would definitely encourage a little more analysis. I'm rather
> puzzled. We have got very nice testsuites on sparc-solaris and on
> *-linux, in general, and those failures certainly are not expected.
> However, missing additional details, it's very difficult to guess: can
> be almost anything, from a weirdness in the installed localedata to a
> defect of the testsuite harness, to a code generation bug, to a latent
> bug in the generic code of the library exposed only by that target, and
> only now.

I don't see these regression on Debian unstable, not exactly built
from the snapshot, but from CVS at the same date. Test results at

http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00280.html

However, there are 8 gfortran regressions, compared to 4.0.0:

FAIL: gfortran.dg/f2c_2.f90  -O0  execution test
FAIL: gfortran.dg/f2c_2.f90  -O1  execution test
FAIL: gfortran.dg/f2c_2.f90  -O2  execution test
FAIL: gfortran.dg/f2c_2.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/f2c_2.f90  -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: gfortran.dg/f2c_2.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/f2c_2.f90  -O3 -g  execution test
FAIL: gfortran.dg/f2c_2.f90  -Os  execution test