Re: PCH patch

Re: PCH patch

[B. Kosnik]

> The PCH branch has been open for testing for some time now, and I got
> positive status reports (or at least, they sounded positive) for
> x86-linux, ia64-linux, x86-mingw. I have also tested it myself on
> powerpc-darwin.

Really? I didn't see these. Perhaps you would be so kind as to point out
where current testresults are located?

Also, what's the status with these bits:
http://gcc.gnu.org/ml/gcc/2002-12/msg00710.html
http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg00096.html
http://gcc.gnu.org/ml/gcc/2002-12/msg00588.html

-benjamin

Re: PCH patch

[Geoffrey Keating]

On Sunday, December 15, 2002, at 05:49  PM, B. Kosnik wrote:

>
>
>> The PCH branch has been open for testing for some time now, and I got
>> positive status reports (or at least, they sounded positive) for
>> x86-linux, ia64-linux, x86-mingw. I have also tested it myself on
>> powerpc-darwin.
>
> Really? I didn't see these.

You wouldn't have, most of the reports were sent to me in private mail. 
  The second URL you listed seems to be a positive status report for 
ia64-linux.

>  Perhaps you would be so kind as to point out
> where current testresults are located?
>
I don't know of anywhere that testresults have been posted.  In fact, 
the second URL you posted is new to me.

> Also, what's the status with these bits:
> http://gcc.gnu.org/ml/gcc/2002-12/msg00710.html
> http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg00096.html
> http://gcc.gnu.org/ml/gcc/2002-12/msg00588.html
>
Not regressions.  It might be annoying that PCH doesn't work in every 
case on every platform, but it won't affect anyone's ability to develop 
or use GCC: they can simply not use PCH.

PCH patch

[Geoffrey Keating]

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

[Forgot to attach the actual patch!]

Shortly after Mark makes the branch, I'll merge the PCH branch to 
mainline with something like this patch.

The PCH branch has been open for testing for some time now, and I got 
positive status reports (or at least, they sounded positive) for 
x86-linux, ia64-linux, x86-mingw.  I have also tested it myself on 
powerpc-darwin.

This particular patch has been bootstrapped & tested on powerpc-darwin, 
and I'm running an additional check on powerpc-eabisim.

There are some known test failures with the new patch, but they aren't 
regressions (in fact, they only affect debugging information when a PCH 
is used).  I also have some reports that PCH doesn't fully work on all 
platforms, this is to be expected, hopefully when the patch is in the 
mainline those who work on these platforms will be able to improve the 
situation.

The patch is 400K, a little too big to send uncompressed, so here it is 
compressed.



[-- Attachment #2: pch-15.patch.gz --]
[-- Type: application/x-gzip, Size: 88401 bytes --]

Re: PCH patch

[Joseph S. Myers]

On Fri, 13 Dec 2002, Geoffrey Keating wrote:

> Shortly after Mark makes the branch, I'll merge the PCH branch to 
> mainline with something like this patch.

The new file c-pch.c is missing documentation in passes.texi.  I'm also
rather surprised that nothing about the PCH implementation merits
documentation in cppinternals.texi or elsewhere in the internals manuals.  
The new %V specs feature needs documenting in invoke.texi.  One ChangeLog
says "*** End of unmerged pch-branch ChangeLog ***" which appears wrong.  
The header for c-pch.c says "This file is part of GNU CC."; it should say
GCC.  (Patches to fix that issue for existing files have been submitted
but need a global write maintainer to review and apply them, starting with
<http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01716.html> then the
submitter may produce patches for the rest of the tree.)

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

Re: PCH patch

[Mark Mitchell]

--On Saturday, December 14, 2002 08:51:58 PM +0000 "Joseph S. Myers" 
<jsm28@cam.ac.uk> wrote:

> On Fri, 13 Dec 2002, Geoffrey Keating wrote:
>
>> Shortly after Mark makes the branch, I'll merge the PCH branch to
>> mainline with something like this patch.

Please do not do this until:

a) Zack has had a chance to finish merging BIB, and

b) I have had a chance to merge the new C++ parser.

It's important to get BIB in so that all those improvements are available
to mainline, and the new parser and PCH are both likely to create some
problems somewhere; best we only have one at once.

Thanks,

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

Re: PCH patch

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

> --On Saturday, December 14, 2002 08:51:58 PM +0000 "Joseph S. Myers"
> <jsm28@cam.ac.uk> wrote:
> 
> > On Fri, 13 Dec 2002, Geoffrey Keating wrote:
> >
> >> Shortly after Mark makes the branch, I'll merge the PCH branch to
> >> mainline with something like this patch.
> 
> Please do not do this until:
> 
> a) Zack has had a chance to finish merging BIB, and
> 
> b) I have had a chance to merge the new C++ parser.
> 
> It's important to get BIB in so that all those improvements are available
> to mainline, and the new parser and PCH are both likely to create some
> problems somewhere; best we only have one at once.

