Bug on Solaris

Tue Jan 8 23:16:00 GMT 2002

Hi Jeff,
On Tue, Jan 08, 2002 at 04:42:59PM -0500, Jeff Sturm wrote:
> On Tue, 8 Jan 2002, Andrew Haley wrote:
> > It is, however, a front end bug that manifests itself only when
> > running on SPARC. Endian, perhaps?
>> Perhaps. There's a problem while reading in the constant pool from an
> existing class file. (If it is a big-endian problem, shouldn't it fail on
> PPC too?)
>> I'm looking at jcf-parse.c:get_constant. This code looks suspicious:
>> case CONSTANT_Double:
> {
> HOST_WIDE_INT num[2];
> REAL_VALUE_TYPE d;
> HOST_WIDE_INT lo, hi;
> num[0] = JPOOL_INT (jcf, index);
> lshift_double (num[0], 0, 32, 64, &lo, &hi, 0);
> num[0] = JPOOL_INT (jcf, index+1);
> add_double (lo, hi, num[0], 0, &lo, &hi);
> if (FLOAT_WORDS_BIG_ENDIAN)
> {
> num[0] = hi;
> num[1] = lo;
> }
> 	...
>> For one thing, if HOST_WIDE_INT is 64 bits, then "lo" contains the entire
> number and we must not swap, right?

cool idea, and i immediately changed the line 
if (FLOAT_WORDS_BIG_ENDIAN)
into
if (FLOAT_WORDS_BIG_ENDIAN && sizeof(num[0]) < 8)
and after that the prog worked o.k. for the testcase on Linux and Solaris.
I just did a 'make && make install' inside gcc/gcc, no bootstrap since that
would take a day on my box.
What's the idea behind HOST_WIDE_INT? For the java frontend, all the
types are defined exactly by Sun. E.g. an int has 32 bits and so on.
So wouldn't types like int32_t be better for such tasks?
Thanks for the analysis!
Martin.
-- 
The early bird catches the worm. If you want something else for 
breakfast, get up later.