GCC 3.0 Status Report

GCC 3.0 Status Report

[Mark Mitchell]

GCC 3.0 Status Report
=====================

Timing
------

There are 4 days until the scheduled release of GCC 3.0.

Announcement
------------

As of now, *all* non-documentation patches to the GCC 3.0 release
branch must be approved by me prior to check-in, without exception.
It would still be very helpful to me if the usual reviewers would
continue review the patches.  For example, if Alexandre would review a
configury change and say "this looks correct" that will make it much
easier for me to decide what to do.

As the week goes by, I will be less and less likely to approve
changes, especially changes whose impact is not confined to a single
target.  If a bug is theoretically cross-platform, but is only
actually showing up on one chip, we can use the `#if TARGET_FOO'
around the change in generic code in order to reduce the risk.
Obviously, this is not our normal practice, but it makes sense in this
timeframe.  It is my goal to have no check-ins after Wednesday -- but
of course the point of waiting until midnight Friday will be to see if
there is anything more we need to do.  Check-ins after Wednesday are
likely to result in a slip of our ship date.

Anyone who would normally be able to approve documentation patches may
continue to do so, through the end of 14th, GMT -0800.

If there are issues that you think absolutely must be fixed before the
release, but are not yet high-priority GNATS bugs, here is what you
should do:

  1. Make sure that the bug report is filed in GNATS.  I will not
     consider any item which does not have a GNATS report.

  2. Send me an email indicating why you think this is an 
     absolutely critical bug.  It *must* be a regression from
     GCC 2.95, and it must affect users in a particularly dire 
     way.
 
     Please explicitly name me in the `To' or `Cc' fields; there
     is so much list traffic that I might otherwise miss your
     message.

Prerelease
----------

I have created new prerelease tarballs.  Remember that the actual
release will be generated by the same script; these tarballs are
designed to perform all packaging functions that will be required for
GCC 3.0.  If you find problems with the packaging, please follow the
procedures above for reporting high-priority bugs.

The new prerelease tarballs are:

  ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-3.0-20010611.tar.gz

and the similarly-named language-specific tarballs.

Please try them out.

Overview
--------

I am tremendously pleased with the number of bug reports that have
been closed since last week.  There are now only 14 remaining open
high-priority PRs, down from 68 last week.

