GCC-3.2.2 pre-release (second iteration)

GCC-3.2.2 pre-release (second iteration)

[Gabriel Dos_Reis]

I uploaded 3.2.2 pre-release (second iteration) tarballs on the FTP
server as

     ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-*3.2.2-20030129.*

As usual, please donwload and test them.  Report problems to me and
fill GNATS  PRs.

Unfortunately these tarballs are missing some RTEMS fixes.  They will
get in for the third (and hopefully final) iteration.

Thanks,

-- Gaby

Re: GCC-3.2.2 pre-release (second iteration)

[Joe Buck]

On Wed, Jan 29, 2003 at 04:25:34PM +0100, Gabriel Dos_Reis wrote:
 
> I uploaded 3.2.2 pre-release (second iteration) tarballs on the FTP
> server as
> 
>      ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-*3.2.2-20030129.*
> 
> As usual, please donwload and test them.  Report problems to me and
> fill GNATS  PRs.

I just tested on GNU/Linux, and I am seeing new failures since yesterday's
tarball (yesterday I had no unexpected gcc or g++ failures, and now
there are a total of 11, from 5 distinct tests).  See

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

It's an "up2date" Red Hat 7.2 box with binutils-2.13.1.

Could someone else run the tests and try to verify this?

Re: GCC-3.2.2 pre-release (second iteration)

[Paolo Carlini]

Joe Buck wrote:

>I just tested on GNU/Linux, and I am seeing new failures since yesterday's
>tarball (yesterday I had no unexpected gcc or g++ failures, and now
>there are a total of 11, from 5 distinct tests).  See
>
>http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01306.html
>
>It's an "up2date" Red Hat 7.2 box with binutils-2.13.1.
>
>Could someone else run the tests and try to verify this?
>
I'm also seeing those failures, unfortunately, and also:

    FAIL: g++.eh/spec6.C (test for excess errors)

Paolo.

P.S. binutils-2.13.2, glibc-2.3.1

Re: GCC-3.2.2 pre-release (second iteration)

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

| On Wed, Jan 29, 2003 at 04:25:34PM +0100, Gabriel Dos_Reis wrote:
|  
| > I uploaded 3.2.2 pre-release (second iteration) tarballs on the FTP
| > server as
| > 
| >      ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-*3.2.2-20030129.*
| > 
| > As usual, please donwload and test them.  Report problems to me and
| > fill GNATS  PRs.
| 
| I just tested on GNU/Linux, and I am seeing new failures since yesterday's
| tarball (yesterday I had no unexpected gcc or g++ failures, and now
| there are a total of 11, from 5 distinct tests).  See
| 
| http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01306.html

Numbers from 

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

are indicating something different -- which puzzles me.  
I just ran a full bootstrap + regression testsuite and saw two
failures related to C99 format specifiers on en i868-pc-linux-gnu.

I'm bootstrapping on another host.  

I'll keep you informed as things evolve.

-- Gaby

Re: GCC-3.2.2 pre-release (second iteration)

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

| On Wed, Jan 29, 2003 at 04:25:34PM +0100, Gabriel Dos_Reis wrote:
|  
| > I uploaded 3.2.2 pre-release (second iteration) tarballs on the FTP
| > server as
| > 
| >      ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-*3.2.2-20030129.*
| > 
| > As usual, please donwload and test them.  Report problems to me and
| > fill GNATS  PRs.
| 
| I just tested on GNU/Linux, and I am seeing new failures since yesterday's
| tarball (yesterday I had no unexpected gcc or g++ failures, and now
| there are a total of 11, from 5 distinct tests).  See
| 
| http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01306.html
| 
| It's an "up2date" Red Hat 7.2 box with binutils-2.13.1.
| 
| Could someone else run the tests and try to verify this?

Paolo Carlini <pcarlini@unitus.it> writes:

| I'm also seeing those failures, unfortunately, and also:
| 
|     FAIL: g++.eh/spec6.C (test for excess errors)

Joe, Paolo --

I'm also seeing those failures with the tarball I uploaded but not 
on current version of gcc-3_2-branch (which will be the next
iteration).  

I looked into the failures and cannot find out which patches could
have possibly caused those failures.  All failures seem to be
"syntax error".  I'm inclined to conlude that the environment I used
to prepare the second iteration (which is at work) might be insane [it
is the one which started the reduce/reduce conflit thread]. 

I would like you run the testsuite again but for current CVS
gcc-3_2-branch and report the results.  Thank you very much for your
time.  

-- Gaby

Bison-1.875, again! (Re: GCC-3.2.2 pre-release (second iteration))

[Paolo Carlini]

Gabriel Dos Reis wrote:

>I would like you run the testsuite again but for current CVS
>gcc-3_2-branch and report the results.  Thank you very much for your
>time.
>
Hi Gaby!

Everything is clear, now. I'm still seeing those spurious regressions, 
to wit

FAIL: gcc.dg/cpp/assert_trad2.c  (test for errors, line 13)
FAIL: gcc.dg/cpp/assert_trad2.c  (test for errors, line 16)
FAIL: gcc.dg/cpp/assert_trad2.c bad syntax (test for errors, line 23)
FAIL: gcc.dg/cpp/assert_trad2.c (test for excess errors)
FAIL: gcc.dg/cpp/direct2s.c not a comment (test for errors, line 38)
FAIL: gcc.dg/cpp/direct2s.c (test for excess errors)

FAIL: g++.dg/lookup/using2.C  (test for errors, line 28)
FAIL: g++.dg/lookup/using2.C  (test for errors, line 44)
FAIL: g++.dg/lookup/using2.C (test for excess errors)
XPASS: g++.dg/parse/angle-bracket.C  (test for bogus messages, line 7)
FAIL: g++.dg/parse/angle-bracket.C (test for excess errors)
FAIL: g++.dg/template/typename3.C (test for excess errors)

but they are *all* due to the Bison version I'm using: the very same issue
("parse error" -> "syntax error") that a few days ago led me to propose a
patch for mainline. For some reason, the current 3.2.2 branch when fed the
C testsuite triggers few more new posix "syntax error" from the 
Bison-generated
parser than mainline (and also some C++ ones which, of course are not 
relevant
for mainline). For instance:

--- 3_2_1       2003-01-31 02:13:21.000000000 +0100
+++ 3_2_2-bison-1_875   2003-01-31 02:13:08.000000000 +0100
@@ -4,7 +4,7 @@
 assert_trad2.c:8: missing '(' after predicate
 assert_trad2.c:10: assertion without predicate
 assert_trad2.c:13: predicate must be an identifier
-assert_trad2.c:13: parse error
+assert_trad2.c:13: syntax error
 assert_trad2.c:16: predicate must be an identifier
-assert_trad2.c:16: parse error
-assert_trad2.c:23: parse error
+assert_trad2.c:16: syntax error
+assert_trad2.c:23: syntax error

In my opinion, a testsuite fix very similar to mine of a few days ago should
be applied to those testcases. If you want, I can work on this tomorrow...

Paolo.

Re: Bison-1.875, again! (Re: GCC-3.2.2 pre-release (second iteration))

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@unitus.it> writes:

[...]

| In my opinion, a testsuite fix very similar to mine of a few days ago should
| be applied to those testcases. If you want, I can work on this tomorrow...

Thank you very much for this detailed analysis.  I also accpet you offer.
That will make it possible for me to look at other queued patches.

Since we're in the same timezone, I understand what you're going to do
now and I guess you understand what I would like to do now (but it is
too late ;-).

-- Gaby

Re: GCC-3.2.2 pre-release (second iteration)

[Joe Buck]

On Fri, Jan 31, 2003 at 01:22:31AM +0100, Gabriel Dos Reis wrote:
> I would like you run the testsuite again but for current CVS
> gcc-3_2-branch and report the results.  Thank you very much for your
> time.  

I've been having trouble with subversions.gnu.org's CVS server today;
"cvs update" hangs indefinitely halfway through.  After repeated attempts
I think I have a 3_2_branch copy that is caught up, but I cannot
get contrib/gcc_update to complete.  I've never had this difficulty
before.

Any ideas?

Re: GCC-3.2.2 pre-release (second iteration)

[Greg Schafer]

On Fri, Jan 31, 2003 at 01:22:31AM +0100, Gabriel Dos Reis wrote:
> I'm also seeing those failures with the tarball I uploaded but not 
> on current version of gcc-3_2-branch (which will be the next
> iteration).  
> 
> I looked into the failures and cannot find out which patches could
> have possibly caused those failures.  All failures seem to be
> "syntax error".  I'm inclined to conlude that the environment I used
> to prepare the second iteration (which is at work) might be insane [it
> is the one which started the reduce/reduce conflit thread]. 
> 
> I would like you run the testsuite again but for current CVS
> gcc-3_2-branch and report the results.  Thank you very much for your
> time.  

Gabriel, just a heads up. the tarball does indeed appear to be broken.

Building from the tarball shows the failures whereas building from CVS is
fine for me:-

tarball:
http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01382.html

CVS:
http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01325.html


It is probably the bison thing as Paolo suggested. But I thought the
maintainer scripts were supposed to adjust the timestamps so as not to rely
on the bison in the user's environment. Dunno.

