Re: Stable release?

Re: Stable release?

[Andrew Haley]

> From: Matt Welsh <mdw@cs.berkeley.edu>
> Date: Wed, 16 Feb 2000 10:22:04 -0800
> 
> 
> I guess I don't understand the problem here. Isn't the Java-specific
> portion of EGCS maintained by people *on this list*? What, then, is
> the problem with making branded versions of EGCS/LIBGCJ available to
> people on the GCJ website?

If it were just the Java specific parts, there wouldn't be any
problem.  However, gcc is not just a Java compiler, so any blessed
compiler would need to be fully functional for all its front ends to
be useful.

> Also keep in mind that almost all of the bugs we're likely to run
> into are in libgcj, NOT EGCS!

That is not my experience.

Andrew.

Re: Stable release?

[Matt Welsh]

Andrew Haley <aph@pasanda.cygnus.co.uk> writes:
> I think you're looking at this way too optimistically!
> 
> We would inevitably start having to collect patches to any "blessed"
> version of gcc, 

No you don't! Only accept patches against the latest CVS tree. The
point of having a "blessed" gcc is so that people can start using the
latest libgcj, which is where the action is anyway.

Re: Stable release?

[Anthony Green]

Andrew wrote:
> Yes, but then we'd have to tag the egcs source tree and support that
> version with continuing bug fixes.  Do we really want to do that?

Maybe not.  If the next snapshot appears reasonable, maybe we can just
save it away on our web site.  We don't have to make any claims beyond
the normal snapshot ones, but people can provide "it works for me"
type anecdotal evidence.

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

Re: Stable release?

[Matt Welsh]

Would it be possible for us (the GCJ team) to "brand" a snapshot of
EGCS which we believe is stable for the purposes of using GCJ? There's
no reason we need to be gated on the EGCS team; we simply take a known-good
snapshot of EGCS and make that available on the website.

Bryce McKinlay <bryce@albatross.co.nz> writes:
> Fredrik Warg wrote:
> 
> > Does anyone know if there will be a new stable release soon
> > (one that will also build against a stable gcc).
> 
> The magic 8-ball says "Outlook not so good". libgcj has a lot of new
> features that depend on fixes and new features in the compiler. We
> really  have to wait for the next (major) release of gcc before making a
> new release of the library. AFAIK, there has been no word on when that
> might happen.
> 
> regards
> 
>   [ bryce ]
> 
> 

Re: Stable release?

[Anthony Green]

Andrew wrote:
> I think you're looking at this way too optimistically!

Yes, I do tend to do that. 

> We would inevitably start having to collect patches to any "blessed"
> version of gcc, 

I'm not suggesting we bless anything.  If a snapshot happens to "work
for me", someone can just save it aside (normally they aren't very
long lived).

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

Re: jboolean / _Jv_InstanceOf / .class compiler problem

[Alexandre Petit-Bianco]

Bryce McKinlay writes:

> I don't have a test case outside the context of the _Jv_IsInstanceOf
> call. With my new implementation of this method (in the constant
> time patch), its result value never gets set properly (debugger
> shows random garbage values), and so "instanceof" always returns
> true. But this only occurs when dealing with code compiled from
> .class files. The source compiler and interpreter are unaffected.

I definitely should look into that. I need the full patch. A test case
would be nice too.

./A

Re: Stable release?

[Bryce McKinlay]

Matt Welsh wrote:

> This situation is certainly hurting the GCJ project. GCJ is really getting
> to the point where it's a powerful and robust Java compiler, but unfortunately
> not many people know about it or use it -- perhaps because there's a lot
> missing from the old version posted on the website.

gcj has come a long way, but I'm not sure if its really ready for a stable
release yet. Inner class support in particular is really something that is
turning people away and should be in the next release, and there are quite a few
bugs in gnats that need to get fixed.

> Also, the startup cost to start working with GCJ is too high. Making a
> clearly labelled "stable" GCJ version, all packaged up and ready to use,
> would go a long way towards solving this problem. Right now in order to use
> GCJ you either get to (a) grab the old 2.95.1 release, (b) get 2.95.2 and
> find some patches on a mysterious website referred to in one of Bryce's
> postings to the mailing list months ago; or (c) sweat through grabbing the
> latest CVS tree, which nobody knows whether it's broken or not.

Perhaps the best solution would be to make a "semi-official" patch against 2.95.2
and post it on the gcj website. I've already done most of the work for that, and
its not really much work to drop in a few extra patches every month or two to
keep it in sync with libgcj. We won't be changing anything outside of the Java
front end, so it would be a better base to work with for people who are concerned
about bugs in other parts of the compiler, and because it works on more
platforms.