Obviously, we have had more upheaval over the weekend, particularly in
the C++ library, than would have been ideal.  This reflects the nature
of this release, i.e., that is a release of brand new technology,
including a brand new C++ library.  It is important that everyone
remember that this is a `.0' release, and as such we must all expect
more problems than in a release that contains fewer changes.  We will
have follow-on releases in short order to fix critical bugs.

At this point, I do not anticpate delaying the release of GCC 3.0.
There is a possibility that the release will be delayed, by a matter
of a few days.  The final go/no-go decision will be based on my
perception of where we are, how much more we could achieve with very
little work, and whether or not that work would likely be
destabilizing.

Looking Forward
---------------

I am beginning to think about GCC 3.0.1 and GCC 3.1.  It is my goal to
get us, finally, on a regular schedule of quarterly major releases.  I
will present my ideas for how to achieve this to the GCC Steering
Committee this week or very early next week.  I anticipate that a
decision will be made within a couple of weeks.

Issues
------

Here is a summary of the open issues.  If you can help with any of
these please do!

CNI: Using gcj's CNI requires an explict -I switch to the compiler.
     I downgraded this PR, since that seems to be the
     consensus.  This is not a showstopper: there is a simple 
     workaround.

C++: There is an apparent strict-aliasing problem on Alpha.  I will
     try to track this down today.  PR 2758.

C++: Nathan is fixing/has fixed more problems in vtable layout.
     PR3089.

EH: Loren has patches to fix EH in the presence of threading that
    need to be moved from the mainline to the branch.  PR3082.

Reload: This is PR2876.  Bernd attempted to fix this, but the 
        patch broke IRIX.  We should try again.

Configury: In-source builds do not work.  Tom, are you still working
	   on this?  If not, please let me know so that someone
	   else can take it over.

ARM: There are still multiple ARM regressions from GCC 2.95.  There
     is still time to fix them -- but we must act extremely quickly.
     These are bugs 3037, 3053, 2878, and 817.

H8:  PR2866 looks like it might have a very simple fix that would
     only require tweaking the H8 configuration file.

AIX: David has elected not to fix this bug for this release.
     Hopefully, it will be fixed in 3.0.1.  PR3042.

68K: Bootstrap problem.  PR1795.  If this is not fixed soon, it 
     can wait for 3.0.1.

Re: GCC 3.0 Status Report

[Loren James Rittle]

In article < 20010611214848B.mitchell@codesourcery.com > you write:

> EH: Loren has patches to fix EH in the presence of threading that
>     need to be moved from the mainline to the branch.  PR3082.

For the record, this was already moved to the 3.0 branch back on
2001-06-08, the day after it appeared on mainline.  The move was
approved and encouraged by Benjamin.

I didn't closed the PR until today since I didn't know I had the
ability to directly play with GNATS until today.

Regards,
Loren

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Mon, 11 Jun 2001, Mark Mitchell wrote:

> The new prerelease tarballs are:
> 
>   ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-3.0-20010611.tar.gz
> 
> and the similarly-named language-specific tarballs.
> 
> Please try them out.

Should people run the testsuite from these tarballs with 2.95.3, and send
those results to gcc-testresults?

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

Re: GCC 3.0 Status Report

[Mark Mitchell]

> Should people run the testsuite from these tarballs with 2.95.3, and send
> those results to gcc-testresults?

It certainly won't hurt.  It also won't really work in general --
I know that for G++ a lot of the tests will pass/fail for "silly"
reasons.  In general, we know that the testsuite performance is
OK relative to 2.95.x because we know that we have only XFAILed
tests that were regressions from GCC 2.95.

I am more interested in people building from the tarballs, and
then running the resulting compiler on whatever code is handy.
Still, what you suggest is not a bad idea.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Nathan Sidwell]

Mark Mitchell wrote:

> Configury: In-source builds do not work.  Tom, are you still working
>            on this?  If not, please let me know so that someone
>            else can take it over.
There's a patch from me at
http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00662.html
which gets part of the way there, and is waiting for Alex's
(and now Mark's) approval. BTW, Loren Rittle, who recently
put that gthr stuff in thinks it's ok.

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: GCC 3.0 Status Report

[Tom Tromey]

Mark> Configury: In-source builds do not work.  Tom, are you still
Mark> working on this?  If not, please let me know so that someone
Mark> else can take it over.

Yes, I'm working on it.  I was blocked yesterday by the `gthr.h'
problem -- the build didn't get past libstdc++, and I still don't know
if I can reproduce the problem Nathan reported with the libjava
configure.

