Alpha (Re: [kaffe] Testing for 1.1.0 release)

[Dalibor Topic]

Hi Dan,

--- mcmahill at mtl.mit.edu wrote:
>
> > > test/regression/InetSocketAddressTest.fail
> > 
> > how does this one fail, i.e. could you take a look at
> InetSocketAddressTest.out
> > 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
involved.

> > 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 ;)

cheers,
dalibor topic

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com