rfc: clobber all call-saved registers

rfc: clobber all call-saved registers

[Richard Henderson]

On two instances in the last week, I've created reduced test
cases in which it was necessary to convince reload that it
could not put a particular value into a hard register in order
to elicit the problem.  In both instances I had to create a
platform-specific test that used an asm to clobber all the
registers in question.

I hate creating platform specific tests for potentially generic
problems, since the problem is bound to show up somewhere else
as well.  So what to do?  I can think of two options:

(1) A header file somewhere in the testsuite that has a whole
    whale-load of ifdefs and chooses the correct asm statement,

(2) A compiler builtin that generates the correct asm statement
    based on the contents of call_used[].

Thoughts?


r~

Re: rfc: clobber all call-saved registers

[Hans-Peter Nilsson]

On Tue, 8 Jan 2002, Richard Henderson wrote:
> I hate creating platform specific tests for potentially generic
> problems, since the problem is bound to show up somewhere else
> as well.  So what to do?  I can think of two options:
>
> (1) A header file somewhere in the testsuite that has a whole
>     whale-load of ifdefs and chooses the correct asm statement,
>
> (2) A compiler builtin that generates the correct asm statement
>     based on the contents of call_used[].
>
> Thoughts?

A trick question?  A built-in would solve the problem once and
for all targets, new and old, it seems.  If you think a
"self-serving" built-in looks bad, consider there are several
EH-builtins with very limited use.  Right, the test-suite isn't
a run-time library, but simplified test-cases are IMHO just as
important.

I think there are different needs: call_used, non-call_used and
all registers clobbered.  Perhaps others.

brgds, H-P

Re: rfc: clobber all call-saved registers

[Richard Earnshaw]

> On Tue, 8 Jan 2002, Richard Henderson wrote:
> > I hate creating platform specific tests for potentially generic
> > problems, since the problem is bound to show up somewhere else
> > as well.  So what to do?  I can think of two options:
> >
> > (1) A header file somewhere in the testsuite that has a whole
> >     whale-load of ifdefs and chooses the correct asm statement,
> >
> > (2) A compiler builtin that generates the correct asm statement
> >     based on the contents of call_used[].
> >
> > Thoughts?
> 
> A trick question?  A built-in would solve the problem once and
> for all targets, new and old, it seems.  If you think a
> "self-serving" built-in looks bad, consider there are several
> EH-builtins with very limited use.  Right, the test-suite isn't
> a run-time library, but simplified test-cases are IMHO just as
> important.
> 
> I think there are different needs: call_used, non-call_used and
> all registers clobbered.  Perhaps others.

Rather than creating loads of builtins that do lots of randomly different 
things, how about a __builtin_diagnostic(type,...) that can be used for a 
whole slew of these.  Clearly these shouldn't be used anywhere outside 
testing the compiler, and we can even keep the public documentation down 
to a minimum.

R.

Re: rfc: clobber all call-saved registers

[Richard Henderson]

On Wed, Jan 09, 2002 at 10:56:06AM +0000, Richard Earnshaw wrote:
> Rather than creating loads of builtins that do lots of randomly different 
> things, how about a __builtin_diagnostic(type,...) that can be used for a 
> whole slew of these.

I don't see the difference.


r~

Re: rfc: clobber all call-saved registers

[Gabriel Dos Reis]

Richard Earnshaw <rearnsha@arm.com> writes:

| > On Tue, 8 Jan 2002, Richard Henderson wrote:
| > > I hate creating platform specific tests for potentially generic
| > > problems, since the problem is bound to show up somewhere else
| > > as well.  So what to do?  I can think of two options:
| > >
| > > (1) A header file somewhere in the testsuite that has a whole
| > >     whale-load of ifdefs and chooses the correct asm statement,
| > >
| > > (2) A compiler builtin that generates the correct asm statement
| > >     based on the contents of call_used[].
| > >
| > > Thoughts?
| > 
| > A trick question?  A built-in would solve the problem once and
| > for all targets, new and old, it seems.  If you think a
| > "self-serving" built-in looks bad, consider there are several
| > EH-builtins with very limited use.  Right, the test-suite isn't
| > a run-time library, but simplified test-cases are IMHO just as
| > important.
| > 
| > I think there are different needs: call_used, non-call_used and
| > all registers clobbered.  Perhaps others.
| 
| Rather than creating loads of builtins that do lots of randomly different 
| things, how about a __builtin_diagnostic(type,...) that can be used for a 
| whole slew of these.  Clearly these shouldn't be used anywhere outside 
| testing the compiler, and we can even keep the public documentation down 
| to a minimum.

I do like the idea.  Any objection?

-- Gaby

Re: rfc: clobber all call-saved registers

[Richard Earnshaw]

> On Wed, Jan 09, 2002 at 10:56:06AM +0000, Richard Earnshaw wrote:
> > Rather than creating loads of builtins that do lots of randomly different 
> > things, how about a __builtin_diagnostic(type,...) that can be used for a 
> > whole slew of these.
> 
> I don't see the difference.
> 
> 
> r~

__builtin_clobber_call_regs  requires docuementation that says don't use 
it.
__builtin_test_someting_else requires docuementation that says don't use 
it.
...

Plus someone will then think "But that's what I want to make the compiler 
do, and the name clearly implies that, so I'll use it anyway" and we will 
end up with fights again as to whether we should continue to support it 
*in the way in which the user was relying upon it*.  People have misused 
several of our builtins in the past, and then wondered why the code wasn't 
portable to another machine or another release of the compiler.


If we have

__builtin_diagnostic(53)

Then externally we can say "__builtin_diagnostic is used for internal 
testing of the compiler, there are many sub-codes that affect the 
behaviour of this command, but they are not documented here, since they 
must not be used outside of testing the compiler".

Of course, we still have to have a table explaining what the sub-codes 
are, but it doesn't have to appear in the using and porting manual.

R.

Re: rfc: clobber all call-saved registers

[Joseph S. Myers]

On Wed, 9 Jan 2002, Richard Earnshaw wrote:

> Of course, we still have to have a table explaining what the sub-codes 
> are, but it doesn't have to appear in the using and porting manual.