Nathan> There's a patch from me at
Nathan> http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00662.html
Nathan> which gets part of the way there, and is waiting for Alex's
Nathan> (and now Mark's) approval. BTW, Loren Rittle, who recently
Nathan> put that gthr stuff in thinks it's ok.

I'll look at applying this and see if that helps me move forward.
Thanks.

Tom

Re: GCC 3.0 Status Report (the ARM bits)

[Richard Earnshaw]

> ARM: There are still multiple ARM regressions from GCC 2.95.  There
>      is still time to fix them -- but we must act extremely quickly.
>      These are bugs 3037, 3053, 2878, and 817.

#817: I've approved Phil's proposed patch for the branch only.  It's not 
the cleanest way to fix the problem, but it does fix it for now.

#2878: I posted a patch last night.  A bootstrap of the gcc directory with 
BOOT_CFLAGS=-g passed with the patch applied, but I've had no further time 
for testing it.

#3037: I suspect fixing this fully may be hard.  One possibility may be to 
(ab)use LOCAL_REGNO to achieve the result we want.  Something like
#define LOCAL_REGNO(X) \
	((reload_in_progress || reload_completed) \
	 && (regs_ever_live[X] && ! call_used_regs[X]))

But I haven't been able to test this much due to other commitments.

#3053: I've not had a chance to try RTH's patch yet.

Re: GCC 3.0 Status Report (the ARM bits)

[Nathan Sidwell]

Richard Earnshaw wrote:

> #3053: I've not had a chance to try RTH's patch yet.
I'm running a C & C++ bootstrap on an ARM box with this patch.

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: GCC 3.0 Status Report (the ARM bits)

[Philip Blundell]

Richard Earnshaw wrote:
>#817: I've approved Phil's proposed patch for the branch only.  It's not 
>the cleanest way to fix the problem, but it does fix it for now.

Mark, can you confirm that you are happy for me to apply this patch to the 
branch?

p.


-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999 (debian)

iD8DBQE7JxdnVTLPJe9CT30RAiIrAJ9bv6wNNM+Jcvr73v/u+CqbvL/XDACgoYQr
vi7gZf7ocqN+wrxM8t1uPsc=
=iQbn
-----END PGP SIGNATURE-----

Re: GCC 3.0 Status Report (the ARM bits)

[Mark Mitchell]

--On Wednesday, June 13, 2001 08:33:59 AM +0100 Philip Blundell 
<philb@gnu.org> wrote:

> Richard Earnshaw wrote:
>> #817: I've approved Phil's proposed patch for the branch only.  It's not
>> the cleanest way to fix the problem, but it does fix it for now.
>
> Mark, can you confirm that you are happy for me to apply this patch to
> the  branch?

Yes, thank you.

Annoyingly, I lost internet connectivity late last evening; fortunately,
it is back.  Sorry for the slow reply.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Joseph S. Myers]

All the Objective C tests fail with --enable-shared if the relevant shared
libraries aren't installed somewhere the dynamic linker searches.  This
isn't a regression, but gives a very bad impression to installers that the
ObjC compiler is completely broken, and I think it ought to be fixed for
3.0.  Could the Objective C maintainer look at this (PR objc/2145)?

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

Re: GCC 3.0 Status Report

[Franz Sirl]

At 12:42 12.06.2001, Joseph S. Myers wrote:
>All the Objective C tests fail with --enable-shared if the relevant shared
>libraries aren't installed somewhere the dynamic linker searches.  This
>isn't a regression, but gives a very bad impression to installers that the
>ObjC compiler is completely broken, and I think it ought to be fixed for
>3.0.  Could the Objective C maintainer look at this (PR objc/2145)?

Well, I did

< http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01394.html >

which fixes the problem for me. I think it's the right approach (same as we 
do for C++), but I would like to have a better method to detect ObjC 
compilation than to check for file extensions.

Franz.

Re: GCC 3.0 Status Report

[Stan Shebs]

Franz Sirl wrote:
> 
> At 12:42 12.06.2001, Joseph S. Myers wrote:
> >All the Objective C tests fail with --enable-shared if the relevant shared
> >libraries aren't installed somewhere the dynamic linker searches.  This
> >isn't a regression, but gives a very bad impression to installers that the
> >ObjC compiler is completely broken, and I think it ought to be fixed for
> >3.0.  Could the Objective C maintainer look at this (PR objc/2145)?
> 
> Well, I did
> 
> < http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01394.html >
> 
> which fixes the problem for me. I think it's the right approach (same as we
> do for C++), but I would like to have a better method to detect ObjC
> compilation than to check for file extensions.

I poked around a bit, but couldn't think of anything better than
what your patch does.  infiles[i].language contains the actual
language to use for each file, but it's not yet set up when
lang_specific_driver is called.

So I'd say to go with what you have, for the branch at least, and
the trunk too if nobody has any other suggestions.

Stan

Re: GCC 3.0 Status Report

[Mark Mitchell]

>
> So I'd say to go with what you have, for the branch at least, and
> the trunk too if nobody has any other suggestions.

If this has not already gone in, I think it is too late.  This is
not-critical functionality in that there are ways for users to
work around the problem.

However, please make sure that we remember to reexamine this issue
after GCC 3.0, for a probably fix in the 3.0.1 release.

Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Franz Sirl]

