Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Rainer Orth]

Adam Megacz writes:

> Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> > 2002-02-06  Adam Megacz <adam@xwt.org>
> > 
> >         * gnu/gcj/io/shs.h, gnu/gcj/io/shs.cc, gnu/gcj/io/natSimpleSHSStream.cc:
> >         use uint<n>_t instead of LONG and BYTE
> > 
> > which unconditionally uses uint<n>_t
> 
> Nope, check shs.h (included from shs.cc):
> 
>   #include<config.h>
>   #if HAVE_INTTYPES_H
>   # include <inttypes.h>
>   #else
>   # if HAVE_STDINT_H
>   #  include <stdint.h>
>   # endif
>   #endif
> 
> If your system does not have one of these headers, it is not C99
> compliant. GCJ does not build on non-C99-compliant systems.

but this is both unlike the way libstdc++ handles this and a (completely
unnecessary) regression from GCC 3.0.x.

	Rainer

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Adam Megacz]

Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> a (completely unnecessary) regression from GCC 3.0.x.
    ^^^^^^^^^^^^^^^^^^^^^^^^

The old shs.cc assumed that an unsigned int was 32 bits. This is
broken. To my knowledge, it can only be fixed robustly on platforms
with proper (C99-compliant) headers.

It seems that you know of another way to fix the problem which will
work on systems lacking proper headers. Could you please post a patch
containing your suggested fix?

Thanks!

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Anthony Green]

On Wed, 2002-03-13 at 15:12, Adam Megacz wrote:
> The old shs.cc assumed that an unsigned int was 32 bits. This is
> broken. To my knowledge, it can only be fixed robustly on platforms
> with proper (C99-compliant) headers.
> 
> It seems that you know of another way to fix the problem which will
> work on systems lacking proper headers. Could you please post a patch
> containing your suggested fix?

I think we decided it would be OK to for the mode of the integer with a
type attribute.   This is what I need for newlib targets as well (like
xscale-elf).

AG

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Rainer Orth]

Anthony Green writes:

> I think we decided it would be OK to for the mode of the integer with a
> type attribute.   This is what I need for newlib targets as well (like
> xscale-elf).

right, this is exactly what java/lang/mprec.h does (as already noted in
the PR libgcj/5944.  I just don't have a good idea where to move this stuff
so it can be used both by java/lang and shs.h.

	Rainer

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Tom Tromey]

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

Rainer> right, this is exactly what java/lang/mprec.h does (as already
Rainer> noted in the PR libgcj/5944.  I just don't have a good idea
Rainer> where to move this stuff so it can be used both by java/lang
Rainer> and shs.h.

I'm not too concerned about that right now.  I don't know if I'll ever
be concerned with it :-).

Could you try this patch?

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	Fix for PR libgcj/5944.
	* gnu/gcj/io/shs.h: Define uint8_t and uint32_t.

Index: gnu/gcj/io/shs.h
===================================================================
RCS file: /cvs/gcc/gcc/libjava/gnu/gcj/io/shs.h,v
retrieving revision 1.2
diff -u -r1.2 shs.h
--- gnu/gcj/io/shs.h 2002/02/07 05:01:29 1.2
+++ gnu/gcj/io/shs.h 2002/03/15 21:05:55
@@ -21,6 +21,9 @@
 # if HAVE_STDINT_H
 #  include <stdint.h>
 # endif
+#else
+typedef unsigned int uint32_t __attribute__((mode(SI)));
+typedef unsigned int uint8_t __attribute__((mode(QI)));
 #endif
 
 /* The SHS block size and message digest sizes, in bytes */

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Rainer Orth]

Tom Tromey writes:

> Could you try this patch?

close :-)  After fixing the #else/#endif nesting, the initial version
failed on Solaris 2.5.1:

/vol/gnu/src/gcc/gcc-3.1-branch-dist/libjava/gnu/gcj/io/shs.h:24: conflicting 
   types for `typedef unsigned int uint32_t'
/vol/gcc/obj/gcc-3.1-20020313/2.5.1-gcc/gcc/include/pthread.h:40: previous 
   declaration as `typedef long unsigned int uint32_t'

Taking the whole section from java/lang/mprec.h works on both
sparc-sun-solaris2.5.1 (where the bootstrap completes now; I'll run the
testsuite and post results soon) and alpha-dec-osf4.0f (where shs.c
compiles, but I get the same ICE compiling java/lang/Character.java,
details follow).

	Rainer


Index: gnu/gcj/io/shs.h
===================================================================
RCS file: /cvs/gcc/gcc/libjava/gnu/gcj/io/shs.h,v
retrieving revision 1.2
diff -u -p -r1.2 shs.h
--- shs.h	2002/02/07 05:01:29	1.2
+++ shs.h	2002/03/15 21:28:02
@@ -20,6 +20,14 @@
 #else
 # if HAVE_STDINT_H
 #  include <stdint.h>
