GCC 3.0 Status Report

GCC 3.0 Status Report

[Mark Mitchell]

[Note: if your name appears explicitly in the `Cc' list, there is an
       action item for you at the bottom of this report.]

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

Timing
------

There are ten days until the release of GCC 3.0.

Major Annoucements
------------------

As announced in the May 21st Status Report, GNATS is now frozen.  No
new bugs can be made high priority without my express approval.  If
you wish to mark a bug high priority, you must first send me mail
explaining why fixing the bug is of *absolutely vital* import.  It
must not only be a regression from GCC 2.95 -- it must also be in some
way cataclysmic.  Failing to build the Linux kernel or the X server
for an x86 would be one example.  No optimization issue is likely to
qualify; correctness issues are probably the only likely candidates.
Crashing on illegal code for which we used to give an error mesage is
probably not a candidate.  Even failing to compile a correct, but
corner-case example, might not qualify.

Overview
--------

Unfortunately, there are many more high-priority bugs now than there
were a week ago.  I am saddenned that more of them have not been
fixed.  Many of these bugs are libstdc++ or Java bugs.  Those two
teams should focus on fixing or downgrading these bugs.  It is
important that I have an overview of what people are really trying to
fix, and what we are going to leave for another release.

The high number of open bugs, and the slow rate at which people are
fixing them, is going to force me to spend more time than I had hoped
on bug-fixing.  That means that I will have less time than I hoped for
packaging, documentation, release notes, etc.  If you are at all able
to contribute in those areas, please do so.  Gerald Pfeifer continues
to coordinate the documentation side of things.

Thanks to those who worked on the release script in my absence!  Since
there do not appear to be any packaging problem reports in GNATS, I
will assume that the tarballs work as advertised.  If you are not
contributing to the release in any other way, testing the prerelease
tarballs to make sure that they build and install is an easy and very
useful thing to do.

Fortunately, it looks like we were able to avoid testsuite regressions
for the last week, which is excellent news.

Action Items
------------

V3 Team, Java Team: Fix or downgrade V3 and Java issues.

RTH: Did we fix the ARM conditional-execution problem?
     Or should we go with the patch I proposed that you said disabled
     a lot of conditional-lifetime information?

Everyone else: Continue to fix high-priority bugs.
	       Application testing.
	       Documentation.

Re: GCC 3.0 Status Report

[Richard Henderson]

On Tue, Jun 05, 2001 at 01:23:35PM -0700, Mark Mitchell wrote:
> RTH: Did we fix the ARM conditional-execution problem?

Not yet.  I looked at it this past weekend and didn't make
much headway.  I'm going to look again this afternoon.

>      Or should we go with the patch I proposed that you said disabled
>      a lot of conditional-lifetime information?

No.  If we disable it, we should _really_ disable it, and in a very
obvious way.  Say by undefing HAVE_conditional_execution in flow.c
and putting a big comment explaining why.  Otherwise someone may look
at that code and wonder why it isn't doing what it appears that it
is supposed to be doing and get really confused.

We would also need a tiny adjustment in mark_set_1 as well -- that
ifdef block would need an

	if (cond && some_was_live)
	  not_dead = 1;


r~

Re: GCC 3.0 Status Report

[Rainer Orth]

Mark Mitchell <mark@codesourcery.com> writes:

> As announced in the May 21st Status Report, GNATS is now frozen.  No
> new bugs can be made high priority without my express approval.  If
> you wish to mark a bug high priority, you must first send me mail
> explaining why fixing the bug is of *absolutely vital* import.  It
> must not only be a regression from GCC 2.95 -- it must also be in some
> way cataclysmic.  Failing to build the Linux kernel or the X server
> for an x86 would be one example.  No optimization issue is likely to
> qualify; correctness issues are probably the only likely candidates.

There's one bug I'd like you to consider for high-priority: i.e. gcc's
non-conformance to SGI's N32/N64 ABI structure passing conventions.  This
bug is documented in the installation notes

	http://gcc.gnu.org/install/specific.html#mips*-sgi-irix6

has been in gcc since IRIX 6 support was first contributed, and has
remained unfixed since.

I tried fixing it back in 1999

	http://gcc.gnu.org/ml/gcc-patches/1999-06n/msg00544.html

but failed, both due to lack of help on crashes in other parts of the
compiler and my (still) quite limited knowledge of GCC internals.

When reviewing the Solaris 2, IRIX, and Tru64 UNIX parts of the install
docs, I was reminded of the dreaded issue and I'm now working on it again.

This problem comes up ever and ever again in the IRIX community, as

	http://freeware.sgi.com/shared/howto.html#b1

and several bug reports to gcc-bugs document (search the list archives for
inet_ntoa).  You regularly stumble across it when you try to compile some
network code, it doesn't work and you find the calls to inet_ntoa are
miscompiled.

This problem and the fact it's remained unfixed for years gives gcc
(rightly so, I'd say) a bad reputation among IRIX users, and is really
annoying.

I'd like to see a fix (developed and) integrated into GCC 3.0 since it
requires an incompatible change to the ABI to bring the code gcc produdes
in line with SGIs N32/N64 ABIs, since incompatible ABI changes have already
been announced for GCC 3.0.

As I said, I'm again investigating a fix, but am not sure if my knowledge
of gcc suffices to get this working on my own.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Tue, 5 Jun 2001, Mark Mitchell wrote:

> As announced in the May 21st Status Report, GNATS is now frozen.  No
> new bugs can be made high priority without my express approval.  If

I have restored from the list archives the old PRs that had been lost from
the database (2386 2389 2392 2394 2397 2403 2404 2419 2420 2426), except
for 2426 which I couldn't find in list archives; some of these are
priority "high" (as assigned by the person who submitted them) and need
reviewing.  In addition, some "high" priority PRs had been missing from
the index and so will now appear on searches again after I regenerated it:
2427 2438.

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

Re: GCC 3.0 Status Report

[benjamin kosnik]

> V3 Team, Java Team: Fix or downgrade V3 and Java issues.

My priorities for the next ten days:

1) loren/david threads patch

2) 3045/2346

3) solaris fseek

4) "C" header insanity

I think completion of all of these tasks is important for the release.

Mark, sorry you are disappointed with the progress, but I feel like a
lot of important bugs that got fixed. Look at the GNATS logs, there were
a lot of things accomplished. 

best,
Benjamin

Re: GCC 3.0 Status Report

[Franz Sirl]

On Tuesday 05 June 2001 22:23, Mark Mitchell wrote:
> Major Annoucements
> ------------------
>
> As announced in the May 21st Status Report, GNATS is now frozen.  No
> new bugs can be made high priority without my express approval.  If
> you wish to mark a bug high priority, you must first send me mail
> explaining why fixing the bug is of *absolutely vital* import.  It
> must not only be a regression from GCC 2.95 -- it must also be in some
> way cataclysmic.  Failing to build the Linux kernel or the X server
> for an x86 would be one example.  No optimization issue is likely to
> qualify; correctness issues are probably the only likely candidates.
> Crashing on illegal code for which we used to give an error mesage is
> probably not a candidate.  Even failing to compile a correct, but
> corner-case example, might not qualify.

Mark, I just entered c++/3061, I think it qualifies as high priority bug:

- it's a regression from gcc-2.95
- it crashes kde2 on startup

Besides that I'm just back from vacation and will recheck  
kernel/glibc/xf4/etc with current gcc3.0 on PPC during the next days.

Franz.

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "benjamin" == benjamin kosnik <bkoz@nabi.net> writes:

    >> V3 Team, Java Team: Fix or downgrade V3 and Java issues.

    benjamin> My priorities for the next ten days:

OK, thanks.  If there are open high-priority bugs that you don't think
are going to get fixed, would you downgrade them?

    benjamin> Mark, sorry you are disappointed with the progress, but
    benjamin> I feel like a lot of important bugs that got fixed. Look
    benjamin> at the GNATS logs, there were a lot of things
    benjamin> accomplished.

Disappointment != criticism.  I know everyone did a lot -- I was just
hoping to come home and find fewer open bugs.  Part of the reason
there are lots of open bugs is that people have found more bugs -- and
that's good work, not bad.

Thanks,

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

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

    Franz> Mark, I just entered c++/3061, I think it qualifies as high
    Franz> priority bug:

I agree, and I've marked it accordingly.

Nathan is working on a similar bug -- hopefully they will turn out to
be the same.

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

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

    Rainer> There's one bug I'd like you to consider for
    Rainer> high-priority: i.e. gcc's non-conformance to SGI's N32/N64
    Rainer> ABI structure passing conventions. 

We are less than two weeks from the release, and as you say GCC has
had this bug forever.

Yes, fixing it would be good.  No, not in this release.

Thanks,

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

Re: GCC 3.0 Status Report

[Alexandre Petit-Bianco]

Mark Mitchell writes:

> V3 Team, Java Team: Fix or downgrade V3 and Java issues.

I'm on it.

./A

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Petit-Bianco <apbianco@cygnus.com> writes:

    Alexandre> Mark Mitchell writes:

    >> V3 Team, Java Team: Fix or downgrade V3 and Java issues.

    Alexandre> I'm on it.

Great.

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

Re: GCC 3.0 Status Report

[Rainer Orth]

Mark Mitchell writes:

> >>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> 
>     Rainer> There's one bug I'd like you to consider for
>     Rainer> high-priority: i.e. gcc's non-conformance to SGI's N32/N64
>     Rainer> ABI structure passing conventions. 
> 
> We are less than two weeks from the release, and as you say GCC has
> had this bug forever.
> 
> Yes, fixing it would be good.  No, not in this release.

ok.  I'll continue working on a patch anyway, maybe I can come up with
something that's both obviously correct and non-intrusive.

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

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

[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

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

[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

[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

[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]

 Mark I know you'll have your hands full the next few days but I would
> certainly appreciate if you could keep this in mind for GCC-3.01 or
> GCC-3.1

I want to discuss upcoming releases with the SC, before discussing them
in detail here.  It may be that my conception of what is appropriate
differs from the rest of the SC, so it would be wrong to commit
to anything at this point.

I am sure that, whatever is decided, there will certainly be a
mechanism for getting everyone's wishlist heard.

Thanks,

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

GCC 3.0 Status Report

[Robert Schweikert]

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

Mark Mitchell wrote:
>
>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.
>

Great.

I have some code here that I would like to see in GCC, it allows the
reading of command line arguments from a file, there was a discussion
about this, inspired by me, a while back. I had posted this before but I
think it got lost in the certainly more important GCC-3.0 work. This is
a proposal and I am not sure where and how it should be integrated in
GCC but am willing to do the work if I can get some pointers and help on
where and how.

Mark I know you'll have your hands full the next few days but I would
certainly appreciate if you could keep this in mind for GCC-3.01 or
GCC-3.1

Thanks,
Robert

To use the example:

- compile parser.c (gcc -o parse parser.c)
- run it (parse -I. -L/usr -@myCmdFile.txt -o cute)

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei@mindspring.com                         LINUX



[-- Attachment #2: parser.tgz --]
[-- Type: application/x-gzip, Size: 896 bytes --]

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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

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

[Joern Rennecke]

> Diffs from 2.95 are likely to be extremely large: for a diff to remove
> a library it has to include it verbatim, similarly to add one.  This means

Not true.  You can make an ed diff to delete the old libraries, which should
be rather short.

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

    Toon> "We haven't met, I think ... the name's Bond, James Bond".

This joke leaves me shaken, but not stirred.

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

Re: GCC 3.0 Status Report

[Toon Moene]

Mark Mitchell wrote:

> (This is like sending a `launch commit' message to a nuclear missile;
> it will proceed automatically to its target, even if all power fails
> and the base is overrun by invaders, unless the override code is
> entered.  Make of that analogy what you will.)

"We haven't met, I think ... the name's Bond, James Bond".

[ Sorry, couldn't resist :-) ]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Phil" == Phil Edwards <pedwards@disaster.jaj.com> writes:

    Phil> Ah, lemme back up.  Sanity check: you /do/ return from
    Phil> vacation, right?  :-)