On Wednesday 13 June 2001 18:39, Mark Mitchell wrote:
> > So I'd say to go with what you have, for the branch at least, and
> > the trunk too if nobody has any other suggestions.
>
> If this has not already gone in, I think it is too late.  This is
> not-critical functionality in that there are ways for users to
> work around the problem.
>
> However, please make sure that we remember to reexamine this issue
> after GCC 3.0, for a probably fix in the 3.0.1 release.

OK, I'll apply it to the mainline only then.

Franz.

Re: GCC 3.0 Status Report

[Bernd Schmidt]

On Mon, 11 Jun 2001, Mark Mitchell wrote:

> Reload: This is PR2876.  Bernd attempted to fix this, but the
>         patch broke IRIX.  We should try again.

I've looked into this.  There's something extremely weird going on in
the mips backend; the reload_outdi pattern generates uninitialized uses
(at least according to the rtl) of regs 64 and 65 (lo/hi).  We end up
with a sequence of

(insn/i 213 437 452 (parallel[
            (set (reg:DI 66 accum)
                (mult:DI (zero_extend:DI (reg:SI 4 a0 [151]))
                    (zero_extend:DI (reg:SI 2 v0 [152]))))
            (clobber (reg:DI 65 lo))
            (clobber (reg:DI 64 hi))
        ] ) 41 {mulsidi3_64bit} (insn_list 211 (insn_list 212 (nil)))
    (nil))

(insn 452 213 454 (set (reg:DI 6 a2)
        (reg:DI 65 lo)) 154 {movdi_internal2} (nil)
    (nil))

It all apparently goes downhill from there.

This needs someone familiar with that target to investigate the mips.md
braindamage.


Bernd

Re: GCC 3.0 Status Report

[Geert Bosch]

On Tue, 12 Jun 2001, Bernd Schmidt wrote:
  I've looked into this.  There's something extremely weird going on in
  the mips backend; the reload_outdi pattern generates uninitialized uses
  (at least according to the rtl) of regs 64 and 65 (lo/hi).  We end up
  with a sequence of
  
  (insn/i 213 437 452 (parallel[
              (set (reg:DI 66 accum)
                  (mult:DI (zero_extend:DI (reg:SI 4 a0 [151]))
                      (zero_extend:DI (reg:SI 2 v0 [152]))))
              (clobber (reg:DI 65 lo))
              (clobber (reg:DI 64 hi))
          ] ) 41 {mulsidi3_64bit} (insn_list 211 (insn_list 212 (nil)))
      (nil))
  
  (insn 452 213 454 (set (reg:DI 6 a2)
          (reg:DI 65 lo)) 154 {movdi_internal2} (nil)
      (nil))

The mult instruction sets registers 64 and 65 to hold the lo and the
hi parts of the product (IIRC). Not knowing much about GCC internals,
I wouldn't know why that is marked as a clobber instead of a set,

Below is the relevant page from the MIPS documentation, see
< http://www.mips.com/Documentation/R4400_Uman_book_Ed2.pdf >

Appendix A
_______________________________________________________________________

MULT                               Multiply                        MULT

     31       26 25    21 20    16 15                6 5         0
     -------------------------------------------------------------
       SPECIAL  |   rs   |   rt   |          0        |   MULT
     0 0 0 0 0 0|        |        |0 0 0 0 0 0 0 0 0 0|0 1 1 0 0 0
     -------------------------------------------------------------
           6         5        5              10              6

Format:
     MULT rs, rt

Description: 
     The contents of general registers rs and rt are multiplied, 
     treating both operands as 32-bit 2s complement values. 
     No integer overflow exception occurs under any circumstances. 
     In 64-bit mode, the operands must be valid 32-bit, sign-
     extended values.  

     When the operation completes, the low-order word of the double 
     result is loaded into special register LO, and the high-order 
     word of the double result is loaded into special register HI.

     If either of the two preceding instructions is MFHI or
     MFLO, the results of these instructions are undefined.
     Correct operation requires separating reads of HI or LO
     from writes by a minimum of two other instructions.