We don't now have a using and porting manual.  We have a user manual, and 
we have a separate internals manual.  Clearly all built-in functions for 
internal use only should be documented in the internals manual, and all 
those for external use (where external use includes e.g. libc and kernel 
implementation) should be documented in the user manual.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: rfc: clobber all call-saved registers

[Alexandre Oliva]

On Jan  8, 2002, Richard Henderson <rth@redhat.com> wrote:

> (1) A header file somewhere in the testsuite that has a whole
>     whale-load of ifdefs and chooses the correct asm statement,

> (2) A compiler builtin that generates the correct asm statement
>     based on the contents of call_used[].

How about a new entry for the list already containing "cc" and
"memory", acceptable in the clobbers of an extended asm?

  asm ("" : : : "call_used");

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rfc: clobber all call-saved registers

[Richard Earnshaw]

> On Jan  8, 2002, Richard Henderson <rth@redhat.com> wrote:
> 
> > (1) A header file somewhere in the testsuite that has a whole
> >     whale-load of ifdefs and chooses the correct asm statement,
> 
> > (2) A compiler builtin that generates the correct asm statement
> >     based on the contents of call_used[].
> 
> How about a new entry for the list already containing "cc" and
> "memory", acceptable in the clobbers of an extended asm?
> 
>   asm ("" : : : "call_used");
> 

Hmm, this might be useful as a way of safely allowing an asm to call a 
subroutine and ensure that the compiler clobbers all the correct registers 
at that point.

R.

Re: rfc: clobber all call-saved registers

[David Edelsohn]

>>>>> Richard Earnshaw writes:

Richard> Hmm, this might be useful as a way of safely allowing an asm to call a 
Richard> subroutine and ensure that the compiler clobbers all the correct registers 
Richard> at that point.

	Yes, this would be great!  I have needed the ability to use magic
instructions to trap into simulators that expect function-like argument
passing. 

David

ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[jeroen dobbelaere]

Looking at testcase
	gcc.c-torture/execute/20020307-2.c

It seems that there is a problem with putting the arguments in the right place.
Following peace of code

void foo3()
{
#ifdef USE_DEFINE
# define zzz 2
#else
   int zzz=2;
#endif
   struct {
     int a[zzz];
   } t;

   t.a[0]=1;
   t.a[1]=2;

   foo4(t);
}


results, depending on the definition of 'USE_DEFINE' in completely different output :
  - for structures with a fixed array length, we get following (correct) code : (-O2)