+# else
+typedef unsigned int uint8_t __attribute__((mode(QI)));
+/* This is a blatant hack: on Solaris 2.5, pthread.h defines uint32_t
+   in pthread.h, which we sometimes include.  We protect our
+   definition the same way Solaris 2.5 does, to avoid redefining it.  */
+#  ifndef _UINT32_T
+typedef unsigned int uint32_t __attribute__((mode(SI)));
+#  endif
 # endif
 #endif
 

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Tom Tromey]

Rainer> close :-) After fixing the #else/#endif nesting, the initial
Rainer> version failed on Solaris 2.5.1:

Sorry, I didn't even do a cursory test.

Rainer> Taking the whole section from java/lang/mprec.h works on both
Rainer> sparc-sun-solaris2.5.1 (where the bootstrap completes now;
Rainer> I'll run the testsuite and post results soon) and
Rainer> alpha-dec-osf4.0f (where shs.c compiles, but I get the same
Rainer> ICE compiling java/lang/Character.java, details follow).

Thanks.  I'll check this in soon.

Tom

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Rainer Orth]

Tom Tromey writes:

> Rainer> Taking the whole section from java/lang/mprec.h works on both
> Rainer> sparc-sun-solaris2.5.1 (where the bootstrap completes now;
> Rainer> I'll run the testsuite and post results soon) and
> Rainer> alpha-dec-osf4.0f (where shs.c compiles, but I get the same
> Rainer> ICE compiling java/lang/Character.java, details follow).
> 
> Thanks.  I'll check this in soon.

fine, thanks.  For the reference, here are the testsuite results for
libjava on sparc-sun-solaris2.5.1:

                === libjava tests ===


Running target unix
FAIL: PR5902 compilation from bytecode
FAIL: PR5902 -O compilation from bytecode
FAIL: linking cxxtest
FAIL: Invoke_1 execution from source compiled test
FAIL: Invoke_1 execution from bytecode->native test
FAIL: Invoke_1 -O execution from source compiled test
FAIL: Invoke_1 -O execution from bytecode->native test
FAIL: Primes output from source compiled test
FAIL: Primes output from bytecode->native test
FAIL: Primes -O output from source compiled test
FAIL: Primes -O output from bytecode->native test
FAIL: invokethrow execution from source compiled test
FAIL: invokethrow execution from bytecode->native test
FAIL: invokethrow -O execution from source compiled test
FAIL: invokethrow -O execution from bytecode->native test
FAIL: FileHandleGcTest execution from source compiled test
FAIL: FileHandleGcTest execution from bytecode->native test
FAIL: FileHandleGcTest -O execution from source compiled test
FAIL: FileHandleGcTest -O execution from bytecode->native test

		=== libjava Summary ===

# of expected passes		2009
# of unexpected failures	19
# of expected failures		19
# of untested testcases		26

Compared to the previous 3.0.5 results

	http://gcc.gnu.org/ml/gcc-testresults/2002-03/msg00293.html

they look excellent.  One new failure is the Primes test: there's a gc
message interspersed with the (correct) output:

Needed to allocate blacklisted block at 0x1f9000

Maybe this can be disabled in boehm-gc or ignored somehow: unlike the test
output, it is written to stderr, not stdout.

	Rainer

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Tom Tromey]

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

I didn't see a reply to this.

Rainer> One new failure is the Primes test: there's a gc message
Rainer> interspersed with the (correct) output:
Rainer> Needed to allocate blacklisted block at 0x1f9000
Rainer> Maybe this can be disabled in boehm-gc or ignored somehow:
Rainer> unlike the test output, it is written to stderr, not stdout.

This message is pretty much expected.  There's some discussion of this
on the list a while back.

Adding code to the test suite to let us ignore this has been on my
to-do list forever.

Tom

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Tom Tromey]

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

Rainer>  # if HAVE_STDINT_H
Rainer>  #  include <stdint.h>
Rainer> +# else

Does the else really belong here?
Solaris has <inttypes.h> but it doesn't define these types?

Tom

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Rainer Orth]

Tom Tromey writes:

> >>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> 
> Rainer>  # if HAVE_STDINT_H
> Rainer>  #  include <stdint.h>
> Rainer> +# else
> 
> Does the else really belong here?
> Solaris has <inttypes.h> but it doesn't define these types?

no, Solaris 2.5.1 has neither inttypes.h nor stdint.h.  inttypes.h first
appeared in 2.6.  Only Solaris 2.5.1 pthread.h has {u,}int<n>_t
definitions. 

	Rainer

Re: gnu/gcj/io/shs.cc doesn't compile on Solaris 2.5.1 (bootstrap failure)

[Tom Tromey]

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

Rainer> no, Solaris 2.5.1 has neither inttypes.h nor stdint.h.
Rainer> inttypes.h first appeared in 2.6.  Only Solaris 2.5.1
Rainer> pthread.h has {u,}int<n>_t definitions.

I was misreading the code.  Sigh.  I've checked in the patch and close
the PR.  Thanks.

Tom