He, he.  

It would be nice to stay on vacation forever, but I did not win the
lottery.

I will be back June 2.

Thanks,

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

Re: GCC 3.0 Status Report

[Phil Edwards]

On Mon, May 21, 2001 at 06:48:12PM -0700, Mark Mitchell wrote:
>   Week of May 28
>   --------------
> 
>   - I will be on vacation, starting May 26th.
[...]
>   Week of June 4
>   --------------
>  
>   - GNATS freeze.  
> 
>     No new bugs can be made high-priority after this date without
>     my express approval, even if they are GCC 2.95 regressions.

At what point do you return from vacation?

Ah, lemme back up.  Sanity check:  you /do/ return from vacation, right?  :-)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: GCC 3.0 Status Report

[Dennis Bjorklund]

On Tue, 22 May 2001, Mark Mitchell wrote:

> - Was there a good Swedish translation in GCC 2.95?

No.

> - How do we turn off the Swedish translation?

Don't install the gcc.mo file.

> I suspect that it will be too hard to fix the translation system at
> this point, although I don't mind trying, if it's pretty non-invasive.

Well, in november(?) when the discussion was up people were afraid that it
would affect other functions that depend om the locale setting was used in
a critical way in the compiler. Like using atof to parse a number which in
many locales (like swedish) only works of you use , as the separator. So
0.45 would be read in as the number 0 while 0,45 would be read as the
number 0.45. This is a typical error that I've seen (and fixed) in many
programs.

I don't know if there really are such cases in gcc, and I don't know if
anybode knows about it. I think as sone as 3.0 is out one should just make
the change and find bugs if there are any. Maybe one could even change now
if there is a big testsuite of programs (you must already have that) so we
can make sure that most (or all) things work.

> If we had a good translation in GCC 2.95 that would be more
> compelling.  Otherwise, I think we need to, as you say, disable the
> translation so that people who speak Swedish are not confused by a
> hodge-podge of Swenglish.

As it is now it's not so bad since no of the strings are shown :-) Only
the helptext from gcc --help is translated.

The swedish translation group is quite big and active. But i'm sure that
as sone as the translationsystem works there will be many more
translations. But no one wants to do a couple of weeks work when it want
be used and were you have to redo it when the next version of gcc comes
out.

-- 
/Dennis

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Dennis" == Dennis Bjorklund <db@zigo.dhs.org> writes:

Thanks for raising this issue.

    Dennis> I don't want to ship a gcc with a _very_ broken
    Dennis> translation to swedish.  Better to not have a translation
    Dennis> at all then.

Two questions:

- Was there a good Swedish translation in GCC 2.95?

- How do we turn off the Swedish translation?

I suspect that it will be too hard to fix the translation system at
this point, although I don't mind trying, if it's pretty non-invasive.
If we had a good translation in GCC 2.95 that would be more
compelling.  Otherwise, I think we need to, as you say, disable the
translation so that people who speak Swedish are not confused by a
hodge-podge of Swenglish.

Thanks,

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

Re: GCC 3.0 Status Report

[Gerald Pfeifer]

On Tue, 22 May 2001, Joseph S. Myers wrote:
> What is the status of fixes to the doc/install.texi issues described in
>
> http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00449.html

It's on my TOMONITOR list ;-) and in the worst case I'll try to fit it
onto my TODO list in time for the GCC 3.0 release, though it would be
great could Dean or you have a look.

(As we haven't got a response from Dean yet, I suppose he's on holidays,
hopefully not something worse!)

> http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00634.html

That's on my TODO list for today. Expect a fix soon.

> Once these problems have been sorted out, I may look at doing some of
> the moving of documentation from the old install.texi to the new one.

Great!

And I'll have a look at removing cruft from the old install.texi plus
removing wwwdocs/htdocs/install in favor of the new stuff.

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

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Mon, 21 May 2001, Mark Mitchell wrote:

> Please work on documentation for the release.

What is the status of fixes to the doc/install.texi issues described in

http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00449.html
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00634.html

?

(The former describes various problems with the Texinfo; the latter is
where part of one entry seems to have been duplicated in the middle of
another.)

Once these problems have been sorted out, I may look at doing some of the 
moving of documentation from the old install.texi to the new one.

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

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Tue, 22 May 2001, Dennis Bjorklund wrote:

> The
> translationssystem is broken in gcc, and I don't understand enough of the
> internals of gcc to fix it. One must not break something else that depends
> on functions that are affected by the locale. These things should be fixed
> there instead.

Did NLS work in 2.95 (for the en_UK translation, if configured with 
--enable-nls)?  If so, submit a priority "high" PR as a regression.

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

Re: GCC 3.0 Status Report

[Dennis Bjorklund]

On Mon, 21 May 2001, Mark Mitchell wrote:

> There are 25 days until the release of GCC 3.0.

This means that there probably won't be a swedish translation even though
there are people in the swedish translation team that wants to do it. The
translationssystem is broken in gcc, and I don't understand enough of the
internals of gcc to fix it. One must not break something else that depends
on functions that are affected by the locale. These things should be fixed
there instead.

I suggest that the first thing to do after 3.0 is to fix this and then if
it breaks something else (that for example use atof, since that is
dependent of the locale) we havet to fix that there.

As gcc is now there is half a swedish translation checked in (6-8 months
old) that is basicly just used when on do gcc --help since every
translated string in the tools used by gcc is not shown.

Maybe one should disable this swedish output as well since the rest is in
english, or I should make sure that at least all the output from gcc
--help is in swedish (some strings have changed since I did the
translation).

I don't want to ship a gcc with a _very_ broken translation to swedish.
Better to not have a translation at all then.

If the translation system is fixed there is still time for us to fix the
strings, but since I don't understand all of gcc internals I don't know if
it's possible to fix now (probably not).

-- 
/Dennis

Re: GCC 3.0 Status Report

[Daniel Berlin]

Mark Mitchell <mark@codesourcery.com> writes:

> 
> Please work on documentation for the release.  Are there caveats, news
> items, etc. that people should no about?  Are there undocumented
> command-line options for your target?  Are there people who should be
> thanked for their contributions?  Please collect such information and
> send it to our documentation mainatiner: Gerald Pfeifer
> <pfeifer@dbai.tuwien.ac.at>.  (Gerald, if you would like to handle the
> collection of this information in a different way, please feel free to
> make an alternate announcement.)  And Gerald, please add yourself to
> the thank-you list for doing a fabulous job as the documentation
> maintainer!

Well, if you want the structure, order, and description of the passes, and the documentation
about how it works to be correct, you'll need to apply the patches I
sent for that part of the docs. However, that's more for people who
care about what it's doing internally, of course.

If there is some other part in dire need of updating or more docs, i'm more than
happy to make a go at it so it gets done for the release.

-- 
"Babies don't need a vacation, but I still see them at the
beach...  It pisses me off!  I'll go over to a little baby and
say, "What are you doing here?  You haven't worked a day in your
life!"
"-Steven Wright

GCC 3.0 Status Report

[Mark Mitchell]

Timing
======

There are 25 days until the release of GCC 3.0.

Overview
========

Everyone worked very hard last week.  The new ABI-compliant exceptions
are working pretty smoothly at this point, and Richard Henderson is
helping people bang out the last few bugs and build failures.  Many
bugs were fixed.  There are presently about 30 high-priority bugs
reported, which is slightly down from last week.  The reason the
number isn't lower is that a few new regressions have been found
during the week.  Some of these bugs are Java bugs; it would be good
if the Java folks would try to close out some of these.

Bernd Schmidt helped me out by providing me the release script that he
has been using.  I am cleaning it up and tweaking it to make it
support the GCC 3.0 (and future) releases.  Bernd also fixed a
critical bug on the ARM.  Thank you Bernd!

At this point, my focus will be shifting from bug-fixing to packaging,
documentation, announcements, thank-yous and other similar issues.
That means that to make significant inroads against the open bugs,
other folks will have to step up and help.  There is one particularly
scary ARM bug where apparently GCC 3.0, once installed, cannot be used
to bootstrap itself.  I would definitely like to understand this
problem better.

Requests for Help
=================

Please fix high-priority bugs.

Please continue to report regressions, and to review bugs in GNATS.

Soon, I will make prerelease test tarballs available.  These should be
packaged in the same way as the actual release will be.  Please
download them and try them out.  The most likely failure modes will be
things like that you can't build with the "core" and "c++" modules,
but without the "fortran" module, for example, or that you need
`autofoo' installed.  The prerelease tarballs will be built by cron on
a nightly basis, and posted for testing.  I will post a separate
announcement later.

Please work on documentation for the release.  Are there caveats, news
items, etc. that people should no about?  Are there undocumented
command-line options for your target?  Are there people who should be
thanked for their contributions?  Please collect such information and
send it to our documentation mainatiner: Gerald Pfeifer
<pfeifer@dbai.tuwien.ac.at>.  (Gerald, if you would like to handle the
collection of this information in a different way, please feel free to
make an alternate announcement.)  And Gerald, please add yourself to
the thank-you list for doing a fabulous job as the documentation
maintainer!

Schedule
========

Last week, I announced a June 15th release.  Once I get the release
script working, I will create a cronjob that will spin the release on
that date.  It will then require manual intervention to stop the
release from from happenning.  

(This is like sending a `launch commit' message to a nuclear missile;
it will proceed automatically to its target, even if all power fails
and the base is overrun by invaders, unless the override code is
entered.  Make of that analogy what you will.)

Below is the schedule for between now and the release.  This schedule
is designed to make sure that we are in a position to make the release
on the target date, rather than to make sure that the release is 100%
perfect at that point.  This is the tradeoff that we need to make at
this point; we've worked very hard to improve the quality of the
branch, we will now be working hard to make sure that the world gets
to see what we have done.

  Week of May 21
  --------------

  - Prepare release script.

  - Prepare automated prerelease tarballs.

  - Continue to fix critical bugs.

  Week of May 28
  --------------

  - I will be on vacation, starting May 26th. I will be in a part of
    the world that basically does not have internet access, so I will
    be totally offline.  I apologize for the poor timing, but the trip
    has been planned for months.

  - Immediate reversion policy.

    From this point forward, any patch which causes any new testsuite
    or bootstrap failures on any of our primary or secondary targets
    may be summarily reverted, without discussion.  It is more
    important that the majority of targets continue to function, and
    that people continue to have the opportunity to test them, than
    that any particular bug gets fixed.  If your patch is reverted,
    you can resubmit it after you figure out how to fix the problem,
    but you must have the revised patch reviewed again.  Tickling a
    latent bug, etc., is no excuse.  Think like a user: if it
    used to work, and now it doesn't, you broke it.

    Jeffrey Oldham will monitor the various automated builds that are
    posted nightly on CodeSourcery's server.  If he observes
    regressions in these builds from the previous day's results, he
    will identify the offending patch and remove it, posting a message
    indicating that he has done so.

    Any maintainer may take similar action, if so motivated, so as to 
    avoid waiting for Jeffrey.

  - Test prerelease tarballs.

  - Continue to fix critical bugs.
   
  - Application testing.

  Week of June 4
  --------------
 
  - GNATS freeze.  

    No new bugs can be made high-priority after this date without
    my express approval, even if they are GCC 2.95 regressions.
    Please make every effort to review open bugs for your platform,
    and to perform application testing before this point.  Until
    this point, any maintainer can mark a bug high priority if it
    is a GCC 2.95 regression.

  - Continue to fix critical bugs.

  - Application testing.

  Week of June 11
  ---------------
  
  - Code freeze.

    No checkins will be allowed this week without my express
    approval.  Practically speaking, that means that we will be
    heavily bottlenecked at this point.  Please take advantage of
    the intervening time to work with all of the people who can
    approve patches to get your changes done.

  - Final documentation changes.

  - Final application testing.
  
  - Prepare release announcement.

  June 15th
  ---------

   - Release GCC 3.0.
     