Can I ask you instead to not merge the new C++ parser until after the
PCH patch goes in?  The PCH work is much less likely to cause
regressions than the new parser, since the majority of the changes are
new code that's only run when a PCH is being created or used.  I'd
also like to have time to test the new parser against some of Apple's
source base, but don't have time to do that while testing the BIB
branch, working on integrating PCH, and reporting bugs against the 3.3
branch.

We should also have a plan in case the BIB takes a long time to become
of mergable quality.  Zack has fixed the easier bootstrap problems
with commendable speed, but there are some issues remaining that could
take a long time to solve.

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

Re: PCH patch

[Mark Mitchell]

> Can I ask you instead to not merge the new C++ parser until after the
> PCH patch goes in?

We both want to get their first and we can't both win.

There's no rational right choice; the PCH code will affect the parser
and vice versa.

Both will likely cause chaos for a while, despite the fact that we've
both tested heavily.

Your argument that the new parser is more likely to be problematic is
actually a good reason to get it in first; I'll need all the time I can
get to fix whatever does come up.

Clearly, I am a biased decision-maker.  If you're not willing to let me
go first, we'll need to take it to the SC, or agree to flip for it.

I would, however, be very appreciative if you would let me go first.

> We should also have a plan in case the BIB takes a long time to become
> of mergable quality.  Zack has fixed the easier bootstrap problems
> with commendable speed, but there are some issues remaining that could
> take a long time to solve.

Let's cross that bridge if we get there.

Note that most of these problems are not Zack's fault; they're the fault
of the people who caused the regressions.  Zack is being kind of enough
to spend his time solving the problems (which are, in a few cases, of his
own making.)

In short, I don't think it's unreasonable for this merge from BIB to
take a while.  The rest of us can be patient.  Leaning on Zack at this
point is a good way to make sure that nobody volunteers to operate a
similar branch in the future.

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

Re: PCH patch

[Geoff Keating]

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

> On Fri, 13 Dec 2002, Geoffrey Keating wrote:
> 
> > Shortly after Mark makes the branch, I'll merge the PCH branch to 
> > mainline with something like this patch.
> 
> The new file c-pch.c is missing documentation in passes.texi.

I looked at that part of passes.texi, and decided that since it was
(a) out-of-date and (b) useless, to rewrite it.  It now reads:

The source files to parse C are found in the toplevel directory, and
by convention are named @file{c-*}.  Some of these are also used by
the other C-like languages: @file{c-common.c},
@file{c-common.def},
@file{c-format.c},
@file{c-opts.c},
@file{c-pragma.c},
@file{c-semantics.c},
@file{c-lex.c},
@file{c-common.h},
@file{c-dump.h},
and
@file{c-pragma.h},

Files specific to each language are in subdirectories named after the
language in question, like @file{ada}, @file{objc}, @file{cp} (for C++).

which is still slightly incorrect but at least is now more compact.

>  I'm also
> rather surprised that nothing about the PCH implementation merits
> documentation in cppinternals.texi or elsewhere in the internals manuals.  

There is gty.texi, several hundred lines of documentation about the
interface to the implementation.  It does need a little updating,
though; I'll make a revised patch.

> The new %V specs feature needs documenting in invoke.texi.

It's not user-visible.  It is documented in gcc.c.

I'm somewhat concerned that we're documenting specs even to the
current level of detail (and I notice that some of that documentation
is wrong).

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

Re: PCH patch

[Joseph S. Myers]

On 15 Dec 2002, Geoff Keating wrote:

> I looked at that part of passes.texi, and decided that since it was
> (a) out-of-date and (b) useless, to rewrite it.  It now reads:

Properly, the individual source files should be explained, but their
functions at present aren't particularly well-defined (and some are large
and could do with being split up).

> It's not user-visible.  It is documented in gcc.c.
> 
> I'm somewhat concerned that we're documenting specs even to the
> current level of detail (and I notice that some of that documentation
> is wrong).

The specs documentation should be in exactly one place - that is, in the
internals manual (not invoke.texi which is where it was added when specs
were documented in the manual at all; the ability to parse specs from a
file should only really be there for the use of libgcj) (and not a long
comment in gcc.c either).

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

PCH patch

[Geoffrey Keating]

Shortly after Mark makes the branch, I'll merge the PCH branch to 
mainline with something like this patch.

The PCH branch has been open for testing for some time now, and I got 
positive status reports (or at least, they sounded positive) for 
x86-linux, ia64-linux, x86-mingw.  I have also tested it myself on 
powerpc-darwin.

This particular patch has been bootstrapped & tested on powerpc-darwin, 
and I'm running an additional check on powerpc-eabisim.

There are some known test failures with the new patch, but they aren't 
regressions (in fact, they only affect debugging information when a PCH 
is used).  I also have some reports that PCH doesn't fully work on all 
platforms, this is to be expected, hopefully when the patch is in the 
mainline those who work on these platforms will be able to improve the 
situation.