Re: GCC 4.2.0 RC3 Available
Hi, On Wed, May 02, 2007 at 01:34:18PM -0700, Mark Mitchell wrote: > GCC 4.2.0 RC3 is now available from: Successfully built on s390 and s390x: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00142.html http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00143.html Bye, -Andreas-
Re: GCC 4.2.0 RC3 Available
On 5/6/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> 2007-05-05 Richard Guenther <[EMAIL PROTECTED]>
>
>* doc/install.texi (--disable-stage1-checking): Document.
> [EMAIL PROTECTED] --disable-stage1-checking
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> +Regardless of what is specified with @samp{--enable-checking} the
> +stage1 compiler is built with checking enabled. For small or slow
> +systems you can disable checking for stage1 using
> [EMAIL PROTECTED]
Minor editing:
"By default, the Stage 1 compiler is built with checking enabled, even
if @option{--disable-checking} is used. If your system is too slow or
too small to bootstrap the compiler with checking enabled, you can use
@option{--disable-stage1-checking} to disable checking for the Stage 1
compiler."
Note, in particular, that you should use @option rather than @samp.
This patch is OK for 4.2 and mainline, assuming that someone verifies
that the switch actually performs as advertised.
I have verified that on the branch
- without any checking option defined we build stage1 with checking=yes
and further stages with release checking
- with --enable-checking=release we build all stages with release checking
- with --disable-stage1-checking we build stage1 with --disable-checking
and further stages with release checking
- with --enable-stage1-checking=release we build stage1 with release checking
So,
2007-05-05 Richard Guenther <[EMAIL PROTECTED]>
* doc/install.texi (--enable-checking): Mention different
default for stage1.
(--enable-stage1-checking): Document.
disables1c
Description: Binary data
Re: GCC 4.2.0 RC3 Available
Richard Guenther wrote:
> 2007-05-05 Richard Guenther <[EMAIL PROTECTED]>
>
>* doc/install.texi (--disable-stage1-checking): Document.
> [EMAIL PROTECTED] --disable-stage1-checking
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> +Regardless of what is specified with @samp{--enable-checking} the
> +stage1 compiler is built with checking enabled. For small or slow
> +systems you can disable checking for stage1 using
> [EMAIL PROTECTED]
Minor editing:
"By default, the Stage 1 compiler is built with checking enabled, even
if @option{--disable-checking} is used. If your system is too slow or
too small to bootstrap the compiler with checking enabled, you can use
@option{--disable-stage1-checking} to disable checking for the Stage 1
compiler."
Note, in particular, that you should use @option rather than @samp.
This patch is OK for 4.2 and mainline, assuming that someone verifies
that the switch actually performs as advertised.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: GCC 4.2.0 RC3 Available
On 5/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote: On 5/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > On 5/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > Richard Guenther wrote: > > > > >> > Another problem is that --enable-checking hasn't been set to 'release', > > >> > so the stage1 binary is too big to run on my ARM systems (and the > > >> > compiler will be unnecessarily slower than it needs to be). > > > > >> Are you sure that we're not building with release-checking only? > > > > > > stage1 is always built with checking enabled. > > > > OK. There's a good chance that both Richard E. and I didn't realize > > that (it didn't use to be true). So, from what you're saying, there > > doesn't seem to be an evidence that this is a real problem. > > > > Do we build stage1 with checking enabled even if --disable-checking is > > in effect? Otherwise, how to do folks like Richard E. that are running > > natively on small systems work around this issue? > > Specifying --disable-stage1-checking should work. (it's in the toplevel > configure) I see this is not documented, though :/ Richard, can you check if it actually works? And if it does, the following patch documents it. Ok for the branch? Richard. 2007-05-05 Richard Guenther <[EMAIL PROTECTED]> * doc/install.texi (--disable-stage1-checking): Document. disables1c Description: Binary data
Re: GCC 4.2.0 RC3 Available
On 5/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote: On 5/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >> > Another problem is that --enable-checking hasn't been set to 'release', > >> > so the stage1 binary is too big to run on my ARM systems (and the > >> > compiler will be unnecessarily slower than it needs to be). > > >> Are you sure that we're not building with release-checking only? > > > > stage1 is always built with checking enabled. > > OK. There's a good chance that both Richard E. and I didn't realize > that (it didn't use to be true). So, from what you're saying, there > doesn't seem to be an evidence that this is a real problem. > > Do we build stage1 with checking enabled even if --disable-checking is > in effect? Otherwise, how to do folks like Richard E. that are running > natively on small systems work around this issue? Specifying --disable-stage1-checking should work. (it's in the toplevel configure) I see this is not documented, though :/ Richard, can you check if it actually works? Thanks, Richard.
Re: GCC 4.2.0 RC3 Available
On 5/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: >> > Another problem is that --enable-checking hasn't been set to 'release', >> > so the stage1 binary is too big to run on my ARM systems (and the >> > compiler will be unnecessarily slower than it needs to be). >> Are you sure that we're not building with release-checking only? > > stage1 is always built with checking enabled. OK. There's a good chance that both Richard E. and I didn't realize that (it didn't use to be true). So, from what you're saying, there doesn't seem to be an evidence that this is a real problem. Do we build stage1 with checking enabled even if --disable-checking is in effect? Otherwise, how to do folks like Richard E. that are running natively on small systems work around this issue? Specifying --disable-stage1-checking should work. (it's in the toplevel configure) Richard.
Re: GCC 4.2.0 RC3 Available
Richard Guenther wrote: >> > Another problem is that --enable-checking hasn't been set to 'release', >> > so the stage1 binary is too big to run on my ARM systems (and the >> > compiler will be unnecessarily slower than it needs to be). >> Are you sure that we're not building with release-checking only? > > stage1 is always built with checking enabled. OK. There's a good chance that both Richard E. and I didn't realize that (it didn't use to be true). So, from what you're saying, there doesn't seem to be an evidence that this is a real problem. Do we build stage1 with checking enabled even if --disable-checking is in effect? Otherwise, how to do folks like Richard E. that are running natively on small systems work around this issue? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 RC3 Available
On 5/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Richard Earnshaw wrote: >> Mark Mitchell wrote: >>> GCC 4.2.0 RC3 is now available from: >>> >>> ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 >>> >>> This build now contains the fixes for the Ada build problem present in RC2. >>> >>> At this point, I have no plans for an RC4. However, I am reviewing the >>> various open issues, and available patches, so I might change my mind >>> about that. > > Another problem is that --enable-checking hasn't been set to 'release', > so the stage1 binary is too big to run on my ARM systems (and the > compiler will be unnecessarily slower than it needs to be). That's a serious issue. But, I'm confused: gcc/DEV-PHASE on the branch is set to "prerelease", and, in the auto-host.h file from the build that gets done as part of the prerelease tarball-building script, I see: /* Define if you want the garbage collector to do object poisoning and other memory allocation checks. This is quite expensive. */ #ifndef USED_FOR_TARGET /* #undef ENABLE_GC_CHECKING */ #endif which looks like GC-checking has indeed been turned off, which is consistent with gcc/configure.ac detecting that we're in release mode. Are you sure that we're not building with release-checking only? stage1 is always built with checking enabled. Richard.
Re: GCC 4.2.0 RC3 Available
Richard Earnshaw wrote: >> Mark Mitchell wrote: >>> GCC 4.2.0 RC3 is now available from: >>> >>> ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 >>> >>> This build now contains the fixes for the Ada build problem present in RC2. >>> >>> At this point, I have no plans for an RC4. However, I am reviewing the >>> various open issues, and available patches, so I might change my mind >>> about that. > > Another problem is that --enable-checking hasn't been set to 'release', > so the stage1 binary is too big to run on my ARM systems (and the > compiler will be unnecessarily slower than it needs to be). That's a serious issue. But, I'm confused: gcc/DEV-PHASE on the branch is set to "prerelease", and, in the auto-host.h file from the build that gets done as part of the prerelease tarball-building script, I see: /* Define if you want the garbage collector to do object poisoning and other memory allocation checks. This is quite expensive. */ #ifndef USED_FOR_TARGET /* #undef ENABLE_GC_CHECKING */ #endif which looks like GC-checking has indeed been turned off, which is consistent with gcc/configure.ac detecting that we're in release mode. Are you sure that we're not building with release-checking only? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 RC3 Available
GCC 4.2.0 RC3 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 It does not build LLVM there seems to be a stdlib++ problem. I cannot really file a BugZilla report as I have not distilled the code down to make an accurate report. Luckily it was just a local library file selection problem. LLVM and LLVM-GCC4 build on GCC 4.2.0 RC3. Aaron
Re: GCC 4.2.0 RC3 Available
GCC 4.2.0 RC3 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 It does not build LLVM there seems to be a stdlib++ problem. I cannot really file a BugZilla report as I have not distilled the code down to make an accurate report. Aaron
Re: GCC 4.2.0 RC3 Available
> Mark Mitchell wrote: > > GCC 4.2.0 RC3 is now available from: > > > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 > > > > This build now contains the fixes for the Ada build problem present in RC2. > > > > At this point, I have no plans for an RC4. However, I am reviewing the > > various open issues, and available patches, so I might change my mind > > about that. Another problem is that --enable-checking hasn't been set to 'release', so the stage1 binary is too big to run on my ARM systems (and the compiler will be unnecessarily slower than it needs to be). R.
Re: GCC 4.2.0 RC3 Available
Mark Mitchell wrote: GCC 4.2.0 RC3 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 This build now contains the fixes for the Ada build problem present in RC2. At this point, I have no plans for an RC4. However, I am reviewing the various open issues, and available patches, so I might change my mind about that. Please see: http://gcc.gnu.org/ml/gcc/2007-05/msg00032.html for information about reporting problems. Please see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31807 A bootstrap failure from the RC3 tarball on mipsel-unknown-linux-gnu David Daney
Re: GCC 4.2.0 RC3 Available
Mark Mitchell wrote: Joel Sherrill wrote: Ralf encountered problems on the avr and bfin during the tool build and has filed or updated PRs for those. Understood, and thnanks for testing! I should make clear that I don't see release candidates as opportunities for general testing; they're final release candidates, not alpha releases. The open nature of GCC development means that testing by stakeholders can (and should) be done well before this point. The testing of release candidates should be generally to confirm expected behavior: do the results that you saw the last time you ran tests, against an SVN checkout, match what you see today, with a release tarball? To be honest we did a lot more testing against pre 4.1 SVN code than against pre 4.2. All the talk about 4.2 being in bad shape on primary targets made us leary. Plus we had our own project's fish to fry. :) I don't see any problems at this point though except on the avr and bfin. This is in no way a criticism, or a comment on RETMS testing (about which I know almost nothing), etc.; just a general comment, which your message gave me the excuse to make. :-) No criticism taken. If someone wants to volunteer to help us improve our testing of gcc, we have ideas which would be mutually beneficial to both RTEMS and gcc. If there is bandwidth and a volunteer to help, it would be a good candidate for the Compile Farm. It just takes a lot of build time for us to get a test toolset in place and test it. We build gcc C/C++ RPMs for about 10-12 targets including newlib. That ends up generating 70 libc.a instances once installed. Then we build RTEMS, common add-on packages, and examples for over 100 multilib and board specific configurations. wc reports that source base as about 915K lines of code. It's just a matter of human time and machine time. Both are in short supply. :) --joel Thanks,
Re: GCC 4.2.0 RC3 Available
Joel Sherrill wrote: > Ralf encountered problems on the avr and bfin during the tool > build and has filed or updated PRs for those. Understood, and thnanks for testing! I should make clear that I don't see release candidates as opportunities for general testing; they're final release candidates, not alpha releases. The open nature of GCC development means that testing by stakeholders can (and should) be done well before this point. The testing of release candidates should be generally to confirm expected behavior: do the results that you saw the last time you ran tests, against an SVN checkout, match what you see today, with a release tarball? This is in no way a criticism, or a comment on RETMS testing (about which I know almost nothing), etc.; just a general comment, which your message gave me the excuse to make. :-) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 RC3 Available
The RTEMS community is still building and trying to test RC2. We always build with newlib. Ralf encountered problems on the avr and bfin during the tool build and has filed or updated PRs for those. I am now building the complete RTEMS source tree and tests for every board and multilib. The build is probably about 1/3 of the way through and so far, I have not encountered any problems. I have a lot left to build though and haven't actually run an executable yet. --joel Mark Mitchell wrote: GCC 4.2.0 RC3 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 This build now contains the fixes for the Ada build problem present in RC2. At this point, I have no plans for an RC4. However, I am reviewing the various open issues, and available patches, so I might change my mind about that. Please see: http://gcc.gnu.org/ml/gcc/2007-05/msg00032.html for information about reporting problems. Thanks,
GCC 4.2.0 RC3 Available
GCC 4.2.0 RC3 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 This build now contains the fixes for the Ada build problem present in RC2. At this point, I have no plans for an RC4. However, I am reviewing the various open issues, and available patches, so I might change my mind about that. Please see: http://gcc.gnu.org/ml/gcc/2007-05/msg00032.html for information about reporting problems. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