Volunteer of the Week
=====================

This week's volunteer is one of the truly versatile GCC developers.
He is also one of the most active reviewers of other people's patches.
Equally at home inn the IA64 back-end, the x86 back-end, and any part
of the optimizers, he took on the task of implementing a superior,
industry-standard exception-handling model.  This new
exception-handling model improves the size and performance of C++ and
Java code substantially, and will eventually allow GDB to set
breakpoints on a `throw' and see where the eventual `catch' will be.

The GCC 3.0 Volunteer of the Week is ...

   ... Richard Henderson.

Congratulations!

Re: GCC 3.0 Status Report

[Joe Buck]

> Whoever does this may also want to merge it with the snapshot script.  
> (Which has a few different requirements - e.g. the generated files go in
> releases only, but not snapshots.)  It would be useful if the script has
> the capability to produce diffs from more than one previous version -
> since e.g. 3.0 ought to have diffs both from 2.95 (of limited value given
> their size, but this has been done before - and someone ought to read the
> diffs to find omissions from the release notes) and from 3.0-pre2 (or
> whatever).

Diffs from 2.95 are likely to be extremely large: for a diff to remove
a library it has to include it verbatim, similarly to add one.  This means
the diff has to include all of the 2.95.x libchill, libio, libstdc++, and
all of gcc/ch to delete that, plus all of libstdc++, java, and libjava to
add that, on top of all the other differences.  In the end, the diff is
going to be almost as big as the distribution, meaning that it's not
worthwhile.

However, we do package a C-only subset (gcc-core-xxxx.tar.gz); for that,
the diff from 2.95.3 might be worth having.

Re: GCC 3.0 Status Report

[Christian Iseli]

Hi,

mark at codesourcery dot com said:
> Please try to test GCC on as much software as you can.  Build
> X windows.  Build the Linux kernel.  Run 'em.  File bugs in GNATS.

Ok, I had a go at it on my Linux/Athlon machine.  So far, I compiled the kernel
(2.4.4-ac9), glibc (2.2.3 from CVS), and XFree86 (4.0.99.4 from CVS) and
installed them.  All was compiled using -O2 -march=athlon, and all seems to
work fine :)

My only issue has been reported in GNATS: c/2728.  It might be due to the 
inliner, but that's just a wild guess...  For some reason, the Priority is not 
marked high, though.

Haven't tried Qt and KDE yet...

Things are looking quite good.

Cheers,
					Christian

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Mon, 14 May 2001, Mark Mitchell wrote:

>   Is there anyone willing to work on the release script?  This
>   script builds a tarball from what's in CVS, but also needs to 
>   add generated files not in CVS (e.g., `parse.y').  We need to 
>   test that the generated tarball actually works.  This is a
>   classic release engineering task.  It would be very helpful to
>   me if someone who is skilled in this area would step forward,
>   thereby freeing me up to continue fixing bugs.

Whoever does this may also want to merge it with the snapshot script.  
(Which has a few different requirements - e.g. the generated files go in
releases only, but not snapshots.)  It would be useful if the script has
the capability to produce diffs from more than one previous version -
since e.g. 3.0 ought to have diffs both from 2.95 (of limited value given
their size, but this has been done before - and someone ought to read the
diffs to find omissions from the release notes) and from 3.0-pre2 (or
whatever).

Also, though I did volunteer some months ago to convert the FOM back to a
static faq.html, given the FOM RCS files, I'd rather if someone else were
to take this on.  The aim is to restore all the original content, with all
useful changes, plus useful new FAQ entries (suitably edited; any long
ones may need copyright checks) and anything else that has been frequently
asked.  An editing pass to clean up obsolete information will then be
needed.  Links to the FOM should then revert back to links to the static
FAQ.

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

GCC 3.0 Status Report

[Mark Mitchell]

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

Overall
-------

  The last major piece of functionality for the release (the 
  new ABI-compliant exception-handling model) has been installed.
  Accompanying this are improvements to the C++ standard library
  to work with the new model.  Thanks to Richard Henderson 
  and Benjamin Kosnik for implementing these changes.

  We are getting close to zero unexpected FAILs in the testsuites
  on many major platforms.  We will achieve this goal soon.  I have
  fixed many, many bugs in the last week or so, and disabled some
  tests that do not represent regressions.
  
  If you are a platform maintainer/tester, and you know of a bug that
  you believe is essential for the release -- in other words, that is
  is a regresssion from GCC 2.95.x -- please make sure it is in GNATS
  and marked "high" priority.  Remember that the criteria here is a
  *regression*.  At this point, if it is broken with GCC 2.95.x and
  not already fixed, it is going to stay broken.  It would take an
  earth-shatterring bug of doom to make me think otherwise.

  Please do not send me your list of bugs directly.  Put them in 
  GNATS; that is what it is for.  If you send them to me, I will
  likely delete them.  Then, I will deny every having received
  them. :-)

Schedule
--------

  I will be on vacation May 25th through June 2nd.  I was hoping
  to make the release before May 25th.  Now, I hope to make a test
  release before I go.

  At this point, I am finally willing to set a schedule.

  Previously, I believed that we should wait until certain functional
  criteria were met.  We are now very close to those requirements.
  And, time *does* matter; there really is value in getting this beast
  out the door.  

  Therefore, we're now going to pretend that the company has told us
  that we must ship by a certain date, or the copmany will be unable
  to raise additional financing, that we will be summarily fired
  without severance, and that all of our stock options will be
  worthless.  If you've worked at a dot-bomb recently, this should
  sound familiar.

  The release will be made on or before 11:59PM GMT -8 (Pacific
  Daylight Time) June 15th, 2001 A.D.  Because otherwise I will
  commit suicide at 12:00 AM on June 16th, and you will all feel
  very, very bad.

Requests for Help
-----------------

  Is there anyone willing to work on the release script?  This
  script builds a tarball from what's in CVS, but also needs to 
  add generated files not in CVS (e.g., `parse.y').  We need to 
  test that the generated tarball actually works.  This is a
  classic release engineering task.  It would be very helpful to
  me if someone who is skilled in this area would step forward,
  thereby freeing me up to continue fixing bugs.
  	
  Please track down GNATS bugs that apply to your targets,
  front-ends, etc.  Fix 'em, post 'em, check 'em in.

  Please try to test GCC on as much software as you can.  Build
  X windows.  Build the Linux kernel.  Run 'em.  File bugs in GNATS.
  
  Repeat.

Volunteer of The Week
---------------------

  This weeks winner is tireless in his efforts to clean up 
  crufty old bits of GCC.  Always willing to look for away to
  avoid the "expedient hack", he has often gone where angels, and 
  even fools, fear to tread.  Recently, he's tackled issues
  involving crufty old headers installed by GCC, ancient Makefile 
  ugliness, and ancient configury ugliness.  Someday, I fully 
  expect that he will the README.ALTOS and README.ACORN from the
  GCC directory itself.

  All of this effort will make the GCC 3.1, and every release 
  thereafter, easier -- so our Volunteer of the Week is ...

  ... Zack Weinberg!

  Congratulations.

Re: GCC 3.0 Status Report

[Joe Buck]

I wrote:
> > The answer to your question is that there is no abi compatibility
> > for the library, only for the compiler.

Mike Stump writes:
> Ah, ok, thanks for the explanation.  I understand the difference, I
> just hope that we communicate it with folks.  From
> http://gcc.gnu.org/gcc-3.0/criteria.html:
> 
> C++ ABI
> 
>      In order to avoid changing the C++ ABI from release to release,
>      as GCC has done to date, there must be a stable ABI.
> 
> C++ Standard Library
> 
>      The standard library is a part of the ABI. Changing the standard
>      library interfaces is effectively a change in the ABI. It is
>      important that we provide a standards-conforming C++ standard
>      library.
> 
> It seems to want to lump the library ABI in with the compiler one.
> This could lead to confusion, though, since it doesn't say anything
> much, it isn't wrong.

Yes, you're right, this is confusing.  The reason for the confusion is
historical.  Way back when we started (around the time of the egcs/FSF
reunification), some of us had fantasies about being able to freeze both
the library and the compiler ABIs for 3.0.  But the library is nowhere
near ready for freezing.  So it'll be the old rules for now: 3.0.x
compatible, 3.0 -> 3.1 may break something.  Ideally we'll be able to come
up with something in the future that allows binary compatibility for the
library as well, but I don't think that it can be frozen until some kind
of refactoring pass is done on the STL.

Re: GCC 3.0 Status Report

[Mike Stump]

> From: Joe Buck <jbuck@synopsys.COM>
> To: mrs@windriver.com (Mike Stump)
> Date: Wed, 2 May 2001 03:14:14 -0700 (PDT)

> The answer to your question is that there is no abi compatibility
> for the library, only for the compiler.

Ah, ok, thanks for the explanation.  I understand the difference, I
just hope that we communicate it with folks.  From
http://gcc.gnu.org/gcc-3.0/criteria.html:

C++ ABI

     In order to avoid changing the C++ ABI from release to release,
     as GCC has done to date, there must be a stable ABI.

C++ Standard Library

     The standard library is a part of the ABI. Changing the standard
     library interfaces is effectively a change in the ABI. It is
     important that we provide a standards-conforming C++ standard
     library.

It seems to want to lump the library ABI in with the compiler one.
This could lead to confusion, though, since it doesn't say anything
much, it isn't wrong.

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Mike" == Mike Stump <mrs@windriver.com> writes:

    Mike> I have a random stupid question of the day...  Is it really
    Mike> the case that there are no inlines anywhere in any of the
    Mike> C++ library that might be taken advantage of by the user, or
    Mike> that any such inlines only rely upon abi mandated things?

We have conveniently defined the library to be beyond the scope of the
ABI.

The ABI deals only with layout, vtables, and such.

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

Re: GCC 3.0 Status Report

[Mike Stump]

> To: gcc@gcc.gnu.org
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Tue, 01 May 2001 17:22:17 -0700

>   We are coming down the home stretch.

I have a random stupid question of the day...  Is it really the case
that there are no inlines anywhere in any of the C++ library that
might be taken advantage of by the user, or that any such inlines only
rely upon abi mandated things?

Failure to understand that question, means, we cannot claim C++ abi
compatibility.

GCC 3.0 Status Report

[Mark Mitchell]

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

Overall
-------

  We are coming down the home stretch.  The only major bit of
  work remaining is the merge of Richard/Benjamin's EH/library
  bits to the branch.  Richard, Benjamin, when can we expect
  this?

  Other than that, we just need to keep squishing bugs.  We got
  a lot of regressions fixed last week, and there will be more of
  that this week.  For the most part, we're getting successful
  bootstraps on a wide variety of platforms and the stability on
  the branch seems to be improving.

  I would like to prepare a test release in the next week or two
  for wider distribution.

Helping Out
-----------

  Lots of people are reporting problems, and there are still
  outstanding high-priority bugs in GNATS.  It would be good
  if people with particular knowledge of particular platforms
  could pitch in to solve problems.  It's difficult for me to 
  try to learn whole new architectures just to fix a bug or 
  two.

  Please try to focus on the branch, and not on mainline 
  development.

Re: GCC 3.0 Status Report

[Fergus Henderson]

On 19-Apr-2001, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> Here is a fix for the undefined reference std::errno.  The language
> experts can debate whether it is the right thing to do.
...
> 	* mangle.c (mangle_decl_string): Don't mangle variables with
> 	extern "C" linkage.

That's the right thing to do.

The relevant text in the C++ standard is 7.5 [dcl.link] paragraph 2:

 | Two declarations for an object with C language linkage with the same
 | name (ignoring the namespace names that qualify it) that appear in
 | different namespace scopes refer to the same object.

Personally I don't think this one was a particularly good decision
(e.g. because it will cause trouble if a future extension of C
adds namespaces...), but that's what the committee decided.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

  >     John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html

  I understand your priorities but as I noted this problem affects all
  ports.  

I didn't see that in that message.

But, you are right that it probably could affect most ports.  Some
ports (where pretty much everything is word-sized) are probably OK, by
luck.

Anyhow, I think I have a cleaner patch.  Would you mind mailing me
(privately) the preprocessed source, cc1plus command-line options, and
the target-triplet you're using, so I can make sure that I fixed the
problem?

Thanks!

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

Re: GCC 3.0 Status Report

[Michael Elizabeth Chastain]

Works for me on native solaris.  Good job!  PR libstdc++/2445 can be
closed now.

Michael Chastain

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@racerx.synopsys.com> writes:

    Joe> Perhaps I'm missing something, but if you say "Build don't
    Joe> link" it seems that the test does not catch the error. 

Yes.

Thanks for spotting this.  I'll check in the obvious change -- use
`Build don't run'.

Thanks,

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

Re: GCC 3.0 Status Report

[Joe Buck]

Mark writes:

> + // Build don't link:
> + // Origin: Mark Mitchell <mark@codesourcery.com>
> + 
> + namespace N {
> +   extern "C" int i;
> + 
> +   void f () {
> +     i = 3;
> +   }
> + };
> + 
> + int i;
> + 
> + int main () { N::f (); }

Perhaps I'm missing something, but if you say "Build don't link"
it seems that the test does not catch the error.  If We get an .o
file that incorrectly references N::i, it's still a valid .o file.
The program must be linked to reveal the undefined symbol.  Right?

Re: GCC 3.0 Status Report

[Benjamin Kosnik]

it has to be a macro, sadly.

Of couse, you've squashed a bug anyway, and I'm grateful.

-benjamin

Re: GCC 3.0 Status Report

[Mark Mitchell]

Here is the patch I committed.

Tested on i6868-pc-linux-gnu, committed on the branch and on the
mainline.

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

2001-04-19  Mark Mitchell  <mark@codesourcery.com>

	* cp-tree.h (DECL_LANGUAGE): Don't assume DECL_LANG_SPECIFIC is
	set.
	(SET_DECL_LANGUAGE): New macro.
	* decl.c (duplicate_decls): Use SET_DECL_LANGUAGE.
	(pushdecl): Likewise.
	(build_library_fn_1): Likewise.
	(build_cp_library_fn): Likewise.
	(grokfndecl): Likewise.
	(grokvardecl): Mark `extern "C"' variables as having C linkage.
	* decl2.c (grokclassfn): Use SET_DECL_LANGUAGE.
	* lex.c (retrofit_lang_decl): Likewise.
	* mangle.c (mangle_decl_string): Don't mangle the names of
	variables declared with C language linkage.
	* semantics.c (finish_member_declaration): Use SET_DECL_LANGUAGE.
	
Index: testsuite/g++.old-deja/g++.other/linkage7.C
===================================================================
RCS file: linkage7.C
diff -N linkage7.C
*** /dev/null	Tue May  5 13:32:27 1998
--- linkage7.C	Thu Apr 19 15:38:25 2001
***************
*** 0 ****
--- 1,14 ----
+ // Build don't link:
+ // Origin: Mark Mitchell <mark@codesourcery.com>
+ 
+ namespace N {
+   extern "C" int i;
+ 
+   void f () {
+     i = 3;
+   }
+ };
+ 
+ int i;
+ 
+ int main () { N::f (); }
Index: cp/cp-tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/cp-tree.h,v
retrieving revision 1.572.2.18
diff -c -p -r1.572.2.18 cp-tree.h
*** cp-tree.h	2001/04/16 05:49:55	1.572.2.18
--- cp-tree.h	2001/04/19 22:38:28
*************** struct lang_decl
*** 1929,1937 ****
  #define DECL_IN_MEMORY_P(NODE) \
    (DECL_RTL_SET_P (NODE) && GET_CODE (DECL_RTL (NODE)) == MEM)
  
! /* For FUNCTION_DECLs: return the language in which this decl
!    was declared.  */
! #define DECL_LANGUAGE(NODE) (DECL_LANG_SPECIFIC(NODE)->decl_flags.language)
  
  /* For FUNCTION_DECLs: nonzero means that this function is a constructor.  */
  #define DECL_CONSTRUCTOR_P(NODE) (DECL_LANG_SPECIFIC(NODE)->decl_flags.constructor_attr)
--- 1929,1952 ----
  #define DECL_IN_MEMORY_P(NODE) \
    (DECL_RTL_SET_P (NODE) && GET_CODE (DECL_RTL (NODE)) == MEM)
  
! /* For a FUNCTION_DECL or a VAR_DECL, the language linkage for the
!    declaration.  Some entities (like a member function in a local
!    class, or a local variable) do not have linkage at all, and this
!    macro should not be used in those cases.
!    
!    Implementation note: A FUNCTION_DECL without DECL_LANG_SPECIFIC was
!    created by language-independent code, and has C linkage.  Most
!    VAR_DECLs have C++ linkage, and do not have DECL_LANG_SPECIFIC, but
!    we do create DECL_LANG_SPECIFIC for variables with non-C++ linkage.  */
! #define DECL_LANGUAGE(NODE) 				\
!   (DECL_LANG_SPECIFIC (NODE) 				\
!    ? DECL_LANG_SPECIFIC(NODE)->decl_flags.language	\
!    : (TREE_CODE (NODE) == FUNCTION_DECL			\
!       ? lang_c : lang_cplusplus))
! 
! /* Set the language linkage for NODE to LANGUAGE.  */
! #define SET_DECL_LANGUAGE(NODE, LANGUAGE) \
!   (DECL_LANG_SPECIFIC (NODE)->decl_flags.language = LANGUAGE)
  
  /* For FUNCTION_DECLs: nonzero means that this function is a constructor.  */
  #define DECL_CONSTRUCTOR_P(NODE) (DECL_LANG_SPECIFIC(NODE)->decl_flags.constructor_attr)
Index: cp/decl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/decl.c,v
retrieving revision 1.747.2.17
diff -c -p -r1.747.2.17 decl.c
*** decl.c	2001/04/12 14:16:58	1.747.2.17
--- decl.c	2001/04/19 22:38:31
*************** duplicate_decls (newdecl, olddecl)
*** 3193,3199 ****
  	  /* Make the old declaration consistent with the new one so
  	     that all remnants of the builtin-ness of this function
  	     will be banished.  */
! 	  DECL_LANGUAGE (olddecl) = DECL_LANGUAGE (newdecl);
  	  SET_DECL_RTL (olddecl, DECL_RTL (newdecl));
  	  COPY_DECL_ASSEMBLER_NAME (olddecl, newdecl);
  	  SET_IDENTIFIER_GLOBAL_VALUE (DECL_ASSEMBLER_NAME (newdecl),
--- 3193,3199 ----
  	  /* Make the old declaration consistent with the new one so
  	     that all remnants of the builtin-ness of this function
  	     will be banished.  */
! 	  SET_DECL_LANGUAGE (olddecl, DECL_LANGUAGE (newdecl));
  	  SET_DECL_RTL (olddecl, DECL_RTL (newdecl));
  	  COPY_DECL_ASSEMBLER_NAME (olddecl, newdecl);
  	  SET_IDENTIFIER_GLOBAL_VALUE (DECL_ASSEMBLER_NAME (newdecl),
*************** duplicate_decls (newdecl, olddecl)
*** 3353,3359 ****
  	     is OK.  */
  	  if (current_lang_stack
  	      == &VARRAY_TREE (current_lang_base, 0))
! 	    DECL_LANGUAGE (newdecl) = DECL_LANGUAGE (olddecl);
  	  else
  	    {
  	      cp_error_at ("previous declaration of `%#D' with %L linkage",
--- 3353,3359 ----
  	     is OK.  */
  	  if (current_lang_stack
  	      == &VARRAY_TREE (current_lang_base, 0))
! 	    SET_DECL_LANGUAGE (newdecl, DECL_LANGUAGE (olddecl));
  	  else
  	    {
  	      cp_error_at ("previous declaration of `%#D' with %L linkage",
*************** duplicate_decls (newdecl, olddecl)
*** 3667,3673 ****
  
        if (! types_match)
  	{
! 	  DECL_LANGUAGE (olddecl) = DECL_LANGUAGE (newdecl);
  	  COPY_DECL_ASSEMBLER_NAME (newdecl, olddecl);
  	  SET_DECL_RTL (olddecl, DECL_RTL (newdecl));
  	}
--- 3667,3673 ----
  
        if (! types_match)
  	{
! 	  SET_DECL_LANGUAGE (olddecl, DECL_LANGUAGE (newdecl));
  	  COPY_DECL_ASSEMBLER_NAME (newdecl, olddecl);
  	  SET_DECL_RTL (olddecl, DECL_RTL (newdecl));
  	}
*************** duplicate_decls (newdecl, olddecl)
*** 3682,3688 ****
        if (new_defines_function)
  	/* If defining a function declared with other language
  	   linkage, use the previously declared language linkage.  */
! 	DECL_LANGUAGE (newdecl) = DECL_LANGUAGE (olddecl);
        else if (types_match)
  	{
  	  /* If redeclaring a builtin function, and not a definition,
--- 3682,3688 ----
        if (new_defines_function)
  	/* If defining a function declared with other language
  	   linkage, use the previously declared language linkage.  */
! 	SET_DECL_LANGUAGE (newdecl, DECL_LANGUAGE (olddecl));
        else if (types_match)
  	{
  	  /* If redeclaring a builtin function, and not a definition,
*************** pushdecl (x)
*** 3971,3977 ****
        if (DECL_NON_THUNK_FUNCTION_P (x) && ! DECL_LANG_SPECIFIC (x))
  	{
  	  retrofit_lang_decl (x);
! 	  DECL_LANGUAGE (x) = lang_c;
  	}
  
        if (DECL_NON_THUNK_FUNCTION_P (x) && ! DECL_FUNCTION_MEMBER_P (x))
--- 3971,3977 ----
        if (DECL_NON_THUNK_FUNCTION_P (x) && ! DECL_LANG_SPECIFIC (x))
  	{
  	  retrofit_lang_decl (x);
! 	  SET_DECL_LANGUAGE (x, lang_c);
  	}
  
        if (DECL_NON_THUNK_FUNCTION_P (x) && ! DECL_FUNCTION_MEMBER_P (x))
*************** build_library_fn_1 (name, operator_code,
*** 6716,6722 ****
    DECL_ARTIFICIAL (fn) = 1;
    TREE_NOTHROW (fn) = 1;
    SET_OVERLOADED_OPERATOR_CODE (fn, operator_code);
!   DECL_LANGUAGE (fn) = lang_c;
    return fn;
  }
  
--- 6716,6722 ----
    DECL_ARTIFICIAL (fn) = 1;
    TREE_NOTHROW (fn) = 1;
    SET_OVERLOADED_OPERATOR_CODE (fn, operator_code);
!   SET_DECL_LANGUAGE (fn, lang_c);
    return fn;
  }
  
*************** build_cp_library_fn (name, operator_code
*** 6743,6749 ****
    tree fn = build_library_fn_1 (name, operator_code, type);
    TREE_NOTHROW (fn) = TYPE_NOTHROW_P (type);
    DECL_CONTEXT (fn) = FROB_CONTEXT (current_namespace);
!   DECL_LANGUAGE (fn) = lang_cplusplus;
    set_mangled_name_for_decl (fn);
    return fn;
  }
--- 6743,6749 ----
    tree fn = build_library_fn_1 (name, operator_code, type);
    TREE_NOTHROW (fn) = TYPE_NOTHROW_P (type);
    DECL_CONTEXT (fn) = FROB_CONTEXT (current_namespace);
!   SET_DECL_LANGUAGE (fn, lang_cplusplus);
    set_mangled_name_for_decl (fn);
    return fn;
  }
*************** grokfndecl (ctype, type, declarator, ori
*** 8750,8756 ****
        && ctype == NULL_TREE
        /* NULL_TREE means global namespace.  */
        && DECL_CONTEXT (decl) == NULL_TREE)
!     DECL_LANGUAGE (decl) = lang_c;
  
    /* Should probably propagate const out from type to decl I bet (mrs).  */
    if (staticp)
--- 8750,8756 ----
        && ctype == NULL_TREE
        /* NULL_TREE means global namespace.  */
        && DECL_CONTEXT (decl) == NULL_TREE)
!     SET_DECL_LANGUAGE (decl, lang_c);
  
    /* Should probably propagate const out from type to decl I bet (mrs).  */
    if (staticp)
*************** grokvardecl (type, declarator, specbits_
*** 9022,9030 ****
        else
  	context = NULL_TREE;
  
!       if (processing_template_decl && context)
! 	/* For global variables, declared in a template, we need the
! 	   full lang_decl.  */
  	decl = build_lang_decl (VAR_DECL, declarator, type);
        else
  	decl = build_decl (VAR_DECL, declarator, type);
--- 9022,9034 ----
        else
  	context = NULL_TREE;
  
!       /* For namespace-scope variables, declared in a template, we
! 	 need the full lang_decl.  The same is true for
! 	 namespace-scope variables that do not have C++ language
! 	 linkage.  */
!       if (context 
! 	  && (processing_template_decl 
! 	      || current_lang_name != lang_name_cplusplus))
  	decl = build_lang_decl (VAR_DECL, declarator, type);
        else
  	decl = build_decl (VAR_DECL, declarator, type);
Index: cp/decl2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/decl2.c,v
retrieving revision 1.437.2.11
diff -c -p -r1.437.2.11 decl2.c
*** decl2.c	2001/04/06 06:30:08	1.437.2.11
--- decl2.c	2001/04/19 22:38:33
*************** grokclassfn (ctype, function, flags, qua
*** 1020,1026 ****
  
    /* Even within an `extern "C"' block, members get C++ linkage.  See
       [dcl.link] for details.  */
!   DECL_LANGUAGE (function) = lang_cplusplus;
  
    if (fn_name == NULL_TREE)
      {
--- 1020,1026 ----
  
    /* Even within an `extern "C"' block, members get C++ linkage.  See
       [dcl.link] for details.  */
!   SET_DECL_LANGUAGE (function, lang_cplusplus);
  
    if (fn_name == NULL_TREE)
      {
Index: cp/lex.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/lex.c,v
retrieving revision 1.237.2.3
diff -c -p -r1.237.2.3 lex.c
*** lex.c	2001/04/12 14:17:00	1.237.2.3
--- lex.c	2001/04/19 22:38:33
*************** retrofit_lang_decl (t)
*** 1513,1523 ****
  
    DECL_LANG_SPECIFIC (t) = ld;
    if (current_lang_name == lang_name_cplusplus)
!     DECL_LANGUAGE (t) = lang_cplusplus;
    else if (current_lang_name == lang_name_c)
!     DECL_LANGUAGE (t) = lang_c;
    else if (current_lang_name == lang_name_java)
!     DECL_LANGUAGE (t) = lang_java;
    else my_friendly_abort (64);
  
  #ifdef GATHER_STATISTICS
--- 1513,1523 ----
  
    DECL_LANG_SPECIFIC (t) = ld;
    if (current_lang_name == lang_name_cplusplus)
!     SET_DECL_LANGUAGE (t, lang_cplusplus);
    else if (current_lang_name == lang_name_c)
!     SET_DECL_LANGUAGE (t, lang_c);
    else if (current_lang_name == lang_name_java)
!     SET_DECL_LANGUAGE (t, lang_java);
    else my_friendly_abort (64);
  
  #ifdef GATHER_STATISTICS
Index: cp/mangle.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/mangle.c,v
retrieving revision 1.26.4.6
diff -c -p -r1.26.4.6 mangle.c
*** mangle.c	2001/04/16 05:49:55	1.26.4.6
--- mangle.c	2001/04/19 22:38:33
*************** mangle_decl_string (decl)
*** 2085,2101 ****
    if (TREE_CODE (decl) == TYPE_DECL)
      write_type (TREE_TYPE (decl));
    else if (/* The names of `extern "C"' functions are not mangled.  */
! 	   (TREE_CODE (decl) == FUNCTION_DECL 
  	    /* But overloaded operator names *are* mangled.  */
! 	    && !DECL_OVERLOADED_OPERATOR_P (decl)
! 	    /* If there's no DECL_LANG_SPECIFIC, it's a function built
! 	       by language-independent code, which never builds
! 	       functions with C++ linkage.  */
! 	    && (!DECL_LANG_SPECIFIC (decl) 
! 		|| DECL_EXTERN_C_FUNCTION_P (decl)))
  	   /* The names of global variables aren't mangled either.  */
  	   || (TREE_CODE (decl) == VAR_DECL
! 	       && CP_DECL_CONTEXT (decl) == global_namespace))
      write_string (IDENTIFIER_POINTER (DECL_NAME (decl)));
    else
      {
--- 2085,2099 ----
    if (TREE_CODE (decl) == TYPE_DECL)
      write_type (TREE_TYPE (decl));
    else if (/* The names of `extern "C"' functions are not mangled.  */
! 	   (DECL_EXTERN_C_FUNCTION_P (decl)
  	    /* But overloaded operator names *are* mangled.  */
! 	    && !DECL_OVERLOADED_OPERATOR_P (decl))
  	   /* The names of global variables aren't mangled either.  */
  	   || (TREE_CODE (decl) == VAR_DECL
! 	       && CP_DECL_CONTEXT (decl) == global_namespace)
! 	   /* And neither are `extern "C"' variables.  */
! 	   || (TREE_CODE (decl) == VAR_DECL
! 	       && DECL_EXTERN_C_P (decl)))
      write_string (IDENTIFIER_POINTER (DECL_NAME (decl)));
    else
      {
Index: cp/semantics.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/semantics.c,v
retrieving revision 1.189.2.7
diff -c -p -r1.189.2.7 semantics.c
*** semantics.c	2001/04/18 07:52:56	1.189.2.7
--- semantics.c	2001/04/19 22:38:34
*************** finish_member_declaration (decl)
*** 1858,1864 ****
       A C language linkage is ignored for the names of class members
       and the member function type of class member functions.  */
    if (DECL_LANG_SPECIFIC (decl) && DECL_LANGUAGE (decl) == lang_c)
!     DECL_LANGUAGE (decl) = lang_cplusplus;
  
    /* Put functions on the TYPE_METHODS list and everything else on the
       TYPE_FIELDS list.  Note that these are built up in reverse order.
--- 1858,1864 ----
       A C language linkage is ignored for the names of class members
       and the member function type of class member functions.  */
    if (DECL_LANG_SPECIFIC (decl) && DECL_LANGUAGE (decl) == lang_c)
!     SET_DECL_LANGUAGE (decl, lang_cplusplus);
  
    /* Put functions on the TYPE_METHODS list and everything else on the
       TYPE_FIELDS list.  Note that these are built up in reverse order.

Re: GCC 3.0 Status Report

[John David Anglin]

> The things I don't like (but that aren't your fault!)
> 
>   - Users of DECL_LANGUAGE shouldn't have to check DECL_LANG_SPECIFIC.
>     That's an abstraction breakdown; the fact that DECL_LANG_SPECIFIC
>     is optional is an implementation detail.  That's bothered me
>     for a while; now I'll fix it.

Yes, I stumbled on that one the first time through.  Good idea.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Phil Edwards]

On Wed, Apr 18, 2001 at 07:51:25PM -0700, Mark Mitchell wrote:
> 
> I suspect Jason made this change because something in the standard C++
> library requires this, and you can't rely on c++config.h being
> included soon enough.

I had played around at one point with the idea of c++config.h being
-include'd by all C++ programs, via the default specs.  A cow-orker did so
in a local tree, and it caused problems all over the place.  IIRC some C++
feature tests were failing during autoconf.  We concluded that we didn't
know how to properly augment the lang-specs file...

Anyhow, since c++config.h includes os_defines.h, this approach would
obviate the need for CPLUSPLUS_CPP_SPEC on AIX and the like.  Just put
the defines in os_define.h and every translation unit will see them.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: GCC 3.0 Status Report

[Mark Mitchell]

I'm going to tweak that around a little bit, and install it.

The things I don't like (but that aren't your fault!)

  - Users of DECL_LANGUAGE shouldn't have to check DECL_LANG_SPECIFIC.
    That's an abstraction breakdown; the fact that DECL_LANG_SPECIFIC
    is optional is an implementation detail.  That's bothered me
    for a while; now I'll fix it.

Thanks again,

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

Re: GCC 3.0 Status Report

[John David Anglin]

> The g++ testsuite on native solaris is good for seeing the bug.
> I have "std::errno" errors in tests like g++.benjamin/15071.C and
> g++.brendan/copy9.C.

Hpux also has the bug, however, there are still problems building
libstdc++ under it due to duplicate symbol definitions.  I ran the
the check under i686 linux to make sure I didn't break something
else.  It would be great if you could try the patch on solaris.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Michael Elizabeth Chastain]

> I have checked that `namespace std { extern "C" int errno; }' is not
> mangled under hpux and I don't see any regressions of the libstdc++
> or g++ testsuite under i686 linux.

Note that libstdc++ on i686 linux doesn't show the original bug,
because errno is a macro on that platform, and the expansion of
that macro uses a function and not a data symbol:

  #define errno (*__errno_location ())

The automated regression checker has native linux and I think that's
why it didn't catch this bug.

The g++ testsuite on native solaris is good for seeing the bug.
I have "std::errno" errors in tests like g++.benjamin/15071.C and
g++.brendan/copy9.C.

Michael

Re: GCC 3.0 Status Report

[John David Anglin]

> It's not a patch -- the patch fragment you see is the patch that
> broke g++ (I think).  I don't know enough about g++ data structures
> to write a good patch.

Here is a fix for the undefined reference std::errno.  The language
experts can debate whether it is the right thing to do.  I have checked
that `namespace std { extern "C" int errno; }' is not mangled under
hpux and I don't see any regressions of the libstdc++ or g++ testsuite
under i686 linux.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2001-04-18  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* mangle.c (mangle_decl_string): Don't mangle variables with
	extern "C" linkage.
	* decl.c (grokvardecl): Use full language declaration for `extern'
	variables.

--- mangle.c.orig	Tue Apr 17 14:38:43 2001
+++ mangle.c	Wed Apr 18 20:29:54 2001
@@ -2093,9 +2093,11 @@
 	       functions with C++ linkage.  */
 	    && (!DECL_LANG_SPECIFIC (decl) 
 		|| DECL_EXTERN_C_FUNCTION_P (decl)))
-	   /* The names of global variables aren't mangled either.  */
+	   /* The names of global and extern "C" variables aren't
+	      mangled either.  */
 	   || (TREE_CODE (decl) == VAR_DECL
-	       && CP_DECL_CONTEXT (decl) == global_namespace))
+	       && (CP_DECL_CONTEXT (decl) == global_namespace
+		   || (DECL_LANG_SPECIFIC (decl) && DECL_EXTERN_C_P (decl)))))
     write_string (IDENTIFIER_POINTER (DECL_NAME (decl)));
   else
     {
--- decl.c.orig	Mon Apr 16 17:58:53 2001
+++ decl.c	Thu Apr 19 14:58:37 2001
@@ -9022,9 +9022,10 @@
       else
 	context = NULL_TREE;
 
-      if (processing_template_decl && context)
-	/* For global variables, declared in a template, we need the
-	   full lang_decl.  */
+      if (RIDBIT_SETP (RID_EXTERN, specbits)
+	  || (processing_template_decl && context))
+	/* For `extern' variables or variables declared in a template,
+	   we need the full lang_decl.  */
 	decl = build_lang_decl (VAR_DECL, declarator, type);
       else
 	decl = build_decl (VAR_DECL, declarator, type);

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Gabriel" == Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr> writes:

    Gabriel> Mark Mitchell <mark@codesourcery.com> writes:

    Gabriel> | I suspect Jason made this change because something in
    Gabriel> the standard C++ | library requires this, and you can't
    Gabriel> rely on c++config.h being | included soon enough.

    Gabriel> Hmm, if that is the case, then that thing needs to be
    Gabriel> isolated.

    Gabriel> Andreas has a sensible point.

Yes.  I thought *I* posted some comments along these lines to the V3
mailing list at one point.

The basic problem is that some parts of the C++ library rely on some
parts of the C ibrary beyond what the ANSI/ISO C library provides.

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

Re: GCC 3.0 Status Report

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| I suspect Jason made this change because something in the standard C++
| library requires this, and you can't rely on c++config.h being
| included soon enough.

Hmm, if that is the case, then that thing needs to be isolated.

Andreas has a sensible point.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Mark Mitchell]

I suspect Jason made this change because something in the standard C++
library requires this, and you can't rely on c++config.h being
included soon enough.

In any case, Jason is probably the best person to contact about the
change.

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

Re: GCC 3.0 Status Report

[John David Anglin]

> >>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:
> 
> First, note that Vax Ultrix is not a primary platform the release, so
> these patches are not a high priority for me.
> 
>     John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html

I understand your priorities but as I noted this problem affects all
ports.  Hey, next time I will provide an analysis on the i386!  What
I am saying is that you have to be careful in ignoring problems on
low priority targets because they may well affect the high priority
ones as well.

> I would prefer a patch that simply did something like:
> 
>   minnode = build_int_2 (TREE_INT_CST_LOW (minnode),
>                          TREE_INT_CST_HIGH (minnode));
>   if (unsignedp)
>     TREE_TYPE (minnode) = unsigned_type_node;
> 
> I think the hack where you adjust things according to the signedness
> at the end is confusing.

The sign adjustment at the end is a bit of a hack but it was a compromise
which allows just one pass through the values as before, and an overall
simplification of the code.

I don't believe your suggestion works directly because minnode has
has the signedness of enumtype after the loop.  The testing for signed
values could be put into the loop as in my patch.

I liked the idea of using the actual type and precision specified in
the original values for the minimum precision estimation, rather than
copying the min and max nodes after the loop and resetting their type
and precision.  Doing the precision calculation in the loop is probably
less complicated than the comparisons needed to determine the min and
max values in the list.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Michael Elizabeth Chastain]

Hi Jeff,

I picked up a fragment of a message that looks like it came from you:

http://gcc.gnu.org/ml/gcc/2001-04/msg00874.html
> The most common problem I see is due to the std::errno failures.  So if
> someone has a workaround/fix for that I would greatly appreciate a copy.

I analyzed this and found the patch fragment that broke it.
See PR libstdc++/2445 for the whole story.  Here's some URL's:

  http://gcc.gnu.org/ml/gcc-prs/2001-04/msg00272.html
  http://gcc.gnu.org/ml/gcc-prs/2001-04/msg00273.html

If I am misreading the gcc mailing list archive and you're not
the guy quoted above, my apologies.

(I'm frustrated because I keep seeing people reporting this bug, and I
know what the problem is, but my PR and my mail to gcc@gcc.gnu.org are
lost in the noise).

Michael

Re: GCC 3.0 Status Report

[John David Anglin]

> The most common problem I see is due to the std::errno failures.  So if 
> someone has a workaround/fix for that I would greatly appreciate a copy.

See < http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/c_std/bits/std_cerrno.h.diff?cvsroot=gcc&r1=1.5&r2=1.6 >
for what was done on the main.  This probably isn't the correct solution.
It looks like extern "C" identifiers shouldn't be mangled in namespaces.

I did a couple more tests night to try to diagnose the constructor problem.
However, when I changed CFLAGS to `-O0 -g', I ran smack into the duplicate
symbol problem building libstdc++-v3.  Functions (constructors) that wannabe
weak are getting duplicated in two or more modules as global functions with
weak support turned off.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[John David Anglin]

> I think that probably the other part is correct, but can you explain
> it in more detail?  Not what the problem is (I get that), but why your
> fix is the correct approach?

I am not entirely certain the approach is correct as my knowledge of
C++ and g++ is limited.  Can you see another way to copy the result
without using build_aggr_init?

My approach was based on debugging the existing code.  The call_expr
is converted by ocp_convert to a tree expression containing another
aggr_init_expr in expand_default_init.  Here is the code there:

      if (flags & DIRECT_BIND)
	/* Do nothing.  We hit this in two cases:  Reference initialization,
	   where we aren't initializing a real variable, so we don't want
	   to run a new constructor; and catching an exception, where we
	   have already built up the constructor call so we could wrap it
	   in an exception region.  */;
      else if (TREE_CODE (init) == CONSTRUCTOR)
	/* A brace-enclosed initializer has whatever type is
	   required.  There's no need to convert it.  */
	;
      else
        init = ocp_convert (type, init, CONV_IMPLICIT|CONV_FORCE_TEMP, flags);

It looked to me like the call was already built, so adding DIRECT_BIND
to the flags was the right thing to do to prevent the conversion.  However,
maybe the code here should be checking for a CALL_EXPR.  There is this
comment for build_aggr_init:

   If INIT resolves to a CALL_EXPR which happens to return
   something of the type we are looking for, then we know
   that we can safely use that call to perform the
   initialization.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

The following patch needs approval:

http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00236.html

Without that it is impossible to compile standard compliant code that uses
names that are conflicting with the extensions declared by _GNU_SOURCE.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

First, note that Vax Ultrix is not a primary platform the release, so
these patches are not a high priority for me.

    John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html

I would prefer a patch that simply did something like:

  minnode = build_int_2 (TREE_INT_CST_LOW (minnode),
                         TREE_INT_CST_HIGH (minnode));
  if (unsignedp)
    TREE_TYPE (minnode) = unsigned_type_node;

I think the hack where you adjust things according to the signedness
at the end is confusing.

    John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00817.html

Certainly the bit about setting old_ac is correct.  I'll install that
part of the change.  

I think that probably the other part is correct, but can you explain
it in more detail?  Not what the problem is (I get that), but why your
fix is the correct approach?

I'm not sure that it's possible to get correct C++ semantics with the
PCC calling convention; you might end up with too many copy
constructors, for example.

ChangeLogs shouldn't have justifications in them.  They should go in
the code instead.

Thanks,

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

Re: GCC 3.0 Status Report

[John David Anglin]

Mark,

I would like to draw your attention to these two g++ patches
which I would like considered for both branch and main:

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

The first one potentially affects all targets.  The second
only affects targets that define PCC_STATIC_STRUCT_RETURN.
However, it is crucial to g++ being usable.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[John David Anglin]

> | I am currently doing a build with a hack to avoid the std::errno
> | problem with respect to libstdc++-v3.
> 
> I think the std::errno problem you're seeing is an instance of a
> bigger problem^W regresssion in the front-end -- I was privately told
> that g++ is mangling names declared in extern "C" blocks.  I didn't
> have the opportunity to take a closer look at it, however :-(

Yes, I would certainly believe this to be the case when the extern "C" blocks
are in a namespace.  However, I don't think this is the reason there is
a problem running constructors in a shared library under hpux.  In the
one test program that I tried, it did run successfully when linked with
`-static'.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Gabriel Dos Reis]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

| I am currently doing a build with a hack to avoid the std::errno
| problem with respect to libstdc++-v3.

I think the std::errno problem you're seeing is an instance of a
bigger problem^W regresssion in the front-end -- I was privately told
that g++ is mangling names declared in extern "C" blocks.  I didn't
have the opportunity to take a closer look at it, however :-(

-- Gaby

Re: GCC 3.0 Status Report

[Mark Mitchell]

Thanks a lot for putting this together!  That's a great summary.

I'll look at some of the failures.

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

Re: GCC 3.0 Status Report

[Toon Moene]

Here's an update on the Fortran status:

There are 9 non-closed bug reports in the GNATS database on Fortran and
1 on libf2c.

Fortran:

 275: An ICE on a -O1 -mabi=64 compile on mips-sgi-irix6.5
      This is a regression w.r.t. 2.95.2

 542: g77 doesn't support direct access files larger than 2Gbyte on
      32-bit targets
      A feature request - suspended

 947: An assert on using an INTEGER*2 value as an array index in a
      DATA statement - a genuine frontend error
      This is not a regression

1645: This is g77.f-torture/execute/20010116.f.  Fails on i?86
      This is a regression w.r.t. 2.95.3

1832: g77 -fbounds-check doesn't catch string bounds overrun on
      internal write
      This has always been uncaught - no regression

2031: This is g77.f-torture/compile/20000511-2.f.  Fails on
      mips-sgi-irix6.5 with -O3 -g
      This is a regression w.r.t. 2.95

2033: g77 -ffixed-line-length-none blah.f gives warning:
      unknown register name: line-length-none
      Cute, but wrong - a regression w.r.t. 2.95.3

2153: g77 gives misleading error message when dummy argument of a
      statement function is also declared as an array.
      A feature request - this has been wrong always - suspended.

2193: An installation failure on HPUX 10.20 of 2.95.2 (perhaps someone
      with HPUX experience can look into this one ?)

libf2c:

 941: Configure fails on libf2c when cross-compiling because the
      configure script uses auto-host.h which is host, not target,
      specific
      Way beyond my understanding of the cross-compiling infrastructure

Hope this is useful,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.0 Status Report

[John David Anglin]

Forwarded message:
From dave Tue Apr 17 19:11:04 EDT 2001
Subject: Re: GCC 3.0 Status Report
To: gcc@gcc.gn.org, law@redhat.com
Date: Tue, 17 Apr 2001 19:11:04 -0400 (EDT)
From: "John David Anglin" <dave@hiauly1>
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2640      

> Last Week
> =========

> Jeff Law reported some initial success building GCC 3.0 on HPUX.  The
> compiler is now bootstrapping, but libstdc++ V3 is still not working.
> If you can help out with the debugging task (either because you're a
> PA expert or a V3 expert or a general GCC expert), please do so.  The
> best way to help is probably to contact Jeff Law (law@redhat.com)
> directly.

I am currently doing a build with a hack to avoid the std::errno
problem with respect to libstdc++-v3.  However, the number of failures
is still about the same:

                === g++ Summary for unix/-fPIC ===

# of expected passes            5531
# of unexpected failures        868
# of unexpected successes       2
# of expected failures          93
# of untested testcases         20

I looked at one of them briefly.  The test builds and runs successfully
if linked with `-static'.  When linked with the shared libstdc++-v3,
the test fails almost immediately with a segmentation fault (I think
running __cxx_new_vec.  When I try to single step with gdb, it dumps
core.  It helps to link with immediate binding.  Adb works better than
gdb.  Maybe this gives a clue as to the problem:

>adb g++-bugs-900220_03-C.x
:r
g++-bugs-900220_03-C.x: running (process 4061)
segmentation violation
stopped at      0xC132DA80:     LDW             1980(r20),r20
0xC132DA70,8?ia
0xC132DA70:     LDW             -260(r30),r19
0xC132DA74:     STW             r28,-256(r30)
0xC132DA78:     ADDIL           L%0xffff7000,r19
0xC132DA7C:     OR              r1,r0,r20
0xC132DA80:     LDW             1980(r20),r20
0xC132DA84:     OR              r20,r0,r22
0xC132DA88:     LDWS            0(r20),r20
0xC132DA8C:     LDO             1(r20),r20
0xC132DA90:
$r
pcoqh 0xC132DA83
pcoqt 0xC132DA87
rp    0xC132DA73

arg0  7B006C90      arg1  0             arg2  0             arg3  7AFF289C
sp    7B03AE60      ret0  7B006BB0      ret1  10C8C00       dp    40001308
r1    0xFFFF7000    r3    7AFFA89C      r4    1             r5    7B03A730
r6    7B03A738      r7    7B03A860      r8    7B03A860      r9    4003A2C0
r10   4003AAC0      r11   400372C0      r12   4003AB04      r13   3F
r14   3F            r15   3D            r16   3D            r17   3A
r18   40036822      r19   0             r20   0xFFFF7000    r21   0xC0087EC0
r22   7B006BB0      r31   7B006C90      sar   8             sr0   0
sr1   1138          sr2   5A94          sr3   0             sr4   62DE

The address in r20 is clearly wacko.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)


-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Michael Elizabeth Chastain]

Hi GCC hackers,

I have some insight on a libstdc++ V3 problem that's been hitting hpux
and irix and solaris (the std::errno problem).  I wrote a long analysis
in PR libstdc++/2445.

I think the problem is in the attached patch fragment which was committed
on 2001-03-20.  It handles function names, and it handles global data
names, but it doesn't handle extern "C" data names within namespaces.
So this construct fails:

  namespace std { extern "C" int errno; }

The "errno" name shouldn't get mangled, but it does.

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

===

diff -u -r -N 2001-03-20-14-00-00/source/gcc/cp/mangle.c 2001-03-20-14-05-00/source/gcc/cp/mangle.c
--- 2001-03-20-14-00-00/source/gcc/cp/mangle.c	Thu Feb 22 13:37:39 2001
+++ 2001-03-20-14-05-00/source/gcc/cp/mangle.c	Tue Mar 20 14:03:45 2001
@@ -2069,6 +2069,17 @@
 
   if (TREE_CODE (decl) == TYPE_DECL)
     write_type (TREE_TYPE (decl));
+  else if (/* The names of `extern "C"' functions are not mangled.  */
+	   (TREE_CODE (decl) == FUNCTION_DECL 
+	    /* If there's no DECL_LANG_SPECIFIC, it's a function built
+	       by language-independent code, which never builds
+	       functions with C++ linkage.  */
+	    && (!DECL_LANG_SPECIFIC (decl) 
+		|| DECL_EXTERN_C_FUNCTION_P (decl)))
+	   /* The names of global variables aren't mangled either.  */
+	   || (TREE_CODE (decl) == VAR_DECL
+	       && CP_DECL_CONTEXT (decl) == global_namespace))
+    write_string (IDENTIFIER_POINTER (DECL_NAME (decl)));
   else
     {
       write_mangled_name (decl);

GCC 3.0 Status Report

[Mark Mitchell]

Last Week
=========

Jeff Law reported some initial success building GCC 3.0 on HPUX.  The
compiler is now bootstrapping, but libstdc++ V3 is still not working.
If you can help out with the debugging task (either because you're a
PA expert or a V3 expert or a general GCC expert), please do so.  The
best way to help is probably to contact Jeff Law (law@redhat.com)
directly.

Many bugs were fixed by a wide variety of people.

I closed about 25 high-priority bug reports in GNATS, many of which
represented regressions from GCC 2.95.x.  Others represented bugs that
were already fixed, or that were not really bugs.

Jeffrey Oldham began looking into problems (again!) with building GCC
3.0 on IRIX.  Apparently, some change somewhere has caused us to
exceed static limits in the IRIX linker when building libstdc++ V3.
This may require libtool modifications to fix.

Next Week
=========

More of the same, mostly.

We are making relatively good progress at this point; stabilization
seems to be occurring.

Kudos
=====

For working hard on fixing IA64 bugs , and for lending a hand with a
number of tricky issues, including DWARF2 debugging and obscure
historical artifcats of GCC, this week's GCC 3.0 Volunter of the Week
is ...

  ... Jim Wilson!

Congratulations!

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

Re: GCC 3.0 Status Report

[Toon Moene]

"Joseph S. Myers" wrote:

> On Tue, 3 Apr 2001, Mark Mitchell wrote:

> > Not too much happenned last week.

> What is the status of review of open bugs?

Fortran: 8 open, 2 analyzed, 3 suspended (change-request, 1 duplicate).
Libf2c:  1 open.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Tue, 3 Apr 2001, Mark Mitchell wrote:

> Not too much happenned last week.  

What is the status of review of open bugs?  GNATSweb shows 663 PRs in
state "open" - i.e. unreviewed, presuming that reviewers have changed the
state to "analyzed" when confirming bugs.  (Some of these are recent PRs,
but plenty aren't.)

>   If people would begin building commonly used programs (XWindows,
>   Emacs, etc.) with the GCC 3.0 branch and reporting any problems, 
>   that would be great.  I will set up a more formal mechanism for that
>   shortly.

I'll suggest again that, though not in the release criteria, TeX is a
worthwhile program to try to build, since there have been problems
triggered by TeX in more than one previous release.

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

GCC 3.0 Status Report

[Mark Mitchell]

Not too much happenned last week.  

I moved from near Palo Alto, CA to near Sacramento, CA, so I saw a lot
more of Pottery Barn than I did of GCC.  Pottery Barn definitely has
better lighting. :-)

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

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

Overall
-------

  If people would begin building commonly used programs (XWindows,
  Emacs, etc.) with the GCC 3.0 branch and reporting any problems, 
  that would be great.  I will set up a more formal mechanism for that
  shortly.
 
  Bug-fixing continues on the branch.

  Although not directly related to the release, Jeffrey Oldham
  collected some interesting statistics about how often GCC has failed
  to bootstrap recently.  There was some interesting follow-on
  discussion.

Last Week
---------
   
  Neil Booth merged over some preprocessor improvements, which
  are expected to be the last major preprocessor changes before
  the release.

  Many other people contributed miscellaneous bug fixes.

Next Week
---------

  More bug fixing.  Hopefully prepare test kits.  

  Application testing.

Re: GCC 3.0 Status Report

[David Edelsohn]

	My list of remaining AIX gcc-3.0 bugs is:

PPC fast-math bugfix (Geoff)
g77 __builtin_sqrt missing symbol regression on branch
expr.c argument passing patch (from Feb)
--shared-libgcc conflicts with --shared

David

GCC 3.0 Status Report

[Mark Mitchell]

Only one day late this week...

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

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

Overall
-------

  Relatively little happenned.  In a way, this is a good thing; I
  think we are getting close to having most of the major bug
  fixes incorporated that we will need.

  Application testing should become the major focus at this point.

Last Week
---------

  Jason Merill cleaned up some issues involving `.' and `$' in 
  identifiers.  

  I checked in various patches to improve compile-time time and
  space usage in C++, including lazy name-mangling and throttling
  of the tree-based inliner.

  Jim Wilson and Jakub Jelinek cleaned up after me when I broke
  things.

Kudos
-----

  For volunteering to track down an obscure bug, and succeeding in
  doing so, despite my fervent attempts to lead him down a wrong
  path, the GCC 3.0 Volunteer of the Week is ...

    ... Richard Kenner!

  Congratulations!

Next Week
---------

  Application testing.

  Fix critical bugs.

RE: GCC 3.0 Status Report

[Peter Bienstman]

>Last Week
>---------
>
>  Analysis of open bugs is largely complete.  Many of the remainder
>  are hard to analyze due to being target-specific in various ways.

Strange, GNATS still lists almost 600 bug reports in the 'open' state, i.e.
not analysed by anyone.

Are these reports that people have looked at, but forgot to put in the
'analysed' state?

Peter

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

    Stan> Daniel Berlin wrote:
    >>  Stan Shebs <shebs@apple.com> writes:
    >> 
    >> > I'd certainly like to take a look!  In OS X we have a working

Me, too!

I meant to imply no criticism.  

Whenever anyone does a design/implementation of feature X privately,
it is appropriate for everyone else to take a look at it, rather than
just saying "oh, good now we have X".

I've heard of about 5 different ways to do precompiled headers -- and
each has their strengths and weaknesses.  From what I've heard
(including offline discussions with Geoff), I think a pretty
reasonable set of tradeoffs has been made in this case.

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

Re: GCC 3.0 Status Report

[Stan Shebs]

Daniel Berlin wrote:
> 
> Stan Shebs <shebs@apple.com> writes:
> 
> > I'd certainly like to take a look!  In OS X we have a working example
> > of precompiled headers to compare for functionality and ease of use,
> > and I'd like to know if the Red Hat version will be adequate.
> >
> Last I checked, the OS-X version is implemented as a seperate program,

Yes, it's a semi-intelligent cpp, written in Objective-C++ no less.

> and doesn't work for C++ 

Heh, I spent a good chunk of last year making it parse C++; learned
a little more about the fine points of C++ syntax than I really
wanted to know. :-)  You'll see the result of that work for the
first time in OS X GM - although it's not enabled by default, use
cc -cpp-precomp to get it.

In any case, by "adequate" I just mean the way the precomp system fits
into large-scale builds.  Although Apple's precomp setup is not the
ideal, without it OS X would be shipping months from now, not at the
end of the week.  As Geoff noted, it's one thing to have a first working
version, and another to have passed many millions of lines of code
through it.

Stan

Re: GCC 3.0 Status Report

[Daniel Berlin]

Stan Shebs <shebs@apple.com> writes:

> I'd certainly like to take a look!  In OS X we have a working example
> of precompiled headers to compare for functionality and ease of use,
> and I'd like to know if the Red Hat version will be adequate.
> 
Last I checked, the OS-X version is implemented as a seperate program,
and doesn't work for C++ (Admittedly, I haven't touched the OS X
developer tools since the public beta really, but that's the last
visible release i've had access to, as my CD with a release candidate
from the student program hasn't arrived yet).
So I wouldn't consider it adequate anyway.
No offense or anything, it's just worthless to me (and a lot of
others) if it doesn't work with C++.




> Stan

Re: GCC 3.0 Status Report

[Stan Shebs]

Mark Mitchell wrote:
> 
> Of course, if 3.0 is unusably slower than 2.95 (and some have claimed
> that), then what we do in 3.1 doesn't really matter much.

As usual with FSF releases, there is a wide spectrum of reactions.
x.0 releases typically get a lot of slack; everybody realizes that
they're a step forward, and are not going to insist on perfection.
Back in the 1 -> 2 transition, 1.x went through several more releases
after 2.0 came out, and a 2.x compiler didn't get really wide usage
until 2.3 or so.  The key thing is to hear from the clients (users
and redistributors) whether they're satisfied with the branch as it
stands.

In Apple's own case, we're unlikely to use 3.0 for production, but a
3.1 in the fall would be pretty interesting, especially with a good
PCH implementation.  So it doesn't really matter to us if 3.0 has
problems, because we'll be working on the latest code, but a long
delayed release will push back the dates for followon, and that would
be more of a concern.

> Also, it's fair to point out that there's no guarantee that your PCH
> work will ever go into the FSF GCC.  The design will have to be vetted
> on the FSF lists before that happens.  I don't expect there to be
> problems, but, as with any contribution, all the issues have to be
> weighed before anything on this scale is accepted.

I'd certainly like to take a look!  In OS X we have a working example
of precompiled headers to compare for functionality and ease of use,
and I'd like to know if the Red Hat version will be adequate.

Stan

Re: GCC 3.0 Status Report

[Geoff Keating]

Daniel Berlin <dberlin@redhat.com> writes:

> Most of the 4 seconds seems to get spent in a GC right after it sees
> the first thing in the implementation (I assume it's starting to
> lazy load things from the PCH headers at this point and there is a
> ggc_collect where it isn't the best idea anymore, or PCH is creating
> a lot of objects that aren't goint to be gotten rid of, since the GC
> reclaims just about nothing).

Yes, what happens is that the PCH machinery reads zillions of objects
from the file, and then the very next time that ggc_collect is called
it sees that lots of memory has been allocated and it tries to
collect.  Of course, this is never going to be helpful, since all of
those zillions of objects are referenced otherwise they wouldn't have
been saved in the first place.

Probably the thing to do is to have the PCH machinery add to
G.allocated_last_gc the size of the objects it allocates, because it
knows those objects will not be collectable before the next
ggc_collect().


There's no lazy loading yet.  Everything is loaded in at once.  That's
one of the reasons I'm so impressed with the big speed increase, that
was the kind of increase we were hoping to get out of PCH+lazy loading.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC 3.0 Status Report

[Daniel Berlin]

Geoff Keating <geoffk@geoffk.org> writes:

> Mark Mitchell <mark@codesourcery.com> writes:
> 
> >   In the short term, we will focus on compile-time performance, 
> >   especially in C++.  At that point, application testing will 
> >   become the major focus.  Performance of the generated code
> >   will be a greater focus of the 3.1 release.
> 
> Hi Mark,
> 
> I have some news for you, which might be good or might be bad, your
> choice :-).
> 
> Jason Merrill took over the PCH stuff from where I left it, and
> finished the C++ support.  Based on the numbers I had for C, I
> expected a 2x or 3x speed improvement, which is nice but not
> earth-shattering.  However, we have some new numbers from Daniel
> Berlin which indicates that the speed improvement is more on the order
> of 20x, when compiling KDE; I guess I just didn't realize how huge C++
> headers were.

Just to give you some idea of the largeness of C++ headers, I took a
random KDE app, khotkeys, took all of the headers it includes that
aren't specific to itself (IE those in qt2/include and kde2/include
only), through them in a file, and -save-temps'd it, and removed
blank lines, to see how much code it was:

bash-2.04# cat test.cc
#include "test.h"
bash-2.04# cat test.h
#include <kapp.h>
#include <klineedit.h>
#include <kwin.h>
#include <krun.h>
#include <kdesktopfile.h>
#include <ksimpleconfig.h>
#include <kurifilter.h>
#include <kstddirs.h>
#include <kdebug.h>
#include <kuniqueapp.h>
#include <qtimer.h>
#include <dcopobject.h>
#include <kurifilter.h>
#include <kglobalaccel.h>
bash-2.04# remblanklines test.ii
bash-2.04# wc test.ii
   8780   38085  300160 noblanks
This isn't uncommon, and is the very low end (khotkeys is three C++
files, total). 

--Dan

Re: GCC 3.0 Status Report

[Daniel Berlin]

Geoff Keating <geoffk@geoffk.org> writes:

> Mark Mitchell <mark@codesourcery.com> writes:
> 
> >   In the short term, we will focus on compile-time performance, 
> >   especially in C++.  At that point, application testing will 
> >   become the major focus.  Performance of the generated code
> >   will be a greater focus of the 3.1 release.
> 
> Hi Mark,
> 
> I have some news for you, which might be good or might be bad, your
> choice :-).
> 
> Jason Merrill took over the PCH stuff from where I left it, and
> finished the C++ support.  Based on the numbers I had for C, I
> expected a 2x or 3x speed improvement, which is nice but not
> earth-shattering.  However, we have some new numbers from Daniel
> Berlin which indicates that the speed improvement is more on the order
> of 20x, when compiling KDE; I guess I just didn't realize how huge C++
> headers were.   Dan says 'I can now compile all of KDE in the time it
> took to compile one file before'.

One directory, not one file.
It's "almost" that fast, however.

Even on secondary platforms, like BeOS (the original tests were done
on my powerbook running powerpc-linux), i see similar speed
improvements (a factor of 15 to 24).

For instance, one large C++ project i work on, it takes at least 30 seconds
just to finish including all the headers on quite a few of the
files. This means I actually ended 
up having to stuff as many implementations of misc classes as possible
in single files, or files where they didn't belong, to avoid massive compilation times. 
For a test, I seperated these misc classes out,and without PCH, it
takes about 5-10  minutes to compile these 10 simple (< 100 lines) class
implementations, that happen to require a lot of headers
(not my fault, nor could it really be avoided. A lot of mixins and whatnot).

Even doing a single one of these files without PCH takes about a
minute to two minutes.
With PCH on, it takes 4 seconds per file, including the time from
start to object file appearing.
And fork is pretty slow on BeOS  (it's one of those "takes a while to
run configure" platforms).
I'm not joking.

Most of the 4 seconds seems to get spent in a GC right after it sees the first
thing in the implementation (I assume it's starting to lazy load
things from the PCH headers at this point and there is a ggc_collect
where it isn't the best idea anymore, or PCH is creating a lot of
objects that aren't goint to be gotten rid of, since the GC reclaims
just about nothing).


On C programs, I see about the performance improvement you do (I took
evolution, 
precompiled  glib, gtk, and the includes that are most used in
evolution (camel.h, etc), and got a 2-3x compile time improvement).
> So my proposal is that compile-time performance for the 3.0 release be
> downgraded in importance; that we move as much as possible of PCH into
> the mainline FSF tree as soon as possible, so that others can work on
> it and so that it can be integrated into the 3.1 release; and that the
> main feature of the 3.1 release will be compile-time speed
> improvements, much of which will be provided by precompiled headers.
> 
> Of course, there are some things that could be done that would speed
> up 3.0 and speed up PCH even more; for instance, GC is one of the
> things that take more time with PCH because PCH creates lots of
> permanent objects right at the start of compilation, so improvements
> to how GC handles permanent objects will be a big win.

This must be what I just noticed with the GC taking most of the 4
seconds.

-- 

Hackers have kernel knowledge.

Re: GCC 3.0 Status Report

[Mark Mitchell]

Thanks for the news; it's very helpful to know about the current
state, and the performance wins sound great.

Of course, if 3.0 is unusably slower than 2.95 (and some have claimed
that), then what we do in 3.1 doesn't really matter much.

Also, it's fair to point out that there's no guarantee that your PCH
work will ever go into the FSF GCC.  The design will have to be vetted
on the FSF lists before that happens.  I don't expect there to be
problems, but, as with any contribution, all the issues have to be
weighed before anything on this scale is accepted.

Your points regarding GC are right on the money.  I've got half-way
sort-of patches to do generational GC, which will solve the permanent
object problem, and should provide a major win.  But, nothing in
anything like finished form yet.

Thanks,

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

Re: GCC 3.0 Status Report

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

>   In the short term, we will focus on compile-time performance, 
>   especially in C++.  At that point, application testing will 
>   become the major focus.  Performance of the generated code
>   will be a greater focus of the 3.1 release.

Hi Mark,

I have some news for you, which might be good or might be bad, your
choice :-).

Jason Merrill took over the PCH stuff from where I left it, and
finished the C++ support.  Based on the numbers I had for C, I
expected a 2x or 3x speed improvement, which is nice but not
earth-shattering.  However, we have some new numbers from Daniel
Berlin which indicates that the speed improvement is more on the order
of 20x, when compiling KDE; I guess I just didn't realize how huge C++
headers were.  Dan says 'I can now compile all of KDE in the time it
took to compile one file before'.

I think this is such a significant improvement that it makes
consideration of compile-time improvements in the current compiler
much less important.  Of course, a 20% increase is still a significant
increase, but I expect the profile of GCC with PCH to be different to
that for GCC without PCH, and so it might be that a 5% increase goes
turns out to be a .5% increase.  I don't think anyone has tried tuning
the PCH code for performance yet, for instance, and there are a bunch
of places where I noted a possible speed problem when I was writing it
and designed the code so that if it became a problem it could easily
be improved.

The state of this code is that we're just about to ship it to the
customer.  We've stopped finding bugs in it, but probably only because
we've run out of things we know to test.  It basically works, but
there's still significant work to do before it's really finished, in
particular there's a lot of duplicated functionality between the PCH
code and the GC code.  We could put it into FSF GCC right now, at the
cost of some instability, but it's not tested enough to be in the 3.0
release.  Also, the customer hasn't accepted the release yet, and we
don't usually submit stuff until it's paid for, at least not all of
it, and I expect final acceptance for this code to take longer than
usual not least of which because I expect the customer to try it on
their sources and find lots of bugs.

So my proposal is that compile-time performance for the 3.0 release be
downgraded in importance; that we move as much as possible of PCH into
the mainline FSF tree as soon as possible, so that others can work on
it and so that it can be integrated into the 3.1 release; and that the
main feature of the 3.1 release will be compile-time speed
improvements, much of which will be provided by precompiled headers.

Of course, there are some things that could be done that would speed
up 3.0 and speed up PCH even more; for instance, GC is one of the
things that take more time with PCH because PCH creates lots of
permanent objects right at the start of compilation, so improvements
to how GC handles permanent objects will be a big win.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Craig" == Craig Rodrigues <rodrigc@mediaone.net> writes:

    Craig> Has the Committee decided to reduce the number of
    Craig> applications which must compile as an acceptance criteria
    Craig> for a gcc 3.0 release?  (I'm referring to the ones on:
    Craig> http://gcc.gnu.org/gcc-3.0/criteria.html ).

Not at this time.

    Craig> Has any thought been given to using something like Blitz
    Craig> ( http://oonumerics.org/blitz/ , a C++ library for doing
    Craig> matrix mathematics which makes very aggressive use of
    Craig> templates) for testing the template features in gcc 3.0?

POOMA is even more aggressive than Blitz in this respect.

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

Re: GCC 3.0 Status Report

[Craig Rodrigues]

On Mon, Mar 19, 2001 at 12:28:04PM -0800, Mark Mitchell wrote:
> Overall
> -------
> 
>   The Steering Committee has concluded that the release criteria
>   are somewhat over-ambitious given the lack of resources available
>   to complete some of the tasks.
> 
>   Therefore, the GCC 3.0 release will be largely a functionality
>   release, featuring the rewritten x86 back-end, improved Java
>   compiler, new C++ ABI, and new C++ standard library.  Stability
>   will remain a focus, but quality of the generated code will
>   become a secondary priority.  This withstanding, we believe that
>   GCC 3.0 will generate better code than GCC 2.95.x in many 
>   circumstances.

Has the Committee decided to reduce the number of applications
which must compile as an acceptance criteria for a gcc 3.0 release?
(I'm referring to the ones on: http://gcc.gnu.org/gcc-3.0/criteria.html ).

The criteria web page lists a set of platforms on which gcc 3.0 must
build and work in order for the 3.0 release to be accepted.
Must the applications listed on this web page compile and run on
all the acceptance platforms?  (this does not make sense for things
like compiling the Linux kernel under Solaris, but it may make sense for
Emacs or POOMA).

Has any thought been given to using something like
Blitz ( http://oonumerics.org/blitz/ , a C++ library for doing matrix
mathematics which makes very aggressive use of templates) for
testing the template features in gcc 3.0?

Thanks.
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

GCC 3.0 Status Report

[Mark Mitchell]

I was flaky with the weekly status report over the last couple of
weeks, but I'm trying to turn over a new leaf.

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

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

Overall
-------

  The Steering Committee has concluded that the release criteria
  are somewhat over-ambitious given the lack of resources available
  to complete some of the tasks.

  Therefore, the GCC 3.0 release will be largely a functionality
  release, featuring the rewritten x86 back-end, improved Java
  compiler, new C++ ABI, and new C++ standard library.  Stability
  will remain a focus, but quality of the generated code will
  become a secondary priority.  This withstanding, we believe that
  GCC 3.0 will generate better code than GCC 2.95.x in many 
  circumstances.

  In the short term, we will focus on compile-time performance, 
  especially in C++.  At that point, application testing will 
  become the major focus.  Performance of the generated code
  will be a greater focus of the 3.1 release.

Last Week
---------

  Analysis of open bugs is largely complete.  Many of the remainder
  are hard to analyze due to being target-specific in various ways.

  Richard Henderson provided a number of DWARF2 fixes and
  improvements.  Zack Weinberg checked in a number of cleanups
  to simply configuration.

  I began working on a variety of compile-time performance
  optimizations.  One of the lowest-hanging pieces of fruit appears
  to be lazy name-mangling in C++.  I've got that working and will
  check it in soon.  Preliminary work on this project broke the ARM
  bootstrap.  This turned out to be a generic optimization bug; it
  is now fixed.

  Numerous other bugs fixed.

Kudos
-----

  For his continuing work on the GCC 3.0 documentation and web-site, 
  the GCC 3.0 Volunteer of the Week is ...

    ... Gerald Pfeifer!

  Congratulations!

Next Week
---------

  Work on compile-time performance.

  Fix critical bugs.