The jboolean bug I alluded to in 2.95.2 earlier actually does show up in the cvs
version as well, so when it gets fixed there we can likely fix it in the 2.95.2
patch as well. (the bug only appears when you compile from .class files, .java
compilation and the interpreter are unaffected).

  [ bryce ]

Stable release?

[Fredrik Warg]

Hi all,

Does anyone know if there will be a new stable release soon
(one that will also build against a stable gcc). There must
be a whole bunch of changes since 2.95.1 ?


/Fredrik

Re: Stable release?

[Bryce McKinlay]

Fredrik Warg wrote:

> Does anyone know if there will be a new stable release soon
> (one that will also build against a stable gcc).

The magic 8-ball says "Outlook not so good". libgcj has a lot of new
features that depend on fixes and new features in the compiler. We
really  have to wait for the next (major) release of gcc before making a
new release of the library. AFAIK, there has been no word on when that
might happen.

regards

  [ bryce ]

Re: Stable release?

[Tom Tromey]

>> Would it be possible for us (the GCJ team) to "brand" a snapshot of
>> EGCS which we believe is stable for the purposes of using GCJ?
>> There's no reason we need to be gated on the EGCS team; we simply
>> take a known-good snapshot of EGCS and make that available on the
>> website.

Andrew> Yes, but then we'd have to tag the egcs source tree and
Andrew> support that version with continuing bug fixes.  Do we really
Andrew> want to do that?

Not to mention testing, and potential ill-will from the gcc team.
Doing any sort of release is a big deal.

I think for now we're just stuck with the situation, lousy as it is.

However, I also think that now is the time to come up with a plan to
ensure that we aren't in this same position in the future.

It's possible there's nothing we can do.  The runtime is tightly
coupled to the compiler, and compiler work continues.  If the gcc team
decides to not do minor releases while waiting (interminably :-) for a
major release, we're screwed.  So maybe the right approach is to bring
this concern up with the gcc maintainers.

Tom

Re: Stable release?

[Tom Tromey]

Matt> I guess I don't understand the problem here. Isn't the
Matt> Java-specific portion of EGCS maintained by people *on this
Matt> list*? What, then, is the problem with making branded versions
Matt> of EGCS/LIBGCJ available to people on the GCJ website?

As Andrew says, the problem is one of testing.  We need at least the
C, C++, and Java front ends to all work with the back end.  Since bugs
randomly crop up, especially with the rate of change on gcc, this is
hard to do.  Eg, look at the -fno-builtin thing with the current
compiler.

Matt> This situation is certainly hurting the GCJ project.

FWIW, I agree with you.  I would like to do more releases than we've
done.  I'd like to see what comes out of Per's talk with the gcc
maintainers.  Maybe we could get them to do a 2.95.3, and put a new
gcj in it.  I don't know.

Matt> The Java support in the compiler itself isn't changing that much
Matt> ... is it?

It is changing more than you think.  More to come.

Tom

Re: Stable release?

[Tom Tromey]

>>>>> "Fredrik" == Fredrik Warg <warg@ce.chalmers.se> writes:

Fredrik> Does anyone know if there will be a new stable release soon
Fredrik> (one that will also build against a stable gcc). There must
Fredrik> be a whole bunch of changes since 2.95.1 ?

No one knows.  We do have a huge number of changes, but they rely on a
newer compiler.  That means we're pretty much tied to the gcc release
schedule, which is unknw on.

Tom

Re: Stable release?

[Bryce McKinlay]

Tom Tromey wrote:

> If we do this, we'd want to make sure that the libgcj configure script
> can detect when the gcj front end is the wrong version.  Then we could
> have it spit out a URL where people can read about what to do.

That would be a great feature either way. It would cut down on PRs to this list
dramatically ;-)

regards

  [ bryce ]

jboolean / _Jv_InstanceOf / .class compiler problem

[Bryce McKinlay]

Tom Tromey wrote:

> I've seen some jboolean bugs in the past, but I could never reduce
> them to a simple test.  Do you have a test?  Is there a PR?

I don't have a test case outside the context of the _Jv_IsInstanceOf call. With
my new implementation of this method (in the constant time patch), its result
value never gets set properly (debugger shows random garbage values), and so
"instanceof" always returns true. But this only occurs when dealing with code
compiled from .class files. The source compiler and interpreter are unaffected.
I also managed to work around it by changing the return value of the call to
"int", but thats too ugly.

  [ bryce ]

