lexer rewrite testing/timing help needed

[Per Bothner]

I converted the Java front-end to support --enable-mapped-location.
This means that it uses source_location cookies managed by
libcpp/line-map.c to represent file/line/column numbers, just
like the C and C++ front=ends do.  This potentially will allow
us to get rid of a lot of the EXPR_WITH_FILE_LOCATION nodes,
which are now redundant to the extent they're just used for
line/column information.  (Unfortunately, EXPR_WITH_FILE_LOCATION
are also used by the name lookup code, so removing them
completely is more work.)

The are two known non-critical pieces of functionality missing:
(1) The SourceFile attribute in a .class file isn't being handled.
This is probably not a major amount of work, but I need to
understand the interactions better.
(2) The old code kept track of the previous line and previous
location.  The former appears to have been intended for better
error messages when seeing blank lines, and the latter has
something to column numbers for array declarations.

While doing this so I ended up essentially rewriting the Java lexer.
I.e. I moved a lot of code around and simplified the code paths
and data structures.  Hopefully the result is faster, but I don't
know.  And I'm heading off for a week's vacation/travelling.
Though I'm expecting WiFi access, that won't be until Friday
afternoon at best, plus I don't access to very fast hardware.
So this is where I'm asking for help.

Could someone try this patch, and compare:
(a) mainline without the patch with --disable-checking;
(b) mainline with the patch and --disable-checking;
(c) mainline with the patch and --enable-mapped-location and
--disable-checking.
I'd like a summary of testsuite results:  The immediate goal is
no regressions (a)->(b) and as few as possible (a)->(c)).  I also
want to know how the new lexer effects compile time, so I'm asking
for some timing tests on a fixed codebase, perhaps rebuilding
libjava.

The patch presumes a fix to gcc/profile.c.  In my testing I used
this patch:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=7113&action=view
However, the following (which may be checked soon) is probably
better:
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01571.html

I would also be helpful if people could try out of there are
regressions in where the cursor ends up in error messages.
Specifically I'd like testcases to to help me implement (2) above,
if needed.  Possibly existing testcases will cover this.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: java-loc.patch
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040916/2867db81/attachment.ksh>