You don't need more bad news, I'm sure, but ...

There's no reason to expect that code which doesn't compile will actually
work well once the compilation bugs are fixed, and I'm guessing that a
regime that couldn't keep the code at least building wasn't good about
enforcing testing procedures.  So if it were me, I'd estimate how long it
would take to code everything from scratch, and if feeling exceptionally
optimistic, cut that in half.

My organization is as metrics-hungry as any (I work for a certain large
North American aerospace company which does defense contracting), so I
can certainly appreciate the pressure one feels to produce such
numbers.  However, the nature of compilation errors is such that it
would be wholly inaccurate, and even unethical IMHO, to take the
current number of compilation errors and represent it as a metric of
how much work is left to be done.

I'm sure what I'm about to say is basically obvious to anyone who's
spent several hours burning down compilation errors, but I don't know
how else to put it.  When your compiler encounters a syntax error, it
may do one of several things:

 1. Isolate the error as a local problem and proceed to the next
section of code.
 2. Get horribly confused and give up, not even looking at the rest of
the code.
 3. Turn what a human would consider a "single error" into a godawful
long cascade of errors, which goes away as soon as you "kill the head
vampire."
 4. Seg fault (well, it happens...).

Since any of these may be the case for any given error, it's basically
absurd to take the error count at any given time and pretend it means
something.  It doesn't.  If you're not convinced, try (once you figure
out how to display all of them -- as someone else mentioned, Eclipse
handles this great) plotting a little histogram of errors over time.
If it doesn't fluctuate wildly... well, it will fluctuate wildly, so
I'll just optimize out what I was going to say (hooray for branch
prediction in everyday speech).

Warnings are another story.  They are generally independent, isolated,
deterministic, and easy for the compiler to recover from.  That said,
there is still something of a multiplicity problem.  For example, I
recently did some work converting a codebase from 1.4 to 1.5, which
mostly entailed getting rid of generics warnings.  The common case is
that you get a single container which should be generic, and generate a
warning everywhere it's used.  But you fix the definition of the
container (one line of code), and the whole mess goes away in one swell
foop.

So, a "total warnings" metric may be pretty fuzzy, and not a great
predictor of the actual amount of work required.  But it can at least
be counted upon to be more or less monotonically decreasing, which
ought to be enough to satisfy your bosses.

Of course, you could try explaining all this to them, but I imagine
they'll just tell you to go pound SLOC.

Luke