Re: Stable release?

[Tom Tromey]

>>>>> "Godmar" == Godmar Back <gback@cs.utah.edu> writes:

Godmar> I'd like that.  Ideally, fix the problems on RH 5.2 in tree.c
Godmar> before you do that and/or the problem with -fno-builtin.  (Or
Godmar> whatever else problem I'll encounter in the future...)

Yeah, this is exactly the problem with us blessing any snapshot...

That said, we don't have to officially bless anything.  If somebody
out there (Matt for instance :-) has found a certain snapshot to work,
they're free to publicize it here.  I'd even point people at such a
thing, in response to bug report, probably.

Godmar> Maybe it would be good to install a bonsai/tinderbox like
Godmar> scheme that continuously recompiles and tests on various
Godmar> platforms and flags bad checkins?  In particular, I'm
Godmar> concerned about checkins from the non-gcj part of egcs that
Godmar> inadvertently affect the gcj front-end.

Yes, us too -- especially now that the C++ compiler is getting a
facelift.

I would like to see an automatic test system set up.  gcc already has
something along these lines, but it doesn't test libgcj.  (Hopefully
it will once libgcj is put into the gcc cvs tree -- one of the goals
of the classpath merge and relicensing.)

We actually have what I think is a good plan for doing this sort of
testing, in a mostly automatic, distributed way.  The big problem is
finding time to implement it.  Anybody interested in implementing this
sort of thing is welcome to step forward...

Tom

Re: Stable release?

[Matt Welsh]

I guess I don't understand the problem here. Isn't the Java-specific
portion of EGCS maintained by people *on this list*? What, then, is the
problem with making branded versions of EGCS/LIBGCJ available to people
on the GCJ website?

This situation is certainly hurting the GCJ project. GCJ is really getting
to the point where it's a powerful and robust Java compiler, but unfortunately
not many people know about it or use it -- perhaps because there's a lot
missing from the old version posted on the website. 

Also, the startup cost to start working with GCJ is too high. Making a 
clearly labelled "stable" GCJ version, all packaged up and ready to use, 
would go a long way towards solving this problem. Right now in order to use
GCJ you either get to (a) grab the old 2.95.1 release, (b) get 2.95.2 and
find some patches on a mysterious website referred to in one of Bryce's
postings to the mailing list months ago; or (c) sweat through grabbing the
latest CVS tree, which nobody knows whether it's broken or not.

I think we should do something about this situation *now*, rather than 
just "living with it" indefinitely. My suggestion is simply to provide 
a known-working snapshot of EGCS on the website. (Call it an "informal
snapshot", "beta release", or whatever ... the point is that we can't wait
for the EGCS team to decide that the whole damn compiler is ready for a 
release.) If people find bugs then they should first try the latest CVS 
version, with the understanding that the team will only accept patches 
against the latest version of the tree. LIBGCJ can be released on any cycle 
that we choose.

Also keep in mind that almost all of the bugs we're likely to run into are
in libgcj, NOT EGCS! The point of having a "branded" snapshot of EGCS that
we suggest that people use is just so they have the right compiler to support
later versions of libgcj. The Java support in the compiler itself isn't 
changing that much ... is it?

Matt

Re: Stable release?

[Godmar Back]

> 
> 
> Andrew wrote:
> > Yes, but then we'd have to tag the egcs source tree and support that
> > version with continuing bug fixes.  Do we really want to do that?
> 
> Maybe not.  If the next snapshot appears reasonable, maybe we can just
> save it away on our web site.  We don't have to make any claims beyond
> the normal snapshot ones, but people can provide "it works for me"
> type anecdotal evidence.
> 