Greg

Re: GCC-3.2.2 pre-release (second iteration)

[Gabriel Dos Reis]

Greg Schafer <gschafer@zip.com.au> writes:

[...]

| Building from the tarball shows the failures whereas building from CVS is
| fine for me:-
| 
| tarball:
| http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01382.html
| 
| CVS:
| http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01325.html

Thanks for piece of information. 

| It is probably the bison thing as Paolo suggested. But I thought the
| maintainer scripts were supposed to adjust the timestamps so as not to rely
| on the bison in the user's environment. Dunno.

I believe that the maintainer scripts aren't that smart :-(

-- Gaby

Re: GCC-3.2.2 pre-release (second iteration)

[Joe Buck]

Greg Schafer <gschafer@zip.com.au> writes:
> | It is probably the bison thing as Paolo suggested. But I thought the
> | maintainer scripts were supposed to adjust the timestamps so as not to rely
> | on the bison in the user's environment. Dunno.

On Fri, Jan 31, 2003 at 02:34:34AM +0100, Gabriel Dos Reis wrote:
> I believe that the maintainer scripts aren't that smart :-(

In that case, run

contrib/gcc_update --touch

before making tarballs.  This will update the times of dependent files
to be newer than those that are depended on (I'm not certain if it
gets everything, but it can't hurt).

Re: GCC-3.2.2 pre-release (second iteration)

[Joseph S. Myers]

On Thu, 30 Jan 2003, Joe Buck wrote:

> In that case, run
> 
> contrib/gcc_update --touch
> 
> before making tarballs.  This will update the times of dependent files
> to be newer than those that are depended on (I'm not certain if it
> gets everything, but it can't hurt).

The release script already runs contrib/gcc_update --touch.

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

Re: GCC-3.2.2 pre-release (second iteration)

[Gabriel Dos Reis]

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

| On Thu, 30 Jan 2003, Joe Buck wrote:
| 
| > In that case, run
| > 
| > contrib/gcc_update --touch
| > 
| > before making tarballs.  This will update the times of dependent files
| > to be newer than those that are depended on (I'm not certain if it
| > gets everything, but it can't hurt).
| 
| The release script already runs contrib/gcc_update --touch.

Then I'm wondering why things went wrong...

-- Gaby

Re: GCC-3.2.2 pre-release (second iteration)

[Joe Buck]

On Fri, Jan 31, 2003 at 01:53:18PM +0100, Gabriel Dos Reis wrote:
> "Joseph S. Myers" <jsm28@cam.ac.uk> writes:
> 
> | On Thu, 30 Jan 2003, Joe Buck wrote:
> | 
> | > In that case, run
> | > 
> | > contrib/gcc_update --touch
> | > 
> | > before making tarballs.  This will update the times of dependent files
> | > to be newer than those that are depended on (I'm not certain if it
> | > gets everything, but it can't hurt).
> | 
> | The release script already runs contrib/gcc_update --touch.
> 
> Then I'm wondering why things went wrong...

Just a guess: you applied a patch that modified a parser, then you did a
build to test it.  This build picked up your version of bison.
contrib/gcc_update --touch only does a touch.

Re: GCC-3.2.2 pre-release (second iteration)

[Joseph S. Myers]

On 31 Jan 2003, Gabriel Dos Reis wrote:

> | The release script already runs contrib/gcc_update --touch.
> 
> Then I'm wondering why things went wrong...

They didn't.  gcc_update --touch has nothing to do with Bison generated
files since they're not in CVS and gcc_update deals with files in CVS; the
timestamps on Bison-generated files are correct by virtue of being
generated in a build after the tree has been checked out and gcc_update
--touch run.  The only thing that could be considered "wrong" is having
Bison 1.875 installed when generating the prerelease, which necessitates
the "syntax error" testsuite changes, rather than an older version that's
been tested for longer with the 3.2 series (e.g., whatever version was
used for the 3.2.1 release).

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

Re: GCC-3.2.2 pre-release (second iteration)

[Gabriel Dos Reis]

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

[...]

| --touch run.  The only thing that could be considered "wrong" is having
| Bison 1.875 installed when generating the prerelease, which necessitates
| the "syntax error" testsuite changes, rather than an older version that's
| been tested for longer with the 3.2 series (e.g., whatever version was
| used for the 3.2.1 release).

Firstly, there is no way I could have known that GCC's testsuite will be
affected by recent version of Bison as there is no mention of which
Bison should be used for GCC (pre)releases.

Secondly, I used my office environment -- not because I wanted to be
facetious -- but because it provided better connectivity than my 
poor ADSL connection I had at home.

-- Gaby

Re: GCC-3.2.2 pre-release (second iteration)

[Joe Buck]

On Sat, Feb 01, 2003 at 05:19:08PM +0100, Gabriel Dos Reis wrote:
> | --touch run.  The only thing that could be considered "wrong" is having
> | Bison 1.875 installed when generating the prerelease, which necessitates
> | the "syntax error" testsuite changes, rather than an older version that's
> | been tested for longer with the 3.2 series (e.g., whatever version was
> | used for the 3.2.1 release).
> 
> Firstly, there is no way I could have known that GCC's testsuite will be
> affected by recent version of Bison as there is no mention of which
> Bison should be used for GCC (pre)releases.

It's a good thing that you discovered this, actually.

Others won't know this either, so it will be a good thing to fix the tests
so that they won't be broken if they see "syntax error" instead of "parse
error".
 

Re: GCC-3.2.2 pre-release (second iteration)

[Greg Schafer]

On Fri, Jan 31, 2003 at 02:34:34AM +0100, Gabriel Dos Reis wrote:
> Greg Schafer <gschafer@zip.com.au> writes:
> 
> [...]
> 
> | Building from the tarball shows the failures whereas building from CVS is
> | fine for me:-
> | 
> | tarball:
> | http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01382.html
> | 
> | CVS:
> | http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01325.html
> 
> Thanks for piece of information. 
> 
> | It is probably the bison thing as Paolo suggested. But I thought the
> | maintainer scripts were supposed to adjust the timestamps so as not to rely
> | on the bison in the user's environment. Dunno.
> 
> I believe that the maintainer scripts aren't that smart :-(

Just one more piece of info for you:-


tarball:
gcc/c-parse.c  says   /* A Bison parser, made by GNU Bison 1.875.  */

CVS
gcc/c-parse-c  says   /* A Bison parser, made from c-parse.y
                         by GNU bison 1.35.  */


I have bison 1.75 installed on my system, In other words, when I compile from
CVS, gcc/c-parse.c is not being regenerated (like I would expect). The
gcc_update script is adjusting the timestamps for the generated files for
me. I wonder why this is not true for your build environment?

Greg

Re: GCC-3.2.2 pre-release (second iteration)

[Gabriel Dos Reis]

Greg Schafer <gschafer@zip.com.au> writes:

[...]

| me. I wonder why this is not true for your build environment?

That i probably because I wasn't running gcc_update as suggested by
Joe.

Thanks to both of you.

-- Gaby

Re: GCC-3.2.2 pre-release (second iteration)

[Joseph S. Myers]

On 31 Jan 2003, Gabriel Dos Reis wrote:

> | It is probably the bison thing as Paolo suggested. But I thought the
> | maintainer scripts were supposed to adjust the timestamps so as not to rely
> | on the bison in the user's environment. Dunno.
> 
> I believe that the maintainer scripts aren't that smart :-(

The maintainer scripts work fine.  The tarballs generated by the release
script include Bison-generated files generated by the person who ran the
script; when a user builds the tarball, the version of Bison they have is
irrelevant as the timestamps are correct.  When building from CVS, the
user's Bison version is relevant - but the Bison-generated files will only
be regenerated when the source file changes in CVS, not when you upgrade
Bison if the source file doesn't change.  Bison-generated files do not go
in CVS.

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

Re: GCC-3.2.2 pre-release (second iteration)

[Paolo Carlini]

Joseph S. Myers wrote:

>... but the Bison-generated files will only
>be regenerated when the source file changes in CVS, not when you upgrade
>Bison if the source file doesn't change.
>
Thanks for the clarification, I didn't know that.

Paolo.

Re: GCC-3.2.2 pre-release (second iteration)

[Volker Reichelt]

Hi Gaby,

in the first iteration there was an entry for "./.brik" in ".brik" which
(of course) caused the check with brik to fail. This was fixed (i.e. the
entry was removed) in the second iteration. But since I'm not sure
whether this was on purpose or just accidentally, I just wanted to let
you know.

Regards,
Volker

Re: GCC-3.2.2 pre-release (second iteration)

[Gabriel Dos_Reis]

| Hi Gaby,
| 
| in the first iteration there was an entry for "./.brik" in ".brik" which
| (of course) caused the check with brik to fail. This was fixed (i.e. the
| entry was removed) in the second iteration. But since I'm not sure
| whether this was on purpose or just accidentally, I just wanted to let
| you know.

Thanks for the update.  Yes, I now remember something went wrong with
brik in the first iteration; I though I fixed.  I'm glad to see it is
no longer an issue.

Thanks,

-- Gaby