Alpha (Re: [kaffe] Testing for 1.1.0 release)
robilad at yahoo.com
Thu May 22 06:05:01 PDT 2003
--- mcmahill at mtl.mit.edu wrote:
> > > test/regression/InetSocketAddressTest.fail
> > how does this one fail, i.e. could you take a look at
> > and InetSocketAddressTest.fail, and check what's the problem?
> % cat test/regression/InetSocketAddressTest.out
> java.lang.IllegalArgumentException: Null host name value
> java.lang.IllegalArgumentException: Bad port number: 100000
> java.lang.IllegalArgumentException: Bad port number: 65536
> java.lang.IllegalArgumentException: Bad port number: -1
> java.lang.IllegalArgumentException: Bad port number: -128
> Unresolved bad.bad.bad: true
> Unresolved toString(): bad.bad.bad:0
> Unresolved localhost: false
> Resolved toString(): localhost/127.0.0.1:0
> Wildcard address: true
> Port: 128
> Null address is wildcard: true
That's the expected output. The interesting part is in the *.fail files ;)
Could you diff -u the .out file versus the .fail file?
> this could easily be a machine independent buglet which only happens to
> show up on alpha with a SIGFPE but could show up in subtle ways or not at
> all on other systems (including alpha with -mieee). I looked a little,
> but didn't see anything.
I've seen some subtle floating point failures not unlike the ones on alpha on
mips-irix (where class library compilation fails with the same message
regarding MIN_VALUE of Float like it used to on alphas before -mieee) and maybe
on arm-linux as well. I've though I could blame it on the strtod
implementations, but alpha seems to show that there might be something else
> > kaffe generates on alpha-netbsd and see what gcc is complaining about.
> I've fixed most of them. The huge number generated by kaffe.def is
cool, I'm looking forward to the patch.
> By changing to %ld, my warnings went away. You may want to also cast to a
> long too. Ie, dprintf("pc=%ld", (long) pc).
> in kaffe/kaffeh/support.c, these warnings may be a bit worse:
> support.c:422: warning: cast to pointer from integer of different size
> support.c:423: warning: cast to pointer from integer of different size
> f->name = (void*)((u4)name_index);
> u4 is a uint32 (32 bit integer). Then you're casting to a pointer which
> is 64 bits. But then again name_index starts out as a u2 (16 bit
> number?) so maybe you don't care about the top 48 bits...
> support.c:504: warning: cast from pointer to integer of different size
> support.c:505: warning: cast from pointer to integer of different size
> name_index = (u2)(u4)(f->name);
> same thing in reverse.
I'm sort of puzzled about these. Especially since name and type are pointers to
Utf8constants and Classes. Maybe the code just needs a clean up ;)
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
More information about the kaffe