I'd like that.  Ideally, fix the problems on RH 5.2 in tree.c before you do
that and/or the problem with -fno-builtin.  (Or whatever else problem
I'll encounter in the future...)
(I think I'll also try Glenn's suggestion to build only tree.o with 
-fno-builtin.  Thanks for that, btw!)

The main problem for me is that I don't work on gcj-related things
continuously like others do.  Whenever I have some time to get back to 
it, I update the compiler and the libgcj tree and more often than not, one
or both don't work.

Maybe it would be good to install a bonsai/tinderbox like scheme that
continuously recompiles and tests on various platforms and flags
bad checkins?  In particular, I'm concerned about checkins from
the non-gcj part of egcs that inadvertently affect the gcj front-end.  
I'm sure a multi-billion-dollar company like Redhat would have the 
resources to implement something like that.

	- Godmar

Re: Stable release?

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@albatross.co.nz> writes:

Bryce> gcj has come a long way, but I'm not sure if its really ready
Bryce> for a stable release yet. Inner class support in particular is
Bryce> really something that is turning people away and should be in
Bryce> the next release, and there are quite a few bugs in gnats that
Bryce> need to get fixed.

FWIW, while I agree that inner classes are very important, I also
think we have enough new stuff to do a release whether or not they are
ready.  I'd really like to be able to do libgcj releases as frequently
as we think they are necessary -- eg, whenever a major new feature is
added.

Bryce> Perhaps the best solution would be to make a "semi-official"
Bryce> patch against 2.95.2 and post it on the gcj website.

I think this is a plausible approach.  This would lessen our testing
problem, because we'd be working with a known gcc.  I'm inclined to
see what the gcc maintainers think before taking real action though.

If we do this, we'd want to make sure that the libgcj configure script
can detect when the gcj front end is the wrong version.  Then we could
have it spit out a URL where people can read about what to do.

Bryce> The jboolean bug I alluded to in 2.95.2 earlier actually does
Bryce> show up in the cvs version as well, so when it gets fixed there
Bryce> we can likely fix it in the 2.95.2 patch as well. (the bug only
Bryce> appears when you compile from .class files, .java compilation
Bryce> and the interpreter are unaffected).

I've seen some jboolean bugs in the past, but I could never reduce
them to a simple test.  Do you have a test?  Is there a PR?

Tom

Re: Stable release?

[Per Bothner]

I guess it is my job to bring this concern to Gcc steering committee ...
I will do so.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: jboolean / _Jv_InstanceOf / .class compiler problem

[Bryce McKinlay]

Alexandre Petit-Bianco wrote:

> Bryce McKinlay writes:
>
> > I don't have a test case outside the context of the _Jv_IsInstanceOf
> > call. With my new implementation of this method (in the constant
> > time patch), its result value never gets set properly (debugger
> > shows random garbage values), and so "instanceof" always returns
> > true. But this only occurs when dealing with code compiled from
> > .class files. The source compiler and interpreter are unaffected.
>
> I definitely should look into that. I need the full patch. A test case
> would be nice too.

Here is the gcj patch. The runtime patch is here:
http://sourceware.cygnus.com/ml/java-patches/2000-q1/msg00138.html

There's a test case in cvs at
libgcj/libjava/testsuite/libjava.lang/InterfaceDispatch.java

The method that exhibits the problem is _Jv_IsAssignableFrom() in
natClass.cc. You might want to make it non-inline for debugging.

regards

  [ bryce ]

Re: Stable release?

[Andrew Haley]

> Date: Wed, 16 Feb 2000 09:59:29 -0800
> From: Anthony Green <green@cygnus.com>
> 
> Andrew wrote:
> > Yes, but then we'd have to tag the egcs source tree and support that
> > version with continuing bug fixes.  Do we really want to do that?
> 
> Maybe not.  If the next snapshot appears reasonable, maybe we can just
> save it away on our web site.  We don't have to make any claims beyond
> the normal snapshot ones, but people can provide "it works for me"
> type anecdotal evidence.

I think you're looking at this way too optimistically!

We would inevitably start having to collect patches to any "blessed"
version of gcc, *and* we'd have to test against it when updating
libgcj.  And, as Tom pointed out, the gcc team (which from time to
time includes me) wouldn't like to have an another alternative
distribution channel of gcc "versions".

Andrew,

Re: Stable release?

[Per Bothner]

Matt Welsh <mdw@cs.berkeley.edu> writes:

> the point is that we can't wait for the EGCS team to decide that the
> whole damn compiler is ready for a release.)  ...  Also keep in mind
> that almost all of the bugs we're likely to run into are in libgcj,
> NOT EGCS! The point of having a "branded" snapshot of EGCS ...

There is no "egcs team" - it's the "gcc team".  There will never be
another egcs release, only gcc releases.  The cvs tree is rooted at
"egcs" only because fixing it would mean everybody's checked-out
cvs tree would break.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Stable release?

[Andrew Haley]

> From: Matt Welsh <mdw@cs.berkeley.edu>
> Date: Wed, 16 Feb 2000 09:43:31 -0800
> 
> Would it be possible for us (the GCJ team) to "brand" a snapshot of
> EGCS which we believe is stable for the purposes of using GCJ?
> There's no reason we need to be gated on the EGCS team; we simply
> take a known-good snapshot of EGCS and make that available on the
> website.

Yes, but then we'd have to tag the egcs source tree and support that
version with continuing bug fixes.  Do we really want to do that?

Andrew.