foo3:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	str	lr, [sp, #-4]!
	adr	r0, .L25
	ldmia	r0, {r0-r1}
	@ Sibcall epilogue
	ldr	lr, [sp], #4
	b	foo4
.L26:
	.align	2
.L25:
	.word	1
	.word	2

  - for structures with a variable array length, we get following (incorrect) code :

	.size	foo,.Lfe2-foo
	.global	memcpy
	.align	2
	.global	foo3
	.type	foo3,function
foo3:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 1, uses_anonymous_args = 0
	mov	ip, sp
	stmfd	sp!, {r4, r5, fp, ip, lr, pc}
	mov	r3, #1
	mov	r5, sp
	mov	r2, #2
	sub	sp, sp, #8
	str	r3, [sp, #0]
	str	r2, [sp, #4]
	mov	r4, sp
	sub	sp, sp, #8
	mov	r0, sp
	sub	fp, ip, #4
	mov	r2, r2, asl r2
	mov	r1, r4
	bl	memcpy
	bl	foo4
	mov	sp, r4
	mov	sp, r5
	ldmea	fp, {r4, r5, fp, sp, pc}


Between the 'bl memcpy' and 'bl foo4' there is no loading of r0-r1...

(in the case of 20020307-2 : this results in no loading of r1-r3, while the
target function expects to see data in those registers...)

Any idea where this different behavior is triggered ?

Greetings,
-- 
Jeroen Dobbelaere
Embedded Software Engineer

ACUNIA Embedded Solutions
http://www.acunia.com/aes

Re: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[Richard Earnshaw]

> Looking at testcase
> 	gcc.c-torture/execute/20020307-2.c
> 
> It seems that there is a problem with putting the arguments in the right place.
> Following peace of code
> 
> void foo3()
> {
> #ifdef USE_DEFINE
> # define zzz 2
> #else
>    int zzz=2;
> #endif
>    struct {
>      int a[zzz];
>    } t;
> 
>    t.a[0]=1;
>    t.a[1]=2;
> 
>    foo4(t);
> }

When a struct is of potentially variable size (from the viewpoint of the 
callee), then the argument has to be passed by reference (we can't put it 
into the registers since it would mess up dereferencing everything else).  
Whether the reference is to the original (forcing callee copy semantics) 
or to a copy (caller-copy semantics) is something we have to decide on -- 
I'm inclined to require caller-copy.

The whole testcase is very much dependent on the GNU variable-sized array 
extension (you just can't do this in ISO C -- even in C99) so I haven't 
worried about it too much until now.

R.

Re: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[jeroen dobbelaere]

Richard Earnshaw wrote:
>>Looking at testcase
>>	gcc.c-torture/execute/20020307-2.c
>>
[...]
> 
> 
> When a struct is of potentially variable size (from the viewpoint of the 
> callee), then the argument has to be passed by reference (we can't put it 
> into the registers since it would mess up dereferencing everything else).  

Why is this such a problem ?

Looking at the current code (gcc-3.2) produced for the callee (with va_arg), the callee just
starts dumping r0-r3 to the stack, so that from that point,
he (it?) can access the arguments as if passed on the stack...
I guess something similar can be done (without variable arguments) when
a variable-sized array is passed...

But in that case, the caller still has to use the normal argument passing semantics
(and fill in r0-r3).


void foo (int size, ...)
{
   va_list ap;
   struct
   {
     char x[size];
   } d;
   int i;

   va_start (ap, size);
   ap=(typeof(ap)) ((unsigned long)ap );
   d = va_arg (ap, typeof (d));
   for (i = 0; i < size; i++)
     bar (d.x[i]);
   d = va_arg (ap, typeof (d));
   for (i = 0; i < size; i++)
     bar (d.x[i]);
   va_end (ap);
}


	.global	foo
	.type	foo,function
foo:
	@ args = 4, pretend = 16, frame = 0
	@ frame_needed = 1, uses_anonymous_args = 1
	mov	ip, sp
	stmfd	sp!, {r0, r1, r2, r3}
	stmfd	sp!, {r4, r5, r6, r7, r8, sl, fp, ip, lr, pc}
	sub	fp, ip, #20
	ldr	r6, [fp, #4]
	add	ip, fp, #8
	mov	sl, sp
	ands	r3, r6, #3
	movne	r3, #1
	add	r1, r3, r6, lsr #2
	sub	sp, sp, r1, asl #2
	add	r2, r3, r6, lsr #2
	mov	r2, r2, asl #2
	add	r3, r3, r6, lsr #2
	mov	r1, ip
	mov	r0, sp
	mov	r4, #0
	add	r8, ip, r3, asl #2
	bl	memcpy
	cmp	r4, r6
	sub	r7, r6, #1
	mov	r5, sp
[...]

> Whether the reference is to the original (forcing callee copy semantics) 
> or to a copy (caller-copy semantics) is something we have to decide on -- 
> I'm inclined to require caller-copy
> 
> The whole testcase is very much dependent on the GNU variable-sized array 
> extension (you just can't do this in ISO C -- even in C99) so I haven't 
> worried about it too much until now.
> 
> R.
> 

Yep. I'm just going over the different testsuite failures for ARM,
trying to tackle them down, one by one ;)

Greetings,
-- 
Jeroen Dobbelaere
Embedded Software Engineer

ACUNIA Embedded Solutions
http://www.acunia.com/aes

Re: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[Richard Earnshaw]

> Richard Earnshaw wrote:
> >>Looking at testcase
> >>	gcc.c-torture/execute/20020307-2.c
> >>
> [...]
> > 
> > 
> > When a struct is of potentially variable size (from the viewpoint of the 
> > callee), then the argument has to be passed by reference (we can't put it 
> > into the registers since it would mess up dereferencing everything else).  
> 
> Why is this such a problem ?
> 
> Looking at the current code (gcc-3.2) produced for the callee (with va_arg), the callee just
> starts dumping r0-r3 to the stack, so that from that point,
> he (it?) can access the arguments as if passed on the stack...
> I guess something similar can be done (without variable arguments) when
> a variable-sized array is passed...

Consider it from the callers point of view; for example

void foo(int size, ...);

bar ()
{
   int i;

   for (i = 1, i < 5; i++)
     {
        struct {
	  int x[i];
        } d;
	int j;

	for (j = 0; j < i; j++)
	  d[j] = j;

        foo (i, d, 99);
     }
}

Where is 99 put?  Answer: it depends on the value of i.  If i < 3, then 99 
is placed in a register, otherwise it is on the stack.  For the register 
case even that can vary.

That makes compiling the call to foo very difficult, if not impossible.

It's even worse for passing d itself, part of it (sometimes all of it) is 
in registers, and the remainder of it (if there is any) is on the stack.  
How much stack space do we have to allocate...

It's far cleaner to handle this case by making a copy and passing an 
address of the copy, even if this isn't the way most other types of 
argument are handled.

Variadic functions are rare in real life, and are inherently slow; so I 
don't think we need to spend a lot of time on this, especially since it's 
a rather peculiar GCCism.

Now if the above were legal ISO C, then I'd worry about it more; but it 
isn't, so I'm not.

R.

Re: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[David Edelsohn]

>>>>> Richard Earnshaw writes:

Richard> Where is 99 put?  Answer: it depends on the value of i.  If i < 3, then 99 
Richard> is placed in a register, otherwise it is on the stack.  For the register 
Richard> case even that can vary.

Richard> That makes compiling the call to foo very difficult, if not impossible.

Richard> It's even worse for passing d itself, part of it (sometimes all of it) is 
Richard> in registers, and the remainder of it (if there is any) is on the stack.  
Richard> How much stack space do we have to allocate...

	Passing the arguments in registers is difficult if one constructs
the arguments one at a time.  On AIX, at least, the registers are an image
of the beginning of the argument list on the stack.  When passing
arguments in registers, GCC can handle fixed-size arguments to varadic
functions and a fixed number of variable-sized arguments.  Also, passing
the variable-sized argument by reference requires that the argument be
constructed on the stack.

	I believe that GCC could handle variable-sized arguments to
varadic functions if it constructed the entire argument list on the stack
and then copied the memory image of the beginning of the argument list
into the argument registers.  GCC would perform a block load of all
argument registers, regardless the actual number of arguments  This is a
finite, well-defined operation and does not require that GCC construct the
actual register argument list piece by piece.

	I do not know if the ARM ABI calling convention allows for this
technique, and GCC currently does not support it, but it allows GCC to
generate the register arguments without knowing their size, thereby
supporting the GCC extension and conforming to the target calling
convention for passing structures.

David

Re: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[Richard Earnshaw]

> 	I believe that GCC could handle variable-sized arguments to
> varadic functions if it constructed the entire argument list on the stack
> and then copied the memory image of the beginning of the argument list
> into the argument registers.  GCC would perform a block load of all
> argument registers, regardless the actual number of arguments  This is a
> finite, well-defined operation and does not require that GCC construct the
> actual register argument list piece by piece.

But would involve moving the stack pointer in the body of the function 
(something we generally want to avoid as it makes things harder for the 
debugger when there is no frame pointer -- not that we can really compile 
this particular extension without one :-) or moving the unpushed data down 
in the stack once the register arguments have been removed.

> 
> 	I do not know if the ARM ABI calling convention allows for this
> technique, and GCC currently does not support it, but it allows GCC to
> generate the register arguments without knowing their size, thereby
> supporting the GCC extension and conforming to the target calling
> convention for passing structures.

I really don't think it's worth spending a lot of time on this problem, 
and I really don't want to start significantly messing up the ARM back end 
in order to support it when there's no evidence of it being in regular use 
-- try and write a non-variadic function that uses this feature and yet 
still has a prototype if want to see what a mess it causes.  Passing 
arguments of this type by reference would solve the problem with minimal 
invasion into the ARM back-end (we simply define FUNCTION_ARG_PASS_BY_REFER
ENCE in the same way as ia64 has done and we are finished).

R.

[patch] Re: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[jeroen dobbelaere]

Richard Earnshaw wrote:
[..]

> 
> 
> I really don't think it's worth spending a lot of time on this problem, 
> and I really don't want to start significantly messing up the ARM back end 
> in order to support it when there's no evidence of it being in regular use 
> -- try and write a non-variadic function that uses this feature and yet 
> still has a prototype if want to see what a mess it causes.  Passing 
> arguments of this type by reference would solve the problem with minimal 
> invasion into the ARM back-end (we simply define FUNCTION_ARG_PASS_BY_REFER
> ENCE in the same way as ia64 has done and we are finished).
> 
> R.
> 

I agree, as this is a gcc specific extension...
I have implemented this (similar to ia64) and I'm doing a regression test right
now (c only). First indication is that 20020307-2.c does not fail any more...

2002-11-13  Jeroen Dobbelaere  <jeroen.dobbelaere@acunia.com>

	* config/arm/arm.h (EXPAND_BUILTIN_VA_ARG,
	FUNCTION_ARG_PASS_BY_REFERENCE): Add.
	* config/arm/arm.c (arm_va_arg,
	arm_function_arg_pass_by_reference): Add.
	* config/arm/arm-protos.h: Add prototypes.

diff -ur gcc-3.2.1-20021111/gcc/config/arm-orig/arm-protos.h gcc-3.2.1-20021111/gcc/config/arm/arm-protos.h
--- gcc-3.2.1-20021111/gcc/config/arm-orig/arm-protos.h	Wed Nov 13 14:27:31 2002
+++ gcc-3.2.1-20021111/gcc/config/arm/arm-protos.h	Wed Nov 13 13:12:18 2002
@@ -136,6 +136,11 @@
  						enum machine_mode, tree, int));
  extern void   arm_init_cumulative_args	PARAMS ((CUMULATIVE_ARGS *, tree, rtx,
  						int));
+extern rtx    arm_va_arg                PARAMS ((tree, tree));
+extern int    arm_function_arg_pass_by_reference PARAMS ((CUMULATIVE_ARGS *,
+						         enum machine_mode,
+						         tree, int));
+
  #endif

  #if defined AOF_ASSEMBLER
diff -ur gcc-3.2.1-20021111/gcc/config/arm-orig/arm.c gcc-3.2.1-20021111/gcc/config/arm/arm.c
--- gcc-3.2.1-20021111/gcc/config/arm-orig/arm.c	Wed Nov 13 14:27:31 2002
+++ gcc-3.2.1-20021111/gcc/config/arm/arm.c	Wed Nov 13 14:22:30 2002
@@ -1899,6 +1899,35 @@

    return gen_rtx_REG (mode, pcum->nregs);
  }
+
+/* Variable sized types are passed by reference.  */
+/* ??? At present this is a GCC extension to the ARM ABI.  */
+
+int
+arm_function_arg_pass_by_reference (cum, mode, type, named)
+     CUMULATIVE_ARGS *cum ATTRIBUTE_UNUSED;
+     enum machine_mode mode ATTRIBUTE_UNUSED;
+     tree type;
+     int named ATTRIBUTE_UNUSED;
+{
+  return type && TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST;
+}
+
+/* Implement va_arg.  */
+
+rtx
+arm_va_arg (valist, type)
+     tree valist, type;
+{
+  /* Variable sized types are passed by reference.  */
+  if (TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST)
+    {
+      rtx addr = std_expand_builtin_va_arg (valist, build_pointer_type (type));
+      return gen_rtx_MEM (ptr_mode, force_reg (Pmode, addr));
+    }
+
+  return std_expand_builtin_va_arg (valist, type);
+}

  /* Encode the current state of the #pragma [no_]long_calls.  */
  typedef enum
diff -ur gcc-3.2.1-20021111/gcc/config/arm-orig/arm.h gcc-3.2.1-20021111/gcc/config/arm/arm.h
--- gcc-3.2.1-20021111/gcc/config/arm-orig/arm.h	Wed Nov 13 14:27:31 2002
+++ gcc-3.2.1-20021111/gcc/config/arm/arm.h	Wed Nov 13 13:10:08 2002
@@ -1506,6 +1506,16 @@
     && (NUM_ARG_REGS < ((CUM).nregs + NUM_REGS2 (MODE, TYPE)))	\
     ?   NUM_ARG_REGS - (CUM).nregs : 0)

+/* A C expression that indicates when an argument must be passed by reference.
+   If nonzero for an argument, a copy of that argument is made in memory and a
+   pointer to the argument is passed instead of the argument itself.  The
+   pointer is passed in whatever way is appropriate for passing a pointer to
+   that type.  */
+
+#define FUNCTION_ARG_PASS_BY_REFERENCE(CUM, MODE, TYPE, NAMED) \
+  arm_function_arg_pass_by_reference (&CUM, MODE, TYPE, NAMED)
+
+
  /* Initialize a variable CUM of type CUMULATIVE_ARGS
     for a call to a function whose data type is FNTYPE.
     For a library call, FNTYPE is 0.
@@ -1523,6 +1533,9 @@
     On the ARM, r0-r3 are used to pass args.  */
  #define FUNCTION_ARG_REGNO_P(REGNO)	(IN_RANGE ((REGNO), 0, 3))

+/* Implement `va_arg'.  */
+#define EXPAND_BUILTIN_VA_ARG(valist, type) \
+  arm_va_arg (valist, type)

  /* Tail calling.  */



Greetings,
-- 
Jeroen Dobbelaere
Embedded Software Engineer

ACUNIA Embedded Solutions
http://www.acunia.com/aes

Re: [patch] Re: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[jeroen dobbelaere]

jeroen dobbelaere wrote:
[...]

> I have implemented this (similar to ia64) and I'm doing a regression 
> test right
> now (c only). First indication is that 20020307-2.c does not fail any 
> more...
> 
> 2002-11-13  Jeroen Dobbelaere  <jeroen.dobbelaere@acunia.com>
> 
>     * config/arm/arm.h (EXPAND_BUILTIN_VA_ARG,
>     FUNCTION_ARG_PASS_BY_REFERENCE): Add.
>     * config/arm/arm.c (arm_va_arg,
>     arm_function_arg_pass_by_reference): Add.
>     * config/arm/arm-protos.h: Add prototypes.
> 

no regressions seen (checked gcc, g++, objc, f77), 8 failures gone...

Greetings,
-- 
Jeroen Dobbelaere
Embedded Software Engineer

ACUNIA Embedded Solutions
http://www.acunia.com/aes

Re: [patch] Re: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[Richard Earnshaw]

> jeroen dobbelaere wrote:
> [...]
> 
> > I have implemented this (similar to ia64) and I'm doing a regression 
> > test right
> > now (c only). First indication is that 20020307-2.c does not fail any 
> > more...
> > 
> > 2002-11-13  Jeroen Dobbelaere  <jeroen.dobbelaere@acunia.com>
> > 
> >     * config/arm/arm.h (EXPAND_BUILTIN_VA_ARG,
> >     FUNCTION_ARG_PASS_BY_REFERENCE): Add.
> >     * config/arm/arm.c (arm_va_arg,
> >     arm_function_arg_pass_by_reference): Add.
> >     * config/arm/arm-protos.h: Add prototypes.
> > 
> 
> no regressions seen (checked gcc, g++, objc, f77), 8 failures gone...

Which configuration have you tested?

It's quite important for a change like this that some checks with 
libraries built with older compilers are run to ensure we haven't changed 
the ABI in some unexpected manner.

R.

Re: [patch] Re: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[jeroen dobbelaere]

Richard Earnshaw wrote:
>>jeroen dobbelaere wrote:
>>[...]
>>
>>
>>>I have implemented this (similar to ia64) and I'm doing a regression 
>>>test right
>>>now (c only). First indication is that 20020307-2.c does not fail any 
>>>more...
>>>
>>>2002-11-13  Jeroen Dobbelaere  <jeroen.dobbelaere@acunia.com>
>>>
>>>    * config/arm/arm.h (EXPAND_BUILTIN_VA_ARG,
>>>    FUNCTION_ARG_PASS_BY_REFERENCE): Add.
>>>    * config/arm/arm.c (arm_va_arg,
>>>    arm_function_arg_pass_by_reference): Add.
>>>    * config/arm/arm-protos.h: Add prototypes.
>>>
>>
>>no regressions seen (checked gcc, g++, objc, f77), 8 failures gone...
> 
> 
> Which configuration have you tested?

armv5l-unknown-linux-gnu; --with-cpu=xscale

> 
> It's quite important for a change like this that some checks with 
> libraries built with older compilers are run to ensure we haven't changed 

what do you mean with 'older compilers' ?
The glibc that is used has been compiled with a gcc-3.0.4.

> the ABI in some unexpected manner.
> 
> R.
> 

Any suggestion on how to do this exactly ?

Greetings,
-- 
Jeroen Dobbelaere
Embedded Software Engineer

ACUNIA Embedded Solutions
http://www.acunia.com/aes

Re: [patch] Re: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure

[Richard Earnshaw]

> Richard Earnshaw wrote:
> >>jeroen dobbelaere wrote:
> >>[...]
> >>
> >>
> >>>I have implemented this (similar to ia64) and I'm doing a regression 
> >>>test right
> >>>now (c only). First indication is that 20020307-2.c does not fail any 
> >>>more...
> >>>
> >>>2002-11-13  Jeroen Dobbelaere  <jeroen.dobbelaere@acunia.com>
> >>>
> >>>    * config/arm/arm.h (EXPAND_BUILTIN_VA_ARG,
> >>>    FUNCTION_ARG_PASS_BY_REFERENCE): Add.
> >>>    * config/arm/arm.c (arm_va_arg,
> >>>    arm_function_arg_pass_by_reference): Add.
> >>>    * config/arm/arm-protos.h: Add prototypes.
> >>>
> >>
> >>no regressions seen (checked gcc, g++, objc, f77), 8 failures gone...
> > 
> > 
> > Which configuration have you tested?
> 
> armv5l-unknown-linux-gnu; --with-cpu=xscale

Excellent.  It's just that if you use a simulator (eg arm-elf) then you 
end up only testing the compiler against libraries built with the same 
build of the compiler...

> 
> > 
> > It's quite important for a change like this that some checks with 
> > libraries built with older compilers are run to ensure we haven't changed 
> 
> what do you mean with 'older compilers' ?
> The glibc that is used has been compiled with a gcc-3.0.4.
> 
> > the ABI in some unexpected manner.
> > 
> > R.
> > 
> 
> Any suggestion on how to do this exactly ?

I think it's ok now.  You've tested it with linux; I've tested it with 
NetBSD over last night and I've checked that conventional structure 
passing hasn't changed it's behaviour.

So the patch is approved, thanks.

R.

PCH tests fail on sparc-sun-solaris2.7

[Kaveh R. Ghazi]

Geoff - as seen here:
http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg00571.html
pretty much all of the PCH tests fail on sparc-sun-solaris2.7.

Looking in the log file, all of the error messages look like this:

 > gcc.dg/pch/global-1.c:-71: sorry, unimplemented: had to relocate PCH
 > gcc.dg/pch/global-1.c:-71: internal compiler error: Segmentation Fault

(Sometimes the line number was -70 or -72 for the various other tests.)
The g++ tests fail the same way.

I looked in gcc.dg/pch/pch.exp and guessed that I had to generate the
PCH file by hand and rename it to *.hp.pch.  (Is that right?)  Then I
ran cc1 on global-1.c under gdb and got an invalid memory reference as
you can see below.  I'm not sure what I need to provide for you to
reproduce it in a cross config.  PCH perhaps requires us to update our
bug reporting instructions slightly?

		--Kaveh


 > (gdb) run -quiet -v -I. -iprefix
 > /teal/tmpdisk/ghazi/gcc-testing/34/build/gcc/../lib/gcc-lib/sparc-sun-solaris2.7/3.4/
 > -isystem /teal/tmpdisk/ghazi/gcc-testing/34/build/gcc/include
 > -D__GNUC__=3 -D__GNUC_MINOR__=4 -D__GNUC_PATCHLEVEL__=0 -Dsparc
 > -D__sparc__ -D__sparc -D__GCC_NEW_VARARGS__ -Acpu=sparc
 > -Amachine=sparc
 > /teal/tmpdisk/ghazi/gcc-testing/34/egcc-CVS20030112/gcc/testsuite/gcc.dg/pch/global-1.c
 > -quiet -dumpbase global-1.c -auxbase-strip global-1.s -O0 -version -o
 > global-1.s
 > Starting program: /teal/tmpdisk/ghazi/gcc-testing/34/build/gcc/cc1
 > -quiet -v -I. -iprefix
 > /teal/tmpdisk/ghazi/gcc-testing/34/build/gcc/../lib/gcc-lib/sparc-sun-solaris2.7/3.4/
 > -isystem /teal/tmpdisk/ghazi/gcc-testing/34/build/gcc/include
 > -D__GNUC__=3 -D__GNUC_MINOR__=4 -D__GNUC_PATCHLEVEL__=0 -Dsparc
 > -D__sparc__ -D__sparc -D__GCC_NEW_VARARGS__ -Acpu=sparc
 > -Amachine=sparc
 > /teal/tmpdisk/ghazi/gcc-testing/34/egcc-CVS20030112/gcc/testsuite/gcc.dg/pch/global-1.c
 > -quiet -dumpbase global-1.c -auxbase-strip global-1.s -O0 -version -o
 > global-1.s
 > 
 > GNU C version 3.4 20030112 (experimental) (sparc-sun-solaris2.7)
 >         compiled by GNU C version 3.4 20030112 (experimental).
 > ignoring nonexistent directory
 > "/teal/tmpdisk/ghazi/gcc-testing/34/build/lib/gcc-lib/sparc-sun-solaris2.7/3.4/include"
 > ignoring nonexistent directory
 > "/teal/tmpdisk/ghazi/gcc-testing/34/build/lib/gcc-lib/sparc-sun-solaris2.7/3.4/../../../../sparc-sun-solaris2.7/include"
 > ignoring nonexistent directory "NONE/include"
 > ignoring nonexistent directory
 > "/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/3.4/include"
 > ignoring nonexistent directory
 > "/usr/local/sparc-sun-solaris2.7/include"
 > #include "..." search starts here:
 > #include <...> search starts here:
 >  .
 >  /teal/tmpdisk/ghazi/gcc-testing/34/build/gcc/include
 >  /usr/local/include
 >  /usr/include
 > End of search list.
 > /teal/tmpdisk/ghazi/gcc-testing/34/egcc-CVS20030112/gcc/testsuite/gcc.dg/pch/global-1.c:-70: sorry, unimplemented: had to relocate PCH
 > Program received signal SIGSEGV, Segmentation fault.
 > reset_ht (r=0x440330, h=0xafafafbb, unused=0x0) at
 > ../../egcc-CVS20030112/gcc/cpppch.c:552
 > 552       if (h->type != NT_VOID
 > (gdb) bt
 > #0  reset_ht (r=0x440330, h=0xafafafbb, unused=0x0) at ../../egcc-CVS20030112/gcc/cpppch.c:552
 > #1  0x000a3ba0 in ht_forall (table=0x40b4a0, cb=0xa5bbc <reset_ht>, v=0x0) at ../../egcc-CVS20030112/gcc/hashtable.c:235
 > #2  0x000a5c18 in cpp_read_state (r=0x440330, name=0x4098e8 "global-1.hp.pch", f=0x409790, data=0x4467b0)
 >     at ../../egcc-CVS20030112/gcc/cpppch.c:583
 > #3  0x000923e0 in c_common_read_pch (pfile=0x440330, name=0x4098e8 "global-1.hp.pch", fd=4779608,
 >     orig_name=0x4098e8 "global-1.hp.pch") at ../../egcc-CVS20030112/gcc/c-pch.c:220
 > #4  0x0009e5ac in stack_include_file (pfile=0x440330, inc=0x48cc38) at ../../egcc-CVS20030112/gcc/cppfiles.c:437
 > #5  0x0009eca8 in _cpp_execute_include (pfile=0x440330, header=0x4405b8, type=IT_INCLUDE)
 >     at ../../egcc-CVS20030112/gcc/cppfiles.c:828
 > #6  0x0009282c in _cpp_handle_directive (pfile=0x440330, indented=0) at ../../egcc-CVS20030112/gcc/cpplib.c:443
 > #7  0x00095dd8 in _cpp_lex_token (pfile=0x440330) at ../../egcc-CVS20030112/gcc/cpplex.c:864
 > #8  0x0009962c in cpp_get_token (pfile=0x440330) at ../../egcc-CVS20030112/gcc/cppmacro.c:1123
 > #9  0x00047240 in c_lex (value=0x3a6ea0) at ../../egcc-CVS20030112/gcc/c-lex.c:683
 > #10 0x0003e748 in _yylex () at c-parse.y:2953
 > #11 0x0003e574 in yylex () at c-parse.y:3061
 > #12 0x0003c7d0 in yyparse () at c-p21554.c:2479
 > #13 0x00046ce4 in c_common_parse_file (set_yydebug=0) at ../../egcc-CVS20030112/gcc/c-lex.c:165
 > #14 0x00284d54 in compile_file () at ../../egcc-CVS20030112/gcc/toplev.c:2130
 > #15 0x0028a898 in do_compile () at ../../egcc-CVS20030112/gcc/toplev.c:5353
 > #16 0x0028a95c in toplev_main (argc=27, argv=0xffbef904) at ../../egcc-CVS20030112/gcc/toplev.c:5384
 > (gdb) p h
 > $1 = (cpp_hashnode *) 0xafafafbb
 > (gdb) p *h
 > Cannot access memory at address 0xafafafbb

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: PCH tests fail on sparc-sun-solaris2.7

[Geoff Keating]

> Date: Mon, 13 Jan 2003 16:16:50 -0500 (EST)
> From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>

> Geoff - as seen here:
> http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg00571.html
> pretty much all of the PCH tests fail on sparc-sun-solaris2.7.
> 
> Looking in the log file, all of the error messages look like this:
> 
>  > gcc.dg/pch/global-1.c:-71: sorry, unimplemented: had to relocate PCH
>  > gcc.dg/pch/global-1.c:-71: internal compiler error: Segmentation Fault
> 
> (Sometimes the line number was -70 or -72 for the various other tests.)
> The g++ tests fail the same way.
> 
> I looked in gcc.dg/pch/pch.exp and guessed that I had to generate the
> PCH file by hand and rename it to *.hp.pch.  (Is that right?)  Then I
> ran cc1 on global-1.c under gdb and got an invalid memory reference as
> you can see below.  I'm not sure what I need to provide for you to
> reproduce it in a cross config.  PCH perhaps requires us to update our
> bug reporting instructions slightly?

The bug reporting instructions have been updated, but don't bother;
this is certainly a host-specific problem.  If every test is failing
with this message, that means the heuristic in gt_pch_save ("Try to
arrange things...") isn't working.  It'd be possible to implement the
relocation functionality, but this would slow down PCH use on your
system a lot, it'd be better if you could first work out what the
problem with the heuristic is.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: PCH tests fail on sparc-sun-solaris2.7

[Richard Earnshaw]

There are a number of arm-elf failures as well.  Most of them seem to be 
assembly file differences (presumably this is the 'dwarf2' problem), but 
one leads to an ICE.

/home/rearnsha/gnusrc/egcs-cross/gcc/testsuite/gcc.dg/pch/inline-1.c: In 
function `foo':
/home/rearnsha/gnusrc/egcs-cross/gcc/testsuite/gcc.dg/pch/inline-1.c:5: 
internal compiler error: in gen_subprogram_die, at dwarf2out.c:10752
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

This one:

/work/rearnsha/gnu/egcs/gcc/xgcc -B/work/rearnsha/gnu/egcs/gcc/ /home/rear
nsha/gnusrc/egcs-cross/gcc/testsuite/gcc.dg/pch/static-1.c -O0 -I. 
-DSTACK_SIZE=
16384 -S -I/work/rearnsha/gnu/egcs/arm-elf/./newlib/targ-include 
-I/home/rearnsh
a/gnusrc/egcs-cross/newlib/libc/include -o static-1.s 
PASS: gcc.dg/pch/static-1.c (test for excess errors)
line #40
<       ldr     r2, .L5
>       ldr     r2, .L2
line #48
< .L6:
> .L3:
line #50
< .L5:
> .L2:

Also looks suspicious (no sign of any dwarfisms there).  It also fails at 
other optimization levels.  The same is also true of static-2.s

All of the above are produced on an arm-elf cross using newlib.

R.

Re: PCH tests fail on sparc-sun-solaris2.7

[David Edelsohn]

>>>>> Richard Earnshaw writes:

Richard> PASS: gcc.dg/pch/static-1.c (test for excess errors)
Richard> line #40
Richard> <       ldr     r2, .L5
>> ldr     r2, .L2
Richard> line #48
Richard> < .L6:
>> .L3:
Richard> line #50
Richard> < .L5:
>> .L2:

Richard> Also looks suspicious (no sign of any dwarfisms there).  It also fails at 
Richard> other optimization levels.  The same is also true of static-2.s

Richard> All of the above are produced on an arm-elf cross using newlib.

	PowerPC AIX had a similar assembler mis-compare do to label but it
recently resolved itself.

David

Re: PCH tests fail on sparc-sun-solaris2.7

[David Edelsohn]

>>>>> Richard Earnshaw writes:

PASS: gcc.dg/pch/static-1.c (test for excess errors)
line #40
<       ldr     r2, .L5
>       ldr     r2, .L2
line #48
< .L6:
> .L3:
line #50
< .L5:
> .L2:

Richard> Also looks suspicious (no sign of any dwarfisms there).  It also fails at 
Richard> other optimization levels.  The same is also true of static-2.s

	It turns out that I do see a similar assembly file miscompare due
to labels for the G++ system-1.C testcase:

PASS: g++.dg/pch/system-1.C (test for excess errors)
line #90
< LCFI..4:
> LCFI..0:
line #92
< LCFI..5:
> LCFI..1:
line #125
< LCFI..6:
> LCFI..2:
line #127
< LCFI..7:
> LCFI..3:
line #136
< LCFI..8:
> LCFI..4:
line #139
< LCFI..9:
> LCFI..5:
line #140
<       bne- 0,L..7
>       bne- 0,L..5
line #141
< L..5:
> L..3:
line #145
<       bne- 0,L..8
>       bne- 0,L..6
line #146
< L..4:
> L..2:
line #153
< L..8:
> L..6:
line #157
<       b L..4
>       b L..2
line #158
< L..7:
> L..5:
line #162
<       b L..5
>       b L..3
line #240
<       .vbyte  4,LFB..7
>       .vbyte  4,LFB..1394
line #241
<       .vbyte  4,LFE..7-LFB..7
>       .vbyte  4,LFE..1394-LFB..1394
line #244
<       .vbyte  4,LCFI..1-LFB..7
>       .vbyte  4,LCFI..1-LFB..1394
line #256
<       .vbyte  4,LFB..9
>       .vbyte  4,LFB..1403
line #257
<       .vbyte  4,LFE..9-LFB..9
>       .vbyte  4,LFE..1403-LFB..1403
line #260
<       .vbyte  4,LCFI..3-LFB..9
>       .vbyte  4,LCFI..3-LFB..1403

Re: PCH tests fail on sparc-sun-solaris2.7

[Kaveh R. Ghazi]

 > From: Geoff Keating <geoffk@geoffk.org>
 > 
 > > Date: Mon, 13 Jan 2003 16:16:50 -0500 (EST)
 > > From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
 > 
 > > pretty much all of the PCH tests fail on sparc-sun-solaris2.7.
 > > Looking in the log file, all of the error messages look like this:
 > > 
 > >  > gcc.dg/pch/global-1.c:-71: sorry, unimplemented: had to relocate PCH
 > >  > gcc.dg/pch/global-1.c:-71: internal compiler error: Segmentation Fault
 > > 
 > 
 > this is certainly a host-specific problem.  If every test is failing
 > with this message, that means the heuristic in gt_pch_save ("Try to
 > arrange things...") isn't working.  It'd be possible to implement the
 > relocation functionality, but this would slow down PCH use on your
 > system a lot, it'd be better if you could first work out what the
 > problem with the heuristic is.

If I understand things correctly, gt_pch_save is called when the PCH
file is generated.  However the crash happens later when the PCH file
is attempted to be used.  So it's the PCH generation that goes wrong?

I ran the generation under gdb and set a breakpoint in gt_pch_save.
When I get past the mmap, the mmi struct contains:

(gdb) print mmi
$1 = {offset = 1, size = 311296, preferred_base = 0x5b}

I.e. mmap does not return -1 indicating an error.  I'm not sure if
0x5b is a suspicious address though.  I can't access it.

(gdb) print (char*)mmi.preferred_base
$4 = 0x5b <Address 0x5b out of bounds>

It then gets immediately munmapped and the process continues
supposedly successfully until program exit.  I'm not sure what
constitutes a correct "heuristic".  What should I look for?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: PCH tests fail on sparc-sun-solaris2.7

[Geoff Keating]

> Date: Sun, 19 Jan 2003 09:38:29 -0500 (EST)
> From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>

>  > From: Geoff Keating <geoffk@geoffk.org>
>  > 
>  > > Date: Mon, 13 Jan 2003 16:16:50 -0500 (EST)
>  > > From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
>  > 
>  > > pretty much all of the PCH tests fail on sparc-sun-solaris2.7.
>  > > Looking in the log file, all of the error messages look like this:
>  > > 
>  > >  > gcc.dg/pch/global-1.c:-71: sorry, unimplemented: had to relocate PCH
>  > >  > gcc.dg/pch/global-1.c:-71: internal compiler error: Segmentation Fault
>  > > 
>  > 
>  > this is certainly a host-specific problem.  If every test is failing
>  > with this message, that means the heuristic in gt_pch_save ("Try to
>  > arrange things...") isn't working.  It'd be possible to implement the
>  > relocation functionality, but this would slow down PCH use on your
>  > system a lot, it'd be better if you could first work out what the
>  > problem with the heuristic is.
> 
> If I understand things correctly, gt_pch_save is called when the PCH
> file is generated.  However the crash happens later when the PCH file
> is attempted to be used.  So it's the PCH generation that goes wrong?

The way that PCH works is that it creates and saves a memory image,
then loads it in when the PCH is used.  There are all kinds of
pointers in this image, so it matters where it gets loaded.  The
saving code tries to guess a place to load it, and initially sets the
pointers to be good for that location.  The 'sorry' is because I never
did get around to implementing the code that relocates the image; it's
not hard to do (all the tricky framework stuff is done), but it's not
a high priority since it works without relocation on most systems
(well, linux and Darwin) every time.  The relocation would be
expensive, because it'd have to write to nearly every page in the
loaded image.

> I ran the generation under gdb and set a breakpoint in gt_pch_save.
> When I get past the mmap, the mmi struct contains:
> 
> (gdb) print mmi
> $1 = {offset = 1, size = 311296, preferred_base = 0x5b}
> 
> I.e. mmap does not return -1 indicating an error.  I'm not sure if
> 0x5b is a suspicious address though.  I can't access it.

That's very weird.  0x5b can't possibly be right, it's got to be
page-aligned.

> (gdb) print (char*)mmi.preferred_base
> $4 = 0x5b <Address 0x5b out of bounds>
> 
> It then gets immediately munmapped and the process continues
> supposedly successfully until program exit.  I'm not sure what
> constitutes a correct "heuristic".  What should I look for?

The code is looking for a place where it can mmap 311296 bytes when it
loads the PCH file.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: PCH tests fail on sparc-sun-solaris2.7

[Segher Boessenkool]

Geoff Keating wrote:
> 
> >  > > pretty much all of the PCH tests fail on sparc-sun-solaris2.7.

> > I.e. mmap does not return -1 indicating an error.  I'm not sure if
> > 0x5b is a suspicious address though.  I can't access it.
> 
> That's very weird.  0x5b can't possibly be right, it's got to be
> page-aligned.

Maybe it's related to this comment (from ggc-page.c):

  /* StunOS has an amazing off-by-one error for the first mmap allocation
     after fiddling with RLIMIT_STACK.  The result, as hard as it is to
     believe, is an unaligned page allocation, which would cause us to
     hork badly if we tried to use it.  */

...or maybe not.  No idea how old this comment is.


Segher

Re: PCH tests fail on sparc-sun-solaris2.7

[Kaveh R. Ghazi]

 > From: Segher Boessenkool <segher@koffie.nl>
 > 
 > Geoff Keating wrote:
 > > 
 > > >  > > pretty much all of the PCH tests fail on sparc-sun-solaris2.7.
 > 
 > > > I.e. mmap does not return -1 indicating an error.  I'm not sure if
 > > > 0x5b is a suspicious address though.  I can't access it.
 > > 
 > > That's very weird.  0x5b can't possibly be right, it's got to be
 > > page-aligned.
 > 
 > Maybe it's related to this comment (from ggc-page.c):
 > 
 >   /* StunOS has an amazing off-by-one error for the first mmap allocation
 >      after fiddling with RLIMIT_STACK.  The result, as hard as it is to
 >      believe, is an unaligned page allocation, which would cause us to
 >      hork badly if we tried to use it.  */
 > 
 > ...or maybe not.  No idea how old this comment is.
 > Segher

I'm pretty sure that comment referred to SunOS4, not solaris2.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu