This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Java: Definite [Un]Assignment Issues


Per Bothner wrote:
> Ranjit Mathew wrote:
> 
> 
>>The first three - 16.2.{9,10,11}-definite-unassign-pass-3 - existed before
>>my patch and represent our decision to simplify the handling of loops w.r.t.
>>definite [un]assignment. See the comment for the "case LOOP_EXPR" in
>>check_init() in java/check-init.c for reference. Unless we want to change
>>that decision, I recommend that we simply mark these as expected "failures".
> 
> 
> I have no objection to "changing that decision", I just didn't think
> getting this working was a priority.  I obviously would prefer that
> we have it 100% correct.  I also prefer an implementation that is
> both reasonably fast and reasonably simple.

Yes, but that might have involved changes that would have
complicated this patch further. (Actually, the real reason
is that I personally agree with the comment in the code
referred to above - we do pretty well in keeping with the
spirit of the specification and it is not that important
to make every sadistic testcase work - hacker cycles are
better spent elsewhere.)



>>a. Surprisingly for me, we were not at all marking "blank final" local
>>   variables that represent the entities for which the whole "definite
>>   unassignment" brouhaha in JLS 2 Chapter 16 is about!
>>
>>   I define DECL_LOCAL_FINAL_IUD in java-tree.h that is similar to - in fact
>>   the same as - DECL_FIELD_FINAL_IUD, that I use to mark final
>>   local variables that are initialised in their declaration. This is
>>   being done in declare_local_variables() in parse.y in my patch.
> 
> 
> Why?  My quick and dirty tests seem to show that:
>    final int x = 10;
> and
>    final int x;
>    x = 10;
> are handled the same way and both give the errors I'd expect.
> 
> Which testcase is wrong before your patch and correct after?

Consider:

    final int i;
    i = 1;
    if (false)
      i = 2;

versus:

    final int i = 1;
    if (false)
      i = 2;

The former is not an error, but the latter is. Jikes and JDK 1.4
behave as expected, but GCJ does not. (Recall that after a boolean
constant expression with value false "when true", a variable is
*both* definitely assigned as well as definitely unassigned - a
blank final variable can only be assigned to when it is definitely
unassigned, while an initialised final variable cannot be assigned
to at all.)

It also helps in producing better diagnostics for errors (as Jikes
does, but not JDK 1.4), where you need to distinguish between a
blank final and an initialised upon declaration one. (Note that I
have not changed this part of GCJ in my patch, though it can easily
be done.)


> I'll get back to you on the check_bool_init patch.

Be sure to check out the latter part of JLS 2 16.1.7:

http://java.sun.com/docs/books/jls/second_edition/html/defAssign.doc.html#26150

(It seems that this was not present in JLS 1.)

Thanks for taking the time to look into my patch.

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT gmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]