_______________________________________________________________________
A-118                           MIPS R4000 Microprocessor User's Manual

GCC 3.0 Success on sparc-sun-solaris2.8 (Was: GCC 3.0 Status Report)

[Geert Bosch]

On Monday, Mark Mitchell wrote:
  The new prerelease tarballs are:
  
    ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-3.0-20010611.tar.gz
  
  and the similarly-named language-specific tarballs.
  
  Please try them out.
  
Success on sparc-sun-solaris2.8, bootstrapping from gcc-2.8.1
using ./configure ; make bootstrap ; make install
No tweaking or reading required :)

Re: GCC 3.0 Status Report

[Roman Zippel]

Hi,

Mark Mitchell wrote:

> 68K: Bootstrap problem.  PR1795.  If this is not fixed soon, it
>      can wait for 3.0.1.

I think we have a choice here between here between a compiler that
doesn't work at all or a compiler that might work, as there was
obviously no testing done for quite some time. At bootstrap/3090, c/3092
and c/3095 there are the minimum changes described needed to get a sort
of working compiler, but even that produces more than 100 failures
during check, about half of them are regressions to 2.95. I have some
patches to reduce it to 74 failures and I'd like to help to analyze/fix
more of them.
BTW there are two new regression from 3.0 to 3.1, I'll can post them
later.

bye, Roman

Re: GCC 3.0 Status Report

[Mark Mitchell]

--On Wednesday, June 13, 2001 01:16:05 AM +0200 Roman Zippel 
<zippel@linux-m68k.org> wrote:

> Hi,
>
> Mark Mitchell wrote:
>
>> 68K: Bootstrap problem.  PR1795.  If this is not fixed soon, it
>>      can wait for 3.0.1.
>
> I think we have a choice here between here between a compiler that
> doesn't work at all or a compiler that might work

An excellent point.  And given that, I see little point in trying
to fix the bug for the release, so I will downgrade it.

The SC has just been made aware that there
are problems with many embedded targets, and discussion is underway
about what to do with respect to the 3.0 release.  One possible
alternative is to delay the release indefinitely to fix the problems,
but I hope personally that the SC will not adopt this strategy.

My personal suggestion would be that you continue your work on
fixing the problems so that we can get this target working in GCC 3.0.1.

Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Mon, 11 Jun 2001, Mark Mitchell wrote:

> If there are issues that you think absolutely must be fixed before the
> release, but are not yet high-priority GNATS bugs, here is what you
> should do:
> 
>   1. Make sure that the bug report is filed in GNATS.  I will not
>      consider any item which does not have a GNATS report.
> 
>   2. Send me an email indicating why you think this is an 
>      absolutely critical bug.  It *must* be a regression from
>      GCC 2.95, and it must affect users in a particularly dire 
>      way.

I have filed PR other/3161 concerning release packaging issues.  The 
non-inclusion of the HTML documentation in the INSTALL directory in the 
prerelease is a critical issue for users.  The other issues are highly 
desirable to fix for the release.

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

Re: GCC 3.0 Status Report

[Gerald Pfeifer]

On Wed, 13 Jun 2001, Joseph S. Myers wrote:
> I have filed PR other/3161 concerning release packaging issues.  The
> non-inclusion of the HTML documentation in the INSTALL directory in the
> prerelease is a critical issue for users.  The other issues are highly
> desirable to fix for the release.

I've been working on this since this morning.

Patch to follow after a full release build using gcc_release.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC 3.0 Status Report

[Mark Mitchell]

=> I have filed PR other/3161 concerning release packaging issues.  The
> non-inclusion of the HTML documentation in the INSTALL directory in the
> prerelease is a critical issue for users.  The other issues are highly
> desirable to fix for the release.

Marked high, assigned to myself.  I will try to put as much as possible
into gcc_release to automate the process.

Will you and Gerald collaborate on the HTML docs?  I know that there
is a script that needs to be run, but I never fully understood what
to do, and if one of you would make the appropriate change to
gcc_release, that would be terrific.  Any such patch is preapproved.

Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com