Some notes on our status

Some notes on our status

[Tom Tromey]

I think our 3.1 status is improving.  If there are still critical
pending bugs which aren't in Gnats, please tell me (or better yet
submit it).  Or if such a bug exists in Gnats but is not marked
`high', send me the PR number.

Mark has done a lot of work on the Mauve regressions.  Things are
looking good there.

I think PR 6092 (GC failure with Sparc Solaris -m64) may simply be
punted for this release.  I'll spend a bit more time playing with it,
but if nothing jumps out I'll drop it.

PR 6066 (can't rebuild Classpath) is growing and not shrinking :-(.
The current Classpath triggers a known problem in gcj (re-reported as
PR 6336, but also known as PR 1343).  I have a partial patch for this,
which I wrote in December, but it is unfinished.  In any case this
increasingly looks like something we'll unfortunately have to drop for
3.1.  Any comments on that?

PR 6314 is almost done.  I'm testing a patch now.  I chose the name
`-P' for the option because:

* -P is only used by cpp, and we already use -C in a way that
  conflicts with cpp
* "P" for "properties".  Which isn't exactly true but at least it is
  mildly mnemonic

Tom

Re: Some notes on our status

[Per Bothner]

Tom Tromey wrote:
> PR 6314 is almost done.  I'm testing a patch now.  I chose the name
> `-P' for the option because:
> 
> * -P is only used by cpp, and we already use -C in a way that
>   conflicts with cpp
> * "P" for "properties".  Which isn't exactly true but at least it is
>   mildly mnemonic

I would prefer just a long name, like --resources.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Some notes on our status

[Bryce McKinlay]

Per Bothner wrote:

> Tom Tromey wrote:
>
>> PR 6314 is almost done.  I'm testing a patch now.  I chose the name
>> `-P' for the option because:
>>
>> * -P is only used by cpp, and we already use -C in a way that
>>   conflicts with cpp
>> * "P" for "properties".  Which isn't exactly true but at least it is
>>   mildly mnemonic
>
>
> I would prefer just a long name, like --resources.


Yes, I agree.

Bryce.

Re: Some notes on our status

[Jeff Sturm]

On 19 Apr 2002, Tom Tromey wrote:
> I think PR 6092 (GC failure with Sparc Solaris -m64) may simply be
> punted for this release.  I'll spend a bit more time playing with it,
> but if nothing jumps out I'll drop it.

It's not a regression.  I'd vote to drop it.

However I had -m64 builds working around December or so.  In a couple
weeks I'll have time to look at it.  It should be fixable for 3.1.1.

Jeff

Re: Some notes on our status

[Mark Wielaard]

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

Hi,

On Sat, 2002-04-20 at 05:04, Tom Tromey wrote:
> PR 6066 (can't rebuild Classpath) is growing and not shrinking :-(.
> The current Classpath triggers a known problem in gcj (re-reported as
> PR 6336, but also known as PR 1343).  I have a partial patch for this,
> which I wrote in December, but it is unfinished.  In any case this
> increasingly looks like something we'll unfortunately have to drop for
> 3.1.  Any comments on that?

The current gcj can build the latest released version (0.03) of GNU
Classpath which is good. If we can find workarounds for the current
problems in Classpath CVS then we can make sure that a next version of
Classpath will work with gcj 3.1. Obviously as a Classpath hacker I
think it is very important to fix this issue since officially Classpath
is the upstream provider for a lot of the standard classes in libgcj.

PR6336/1343 isn't a real problem since it has a known workaround (rename
one of the inner classes) which I have already applied to my local
Classpath tree.

The problem(s) that I am seeing look like PR java/2791, which you will
get for java.io.FileChannel and java.util.Map. Luckily the patch given
in that PR does fix that problem (Back in August I reported that it
didn't solve the issue I had back then in Classpath, but the bug report
wasn't actually about compiling Classpath. Sorry, if my report made the
patch not go in.)

Applying that patch will show three more problems which you already
reported in the original PR java/6066 for java.util.AbstractMap (the
same happens for java.awt.AWTKeyStroke, java.awt.im.InputSubset). But a
workaround is to fully qualify the inner classes used. Which I have done
for my local Classpath tree.

With these changes I am able to compile Classpath CVS with gcj 3.1 CVS.

I have attached an updated version of the patch given in PR java/2791:

2001-08-17  Alexandre Petit-Bianco  <apbianco@redhat.com>

	* jcf-parse.c: (yyparse): Don't prepend "./" to relative
	paths. Fixes PR java/2791.

This does not introduce any new regressions in libgcj or mauve, so if
Alexandre still believes this patch is right it would be very nice to
get this in 3.1.

I will post my patches for the Classpath source to the Classpath
mailinglist so you can check that they solve the remaining issues.

Cheers,

Mark

[-- Attachment #2: jcf-parse.diff --]
[-- Type: text/x-patch, Size: 578 bytes --]

Index: jcf-parse.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/jcf-parse.c,v
retrieving revision 1.104.2.5
diff -u -r1.104.2.5 jcf-parse.c
--- jcf-parse.c	29 Mar 2002 00:14:00 -0000	1.104.2.5
+++ jcf-parse.c	21 Apr 2002 15:49:37 -0000
@@ -1014,9 +1014,6 @@
 	  int twice = 0;
 
 	  int len = strlen (list);
-
-	  if (*list != '/' && filename_count > 0)
-	    obstack_grow (&temporary_obstack, "./", 2);
 
 	  obstack_grow0 (&temporary_obstack, list, len);
 	  value = obstack_finish (&temporary_obstack);

Re: Some notes on our status

[Anthony Green]

On Sat, 2002-04-20 at 00:52, Per Bothner wrote:
> I would prefer just a long name, like --resources.

I prefer the even longer --core-resource, or shorter --resource.

In any case, thanks for addressing this Tom (although I'm bummed that we
can't just continue using -R).

AG

Re: Some notes on our status

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> With these changes I am able to compile Classpath CVS with gcj
Mark> 3.1 CVS.

Thanks for all your work on this.
I'm going to reduce 6066 to medium priority.

Tom

Re: Some notes on our status

[Alexandre Petit-Bianco]

> This does not introduce any new regressions in libgcj or mauve, so
> if Alexandre still believes this patch is right it would be very
> nice to get this in 3.1.

I thing it is still right, please go ahead.

Thanks,

./A