This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: gcj patch ping
- From: Tom Tromey <tromey at redhat dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Java Patch List <java-patches at gcc dot gnu dot org>
- Date: 04 Jun 2002 16:17:26 -0600
- Subject: Re: gcj patch ping
- References: <877klhckry.fsf@creche.redhat.com> <3CFBA253.1040503@bothner.com>
- Reply-to: tromey at redhat dot com
>>>>> "Per" == Per Bothner <per@bothner.com> writes:
>> http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00983.html
>> Somewhat hacky fix for PR 6520
Per> This doesn't seem right, not without knowing what are
Per> the actual semantics for what fold is *supposed* to do for
Per> constants. It seems to me wrong for fold to be modifying
Per> existing nodes.
That makes sense. I'll investigate further.
>> http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00393.html
>> Assertion facility
Per> I'm not familiar with the assert facility, but I trust
Per> your judgement.
Ok. Basically this is a straightforward implementation of the new
feature. I'll check it in.
>> http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02182.html
>> Minor optimization in bytecode generation
Per> It seems ok. But I wonder why you need to test:
Per> && reloc->label != block
I believe I added that to prevent an infinite loop if the `goto's
themselves form one.
Per> Also perhaps add to the comment at the top of the loop
Per> your rationale - i.e. "this can happen when generating
Per> a 'finally' clause".
Ok.
Tom