Re: Has anyone seen this build error before?

[Mo DeJong <mdejong at cygnus dot com>]

On 20 Nov 2000, Tom Tromey wrote:

> Mo> Humm, how many are there? If it is just one or two, could you post
> Mo> them to the list or post a pointer to where I could find them?
> 
> Alex posted these:
> 
> Alex> I think Tom is talking about patches to gcj/297 and gcj/283
> Alex> (Tom, please tell me if I'm wrong.) But I don't think it's going
> Alex> to help with your case. Egcs isn't in a very good state today. I
> Alex> can't even build it past libiberty/cplus-dem.c (I hit this when
> Alex> I tried to reproduce your problem yesterday night.)
> 
> I think those are the ones.  I'm not positive -- it was some patches
> you emailed me last week in response to the java.util.Collections
> problem.

I added the patch from anthony and the one for 297. The one for
283 seems to already have been applied or else some other patch
was applied in its place. To make a long story short, I still
get the compile error while building libgcj. I guess I will
have to just give up on this for a bit until it works again.

> The biggest problem for us is that the constant expression code in gcj
> is very underpowered.  There are a lot of cases it doesn't handle, and
> it is only used for declarations (and not, as far as I could tell,
> case labels).

Boy, that is going to be a problem. Using the constant expression
feature of a switch statement seems to be the best way to test
compile time constants. It is used all over the place in Jacks.

> We also fail all of the "@" tests since I haven't had time to change
> the test suite to add a constraint covering that case.  There are
> around 10 of these.

That one will be easy to fix.

Mo DeJong
Red Hat Inc