This is the mail archive of the gcc@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: GCC 3.1 Prerelease


>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Per> I just created pr java/6425.  I'm biased, but I think this needs
Per> to be fixed before the release.

I looked at this.

First, the problem occurs on this line:

    sbuf.append(RealNum.toScaledInt(number, 10).toString());

Breaking this into two lines, like so, makes the code compile:

    IntNum x = RealNum.toScaledInt(number, 10);
    sbuf.append(x.toString());

That's interesting information.  It helped me track down the
difference between what happens when things go ok and when they don't.
However I don't fully understand what it means.


The class-loading code seems pretty fragile.  If it is going to
compare file names it seems like it ought to compare the results of
realpath().  Otherwise there might be ways to fool it.  However, while
this code isn't ideal (as far as I can see anyway), I think the
problem lies elsewhere.


The appended patch fixes the problem for me.  What happened was we got
to this code with an EXPR_WITH_FILE_LOCATION like this:

            arg 0 <expr_with_file_location 0x4012a420
                arg 0 <identifier_node 0x4012a480 RealNum.toScaledInt tree_2> arg 1 <identifier_node 0x40126340 FixedRealFormat.java>
                arg 2 <tree_list 0x4012917c
                    purpose <expr_with_file_location 0x4012a4a0
                        arg 0 <identifier_node 0x4012a400 RealNum> arg 1 <identifier_node 0x40126340 FixedRealFormat.java>
                        FixedRealFormat.java:9:16>
                    chain <tree_list 0x40129190
                        purpose <expr_with_file_location 0x4012a4c0 arg 0 <identifier_node 0x4012a440 toScaledInt> arg 1 <identifier_node 0x40126340 FixedRealFormat.java>
                            FixedRealFormat.java:9:23>>>
                FixedRealFormat.java:9:16>

If we strip the outer EXPR_WITH_FILE_LOCATION, as the patch does, we
end up with qual_wfl as:

    <identifier_node 0x4012a400 RealNum>


Anyway, I don't really understand what is going on here.  I assume
there is some reason for the existing `if', but I don't know what it
is.  I'm going to try rebuilding libgcj with this patch and see how
that goes.

Alex, can you look at this quickly?  As far as I know you're the only
one who really understands this code.

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* parse.y (qualify_ambiguous_name) [case CALL_EXPR]: Always choose
	EXPR_WFL_QUALIFICATION of qual_wfl.

Index: parse.y
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v
retrieving revision 1.353.2.17
diff -u -r1.353.2.17 parse.y
--- parse.y 15 Apr 2002 09:28:53 -0000 1.353.2.17
+++ parse.y 23 Apr 2002 21:01:01 -0000
@@ -11219,11 +11219,8 @@
       {
       case CALL_EXPR:
 	qual_wfl = TREE_OPERAND (qual_wfl, 0);
-	if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION)
-	  {
-	    qual = EXPR_WFL_QUALIFICATION (qual_wfl);
-	    qual_wfl = QUAL_WFL (qual);
-	  }
+	qual = EXPR_WFL_QUALIFICATION (qual_wfl);
+	qual_wfl = QUAL_WFL (qual);
 	break;
       case NEW_ARRAY_EXPR:
       case NEW_ANONYMOUS_ARRAY_EXPR:


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