[parisc-linux] [gcc] should we teach gcc some new tricks?

[parisc-linux] [gcc] should we teach gcc some new tricks?

[Randolph Chung]

i've been looking at the extreme slowness of ext3 during some workloads.
came across this bit of code... not that it will make any difference,
but i wonder if we can make gcc a bit smarter?

given this bit of C code:

static inline int test_bit(int nr, const void * addr)
{
	const unsigned char *ADDR = (const unsigned char *) addr;
	return (ADDR[nr >> 3] >> (nr & 7)) & 1;
}

int proc1(int nr, int foo)
{
	int ret;
	char *buf1, *buf2;

	if (test_bit(nr, buf1))
		return 0;

	if (foo)
		ret = 1;
	else
		ret = !test_bit(nr, buf2);
	return ret;
}

int proc2(int nr, int foo)
{
	char *buf1, *buf2;

	if (test_bit(nr, buf1))
		return 0;

	if (foo)
		return 1;
	else
		return !test_bit(nr, buf2);
}

i would have expected gcc to produce the same code for proc1() and
proc2() (and in fact it does for 32-bit), but for 64-bit, proc2() is 2
insn shorter than proc1().  it seems like there are also some
opportunities for further optimizations if gcc can recognize that the
return value can only be 0 or 1, so the sign extension (?) extrd insn at
the end is not needed, and we can deposit the result directly into ret0
instead of r20. that should save us 2 insns.

.globl proc2
	.type	proc2, @function
proc2:
	.PROC
	.CALLINFO FRAME=0,NO_CALLS
	.ENTRY
	extrd,s %r26,63,32,%r26
	extrw,u %r26,31,3,%r19
	extrd,s %r25,63,32,%r25
	mtsarcm %r19
	extrd,s %r26,60,61,%r26
	ldb %r26(%r20),%r19
	extrw,s %r19,%sar,32,%r19
	bb,*< %r19,63,.L10
	ldi 0,%r28
	ldi 1,%r28
	cmpb,*<> %r0,%r25,.L10
	ldi 0,%r20
	ldb %r26(%r21),%r19
	extrw,s %r19,%sar,32,%r19
	extrd,s,*< %r19,63,1,%r0
	ldi 1,%r20
	extrd,s %r20,63,32,%r28
.L10:
	bve,n (%r2)
	.EXIT
	.PROCEND

is this worth looking into? :)
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[James A. Morrison]

Randolph Chung <randolph@tausq.org> writes:

> i've been looking at the extreme slowness of ext3 during some workloads.
> came across this bit of code... not that it will make any difference,
> but i wonder if we can make gcc a bit smarter?
> 
> given this bit of C code:
> 
> static inline int test_bit(int nr, const void * addr)
> {
> 	const unsigned char *ADDR = (const unsigned char *) addr;
> 	return (ADDR[nr >> 3] >> (nr & 7)) & 1;
> }
> 
> int proc1(int nr, int foo)
> {
> 	int ret;
> 	char *buf1, *buf2;
> 
> 	if (test_bit(nr, buf1))
> 		return 0;
> 
> 	if (foo)
> 		ret = 1;
> 	else
> 		ret = !test_bit(nr, buf2);
> 	return ret;
> }
> 
> int proc2(int nr, int foo)
> {
> 	char *buf1, *buf2;
> 
> 	if (test_bit(nr, buf1))
> 		return 0;
> 
> 	if (foo)
> 		return 1;
> 	else
> 		return !test_bit(nr, buf2);
> }
> 

 GCC 4 already produces the same code for these functions*.  Attached is the
final_cleanup dumb of an O2 build of this file.

 * I only checked that the assembly was the exact same on ia64, but the
tree dumps only differ in the names of the ret variable.

-- 
Thanks,
Jim

http://www.student.cs.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim

;; Function proc1 (proc1)

proc1 (nr, foo)
{
  int D.1253;
  const unsigned char * D.1249;
  char * buf2;
  char * buf1;
  int ret;

<bb 0>:
  D.1249 = (const unsigned char *) (long unsigned int) (nr >> 3);
  D.1253 = nr & 7;
  if (((int) *((const unsigned char *) buf1 + D.1249) >> D.1253 & 1) != 0) goto <L10>; else goto <L2>;

<L10>:;
  ret = 0;
  goto <bb 5> (<L7>);

<L2>:;
  if (foo != 0) goto <L11>; else goto <L4>;

<L11>:;
  ret = 1;
  goto <bb 5> (<L7>);

<L4>:;
  ret = ((int) *(D.1249 + (const unsigned char *) buf2) >> D.1253 & 1) == 0;

<L7>:;
  return ret;

}



;; Function proc2 (proc2)

proc2 (nr, foo)
{
  int D.1291;
  const unsigned char * D.1287;
  char * buf2;
  char * buf1;
  int D.1239;

<bb 0>:
  D.1287 = (const unsigned char *) (long unsigned int) (nr >> 3);
  D.1291 = nr & 7;
  if (((int) *((const unsigned char *) buf1 + D.1287) >> D.1291 & 1) != 0) goto <L9>; else goto <L2>;

<L9>:;
  D.1239 = 0;
  goto <bb 5> (<L6>);

<L2>:;
  if (foo != 0) goto <L10>; else goto <L4>;

<L10>:;
  D.1239 = 1;
  goto <bb 5> (<L6>);

<L4>:;
  D.1239 = ((int) *(D.1287 + (const unsigned char *) buf2) >> D.1291 & 1) == 0;

<L6>:;
  return D.1239;

}


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

>  GCC 4 already produces the same code for these functions*.  Attached is the
> final_cleanup dumb of an O2 build of this file.

My impression is that GCC 4 is doing a better job with 64-bit code
than previous versions although I haven't run any benchmarks.  It
could be as much as a 10% improvement in performance on average.
However, 64-bit code is still slower than 32-bit code.

>>From a PA standpoint, GCC 4 is ready for serious testing.  All testsuite
bugs have been squashed in C and C++.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Grant Grundler]

On Thu, Mar 24, 2005 at 11:19:28AM -0500, John David Anglin wrote:
...
> From a PA standpoint, GCC 4 is ready for serious testing.  All testsuite
> bugs have been squashed in C and C++.

Is there a .deb or tarball available I can drop on a bunch of machines?

I'd be happy to test for kernel builds.

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> On Thu, Mar 24, 2005 at 11:19:28AM -0500, John David Anglin wrote:
> ...
> > From a PA standpoint, GCC 4 is ready for serious testing.  All testsuite
> > bugs have been squashed in C and C++.
> 
> Is there a .deb or tarball available I can drop on a bunch of machines?

There is a recent build in /home/dave/opt/gnu/gcc/gcc-4.0.0 on gsyprf11.
Unfortunately, it was built using --with-as= and --with-ld=, so it isn't
very portable.  I could do a build with the system's as and ld that
would be more portable.  I'm not setup to generate a .deb that would
be system installable.

You are welcome to try the version in /home/dave/opt/gnu/gcc/gcc-4.0.0.
It's easily turned into a tarball.

> I'd be happy to test for kernel builds.

That would provide useful.  In the past, there usually have been new
features or deprecated features that have caused problems.  4.0 has a
new option, -mfixed_range=, that was introduced so that a small range
of fp registers could be used for the xmpyu multiplication insn.  It
might be useful to experiment with this option to see if it useful.
This was borrowed from ia64.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[James A. Morrison]

Grant Grundler <grundler@parisc-linux.org> writes:

> On Thu, Mar 24, 2005 at 11:19:28AM -0500, John David Anglin wrote:
> ...
> > From a PA standpoint, GCC 4 is ready for serious testing.  All testsuite
> > bugs have been squashed in C and C++.
> 
> Is there a .deb or tarball available I can drop on a bunch of machines?
> 
> I'd be happy to test for kernel builds.
> 
> thanks,
> grant
> 

 Try the gcc-snapshot package.

-- 
Thanks,
Jim

http://www.student.cs.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Grant Grundler]

On Thu, Mar 24, 2005 at 12:35:09PM -0500, John David Anglin wrote:
> > On Thu, Mar 24, 2005 at 11:19:28AM -0500, John David Anglin wrote:
> > ...
> > > From a PA standpoint, GCC 4 is ready for serious testing.  All testsuite
> > > bugs have been squashed in C and C++.
> > 
> > Is there a .deb or tarball available I can drop on a bunch of machines?
> 
> There is a recent build in /home/dave/opt/gnu/gcc/gcc-4.0.0 on gsyprf11.

Randolph Chung pointed to another gcc-4.0 build on gsyprf7.
That's fine for me...but several other people would probably want to
try this out on other machines.  And I like to make use of distcc.
gcc-4.0 must be in the same place on several machines for distcc to work.

> Unfortunately, it was built using --with-as= and --with-ld=, so it isn't
> very portable.  I could do a build with the system's as and ld that
> would be more portable.  I'm not setup to generate a .deb that would
> be system installable.

A tarball will do for now. Let someone good at debian packaging
worry about that bit.
My preference is the tarball use directory names/places like
existing gcc-3.x versions do:

grundler@gsyprf11:~$ ls /usr/bin/*3.4
/usr/bin/cpp-3.4*     /usr/bin/hppa-linux-cpp-3.4@
/usr/bin/g++-3.4*     /usr/bin/hppa-linux-g++-3.4@
/usr/bin/gcc-3.4*     /usr/bin/hppa-linux-gcc-3.4@
/usr/bin/gccbug-3.4*  /usr/bin/hppa64-linux-cpp-3.4*
/usr/bin/gcov-3.4*    /usr/bin/hppa64-linux-gcc-3.4*

grundler@gsyprf11:~$ ls /usr/lib/gcc*/hppa*-linux/
/usr/lib/gcc-lib/hppa-linux/:
3.0.4/  3.3.5/

/usr/lib/gcc-lib/hppa64-linux/:
3.0.4/  3.3.3/  3.3.5/

/usr/lib/gcc/hppa-linux/:
3.4.4/

/usr/lib/gcc/hppa64-linux/:
3.4.4/

My assumption is a gcc-4.0 tarball won't clobber any existing files.
So if that's not possible with the above locations, /opt/gnu
would be fine too.


> You are welcome to try the version in /home/dave/opt/gnu/gcc/gcc-4.0.0.

Ok - I will over the next couple of days.

> It's easily turned into a tarball.

BTW, you can host the tarball on http://gsyprf11.e.h.c/~dave/.
Just "mkdir ~/public_html" and start dropping stuff in there.
Alternate URL is http://iou.parisc-linux.org/~dave/

Please advertise where/when a suitable one is available.

> > I'd be happy to test for kernel builds.
> 
> That would provide useful.  In the past, there usually have been new
> features or deprecated features that have caused problems.

ok

> 4.0 has a
> new option, -mfixed_range=, that was introduced so that a small range
> of fp registers could be used for the xmpyu multiplication insn.  It
> might be useful to experiment with this option to see if it useful.

I don't know enough about ABI to understand the issues here.
AFAIK, we currently are using FP registers because that's
the way multiplication is implemented in the integer math libs
we inherited.

> This was borrowed from ia64.

*nod*. I expect hppa can benefit for the same reasons: hppa has
quite a few FP regs and some things FP can just do alot faster.
I just don't know what "some things" consists of.

thanks,
grant

> 
> Dave
> -- 
> J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
> National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Grant Grundler]

On Thu, Mar 24, 2005 at 02:37:46PM -0500, James A. Morrison wrote:
> > Is there a .deb or tarball available I can drop on a bunch of machines?
> 
>  Try the gcc-snapshot package.

Ah..."unstable" package:
	g/gcc-snapshot/gcc-snapshot_20050319-1.diff.gz
	g/gcc-snapshot/gcc-snapshot_20050319-1.dsc
	g/gcc-snapshot/gcc-snapshot_20050319-1_i386.deb
	g/gcc-snapshot/gcc-snapshot_20050319-1_ia64.deb
	g/gcc-snapshot/gcc-snapshot_20050319-1_mipsel.deb
	g/gcc-snapshot/gcc-snapshot_20050319-1_powerpc.deb
	g/gcc-snapshot/gcc-snapshot_20050319-1_s390.deb
	g/gcc-snapshot/gcc-snapshot_20050319.orig.tar.gz

Hrm... looks like hppa didn't build in the last one.
Most recent one available is 
	g/gcc-snapshot/gcc-snapshot_20050212-1_hppa.deb


Thinking about it more, I'd rather have Dave reccomend a tarball
he knows the test results for and is comfortable with them.

thanks though,
grant

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Grant Grundler]

On Thu, Mar 24, 2005 at 04:33:46PM -0500, John David Anglin wrote:
> > > 4.0 has a
> > > new option, -mfixed_range=, that was introduced so that a small range
> > > of fp registers could be used for the xmpyu multiplication insn.  It
> > > might be useful to experiment with this option to see if it useful.
> > 
> > I don't know enough about ABI to understand the issues here.
> > AFAIK, we currently are using FP registers because that's
> > the way multiplication is implemented in the integer math libs
> > we inherited.
> 
> No.  Currently in kernel builds, the use of FP registers is completely
> disabled and integer multiplication is done using the millicode library.

Erm...objdump disagrees:
grundler <541>hppa64-linux-objdump -rD vmlinux | fgrep xmpy | wc
   1654   11578   82683

First occurance is here:
000000001010bca0 <__muldi3>:
    1010bca0:   37 de 00 80     ldo 40(sp),sp
    1010bca4:   db 56 07 e0     extrd,s r26,31,32,r22
    1010bca8:   73 d6 3f 91     std r22,-38(sp)
    1010bcac:   53 d6 3f 93     fldd -38(sp),fr22
    1010bcb0:   73 d9 3f 91     std r25,-38(sp)
    1010bcb4:   53 d7 3f 93     fldd -38(sp),fr23
    1010bcb8:   3a d7 57 96     xmpyu fr22R,fr23R,fr22
    1010bcbc:   d3 53 1b f0     extrw,u r26,31,16,r19
    1010bcc0:   73 d6 3f 93     fstd fr22,-38(sp)
    1010bcc4:   53 d6 3f 91     ldd -38(sp),r22
...

objdump output is on still on gsyprf11:/tmp/2.6.12-rc1-objdump
In case you want to browse it more.

> However with a few FP regs, integer multiplication (32 bit) can be
> done in hardware except of course on machines that don't have FP
> hardware.  The downside is that the kernel has to save whatever
> FP registers it uses.

Yeah, I thought that was happening already.
I'm hoping "save_fp         %r25" in arch/parisc/kernel/entry.S
takes care of that.

> The -mfixed_range= option "fixes" a range if registers.  GCC won't
> use registers that are fixed.

Yeah, it might make sense to "document" current usage
and limit which FP regs the kernel can use. Ie we
could reduce FP state that needs to be save when
entering the kernel. Context switch would need to save
the rest.

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> > No.  Currently in kernel builds, the use of FP registers is completely
> > disabled and integer multiplication is done using the millicode library.
> 
> Erm...objdump disagrees:
> grundler <541>hppa64-linux-objdump -rD vmlinux | fgrep xmpy | wc
>    1654   11578   82683
> 
> First occurance is here:
> 000000001010bca0 <__muldi3>:

Not good.  This is from libgcc.  I see that the muldi3 expander is
disabled when we disable FP regs.  I'm not sure why but it doesn't
seem right.  Using the expander, would cause the use of the millicode
routine when FP regs are disabled.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Randolph Chung]

> Not good.  This is from libgcc.  I see that the muldi3 expander is
> disabled when we disable FP regs.  I'm not sure why but it doesn't
> seem right.  Using the expander, would cause the use of the millicode
> routine when FP regs are disabled.

We *do not* disable fpregs in the kernel. We would like to though.

The problem is precisely libgcc - even if we compile the kernel with
--disable-fpregs, millicode calls generated by gcc will still use
fpregs. One proposal that has been talked about before is if we can
compile a version of the millicode lib that uses limited fpregs range
and compile the kernel using this new option that Dave is talking about,
then we will be able to get by using a (much) smaller subset of fp regs
and we won't have to save/restore them in the kernel.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Randolph Chung]

> We *do not* disable fpregs in the kernel. We would like to though.

I should add that in somewhat recent versions of the kernel, we actually
actively use fpregs in some of the kernel code. The "new" pa_memcpy code
uses fpregs to copy 8-bytes at a time on both 32-bit and 64-bit
machines.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> > Not good.  This is from libgcc.  I see that the muldi3 expander is
> > disabled when we disable FP regs.  I'm not sure why but it doesn't
> > seem right.  Using the expander, would cause the use of the millicode
> > routine when FP regs are disabled.
> 
> We *do not* disable fpregs in the kernel. We would like to though.
> 
> The problem is precisely libgcc - even if we compile the kernel with
> --disable-fpregs, millicode calls generated by gcc will still use
> fpregs. One proposal that has been talked about before is if we can
> compile a version of the millicode lib that uses limited fpregs range
> and compile the kernel using this new option that Dave is talking about,
> then we will be able to get by using a (much) smaller subset of fp regs
> and we won't have to save/restore them in the kernel.

The millicode routines don't use fpregs.  Various libgcc functions
will use them.  However, I think it's a backend bug that causes
__muldi3 to get pulled in when the kernel is linked.

The -mfixed-range option should allow you to reduce the set of used
fpregs but we need to be sure that the libgcc routines don't get used.
Otherwise, we would have to build libgcc with a reduce set of fpregs.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Matthias Klose]

Grant Grundler writes:
> On Thu, Mar 24, 2005 at 11:19:28AM -0500, John David Anglin wrote:
> ...
> > From a PA standpoint, GCC 4 is ready for serious testing.  All testsuite
> > bugs have been squashed in C and C++.
> 
> Is there a .deb or tarball available I can drop on a bunch of machines?

- gcc-snapshot can be found in unstable, although it was pointed out,
  it's not that recent (I can't upload this one every week without the
  risk beeing killed by buildd admins for slower architectures ;)

- You can get gcc-4.0 packages from experimental, just add
  deb http://http.us.debian.org/debian experimental main contrib
  to /etc/apt/sources.list.
  Provided that somebody is building and uploading these ...

Besides the recent gcc-snapshot build failure, I'm having problems
building the packages at all at the moment, there's no difference
using between sarge and unstable.

- if the build succeeds, every test case in the testsuite fails, due
  to expect(?) problems. lamont told me that's reproducible on another
  A500, seeing some messages on the serial console, but I can't see
  these messages. I'm currently running the A500 kernels from the
  parisc archives. palinux-a500-defconfig-2.6.{8.1-pa11,11-pa2,12-rc1-pa1}
  all show the same behaviour.

- The libjava build sometimes fails with an sh/bash error. Restarting
  the build usually fixes this.

- gnat doesn't build, even if you include some prebuilt files (which
  might be wrongly generated) from another build.

Besides these minor issues, the packages should be fine.

	Matthias
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

>   it's not that recent (I can't upload this one every week without the
>   risk beeing killed by buildd admins for slower architectures ;)
> 
> - You can get gcc-4.0 packages from experimental, just add
>   deb http://http.us.debian.org/debian experimental main contrib
>   to /etc/apt/sources.list.
>   Provided that somebody is building and uploading these ...
> 
> Besides the recent gcc-snapshot build failure, I'm having problems
> building the packages at all at the moment, there's no difference
> using between sarge and unstable.

I've had this problem from time to time, particularly on server
machines.  My c3k is solid and this doesn't happen.  For some reason,
the libjava build is most prone to the segfaults in sh/bash and
sometimes make.  Grant's recent builds on gsyprf11 seem to have
changed the nature of the faults.  Now, the kernel panics instead
of a segfault in sh.  Grant would know more as to what's causing
these crashes.

> - if the build succeeds, every test case in the testsuite fails, due
>   to expect(?) problems. lamont told me that's reproducible on another
>   A500, seeing some messages on the serial console, but I can't see
>   these messages. I'm currently running the A500 kernels from the
>   parisc archives. palinux-a500-defconfig-2.6.{8.1-pa11,11-pa2,12-rc1-pa1}
>   all show the same behaviour.

I think that there are issues with expect, tcl and dejagnu.

1) Dejagnu asks expect to trap SEGFAULTS.  This is undefined and results
   in the fault insn being executed repeatively.  It's a simple one line
   fix to remove this:

--- runtest.exp.orig    2004-08-25 16:10:38.000000000 -0400
+++ runtest.exp 2004-08-25 16:11:13.000000000 -0400
@@ -1503,8 +1503,7 @@
 if ![exp_debug] {
      foreach sig "{SIGTERM {terminated}} \
		    {SIGINT  {interrupted by user}} \
-             {SIGQUIT {interrupted by user}} \
-             {SIGSEGV {segmentation violation}}" {
+             {SIGQUIT {interrupted by user}}" {
	 set signal [lindex $sig 0]
	 set str [lindex $sig 1]
	 trap "send_error \"got a \[trap -name\] signal, $str \\n\"; log_and_exit;" $signal

   I've probably munged the diff doing a cut and paste.

2) There is some kind of timing issue with expect/tcl when a given
   test ends.  This causes expect to hang.  When this happens, you
   will see a defunct expect task.  It is a child of the expect task
   that is hung.

   Tcl 8.3 works better than 8.4.  I know they have changed some of
   the code in this area but I don't know why this happens.  I've also
   had this happen on x86 but pa seems much more prone to this problem.

   Tcl 8.3 also works better for tests that generate a lot of output.
   It is less likely to truncate the output resulting in a test failure.
   I think this has to do with the handling of pipes at exit.

3) A warning appears compiling expect in a couple of places regarding
   the second argument of waitpid.  It's always int.  However, expect
   thinks the type of this argument is WAIT_STATUS_TYPE.  This gets
   used when NO_UNION_WAIT isn't defined.  This problem can be worked
   around be adding "-ansi -D_SVID_SOURCE -D_POSIX_SOURCE" to CFLAGS.
   I had hoped that fixing this would resolve the expect hangs but it
   doesn't seem to help.  However, I do like a build without warnings.
   To get this with the above CFLAGS, a number of missing include
   directives need to be added.

   I use the following setup:

   dave@hiauly6:~/gnu/expect-5.43/objdir$ runtest --version
   WARNING: Couldn't find the global config file.
   Expect version is       5.43.0
   Tcl version is          8.3
   Framework version is    1.4.4

   I haven't seen any significant difference in behavior between
   5.42.1 and 5.43.0.  The former is the debian patched source.

4) There is a exit timing issue in tcl 8.4.  I tried a patch from the
   tcl list that claimed to fix this but it didn't seem to fix either
   the hangs or the truncation problem.

> - The libjava build sometimes fails with an sh/bash error. Restarting
>   the build usually fixes this.

:(  I've been hoping that some of these issues are caused by the put_user
problem.

> - gnat doesn't build, even if you include some prebuilt files (which
>   might be wrongly generated) from another build.

I've been regularly building gnat, so I think that you may have a problem
with your prebuilt files.  There was an issue like this in going from
3.3 to 3.4.  If you are starting from 3.3, try starting from 3.4.

There is an issue with tasking.  I have a patch to enable tasking
in Ada.  However, even the simplest possible Ada program that uses
tasking hangs.  I haven't had a chance to look at it much but it
seems like that we may have a problem with signals and thread
support.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Grant Grundler]

On Sat, Mar 26, 2005 at 10:48:06AM -0500, John David Anglin wrote:
> I've had this problem from time to time, particularly on server
> machines.  My c3k is solid and this doesn't happen.  For some reason,
> the libjava build is most prone to the segfaults in sh/bash and
> sometimes make.  Grant's recent builds on gsyprf11 seem to have
> changed the nature of the faults.

The Astro chipset IOC_CTRL register was being programmed differently
by each firmware. The workstation firmware was more conservative.
I've aligned the chipset programming and it seems to have helped
on the a500 with this change:
	http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2005-February/035337.html

>   Now, the kernel panics instead
> of a segfault in sh.  Grant would know more as to what's causing
> these crashes.

Yeah, we are still seeing this a few times per month too. :^(
I don't understand the copy_user_page_asm/do_dp_write data page fault.
But I'm no VM guru either. Randolph thinks the parameter regs look
valid in the tombstone.

> > - The libjava build sometimes fails with an sh/bash error. Restarting
> >   the build usually fixes this.
> 
> :(  I've been hoping that some of these issues are caused by the put_user
> problem.

The Astro change above should stabilize it a bit better.
Please try a 2.6.11-pa[34] (or later) kernel.

Similarly on pa8800, for kernel builds gcc/make/et al will segfault
and gcc sometimes claims internal errors.
It stinks like a chipset/cache coherency issue but I don't see it.
jejb isn't seeing any that might be related to VIVT cache either.

My suspicion is we still have a bug outstanding that is causing
register corruption - similar to the GR26 corruption you found
last December. I've written builds-tools/regtest.c to try
to capture the corruption from the user space side but
it's not working:
	http://cvs.parisc-linux.org/build-tools/regtest.c

I'd like to extend that test to also cover FP regs.
Maybe after debugging ext2_find_next_zero and debugging
why mpt (u320 SCSI) HPMCs on module load.

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> filed http://bugs.debian.org/301577 (although most of the discussion
> isn't in the report).

That should be http://bugs.debian.org/301557.  Daniel thought this
bug should be reassigned to expect.  On the other hand, dejagnu maybe
expecting too much of expect.

> with /bin/dash as shell and expect-tcl8.3 as expect version, the build
> and check succeeded. Test results at
> 
>   http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01933.html

FAIL: g++.old-deja/g++.warn/compare1.C  (test for warnings, line 11)
FAIL: g++.old-deja/g++.warn/compare1.C  (test for warnings, line 24)
FAIL: g++.old-deja/g++.warn/compare1.C (test for excess errors)
FAIL: gcc.c-torture/compile/20011119-2.c  -O1  (test for excess errors)

These are now fixed.

FAIL: thread/pthread7-rope.cc execution test

I don't see this in my testing.  On the other hand, the java failures
appear to be related to pthread support, so I think it likely that
we have one or more pthread bugs.  The java failures vary from one
run to another.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Michael S. Zick]

On Thu March 31 2005 01:57, Matthias Klose wrote:
> 
> Using /bin/dash as the shell for the build seems to avoid these
> problems, I'll bash the Debian bash maintainer ... ;)
> 
Query - Which version of bash? 2.05b or 3.0?

Bash 3.0 has a lot of internal changes, this may
already be fixed.

Mike
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

Hello Dave,

John David Anglin wrote:
[snip]
>>Besides the recent gcc-snapshot build failure, I'm having problems
>>building the packages at all at the moment, there's no difference
>>using between sarge and unstable.
> 
I am trying now the new debian dpkg sources gcc-4.0

> 
> I've had this problem from time to time, particularly on server
> machines.  My c3k is solid and this doesn't happen.  For some reason,
> the libjava build is most prone to the segfaults in sh/bash and
> sometimes make.  Grant's recent builds on gsyprf11 seem to have
> changed the nature of the faults.  Now, the kernel panics instead
> of a segfault in sh.  Grant would know more as to what's causing
> these crashes.
>
I am using a sister system a b2k with a 2.6.12-rc2-pa1 64bit (more stable then the 32bit)
and an unstable debian install.

> 
>>- if the build succeeds, every test case in the testsuite fails, due
>>  to expect(?) problems. lamont told me that's reproducible on another
>>  A500, seeing some messages on the serial console, but I can't see
>>  these messages. I'm currently running the A500 kernels from the
>>  parisc archives. palinux-a500-defconfig-2.6.{8.1-pa11,11-pa2,12-rc1-pa1}
>>  all show the same behaviour.
>
but I unfortunately encounter also an expect pb (hanging):
# ps -ef
[snip]
root     11231 11228  9 17:08 pts/1    00:13:36 expect -- /usr/share/dejagnu/runtest.exp --tool gcc
root     11251 11231  0 17:08 pts/1    00:00:01 [expect] <defunct>
root     13466  1414  0 18:53 ?        00:00:00 sshd: jso [priv]
root     13478 13466  0 18:53 ?        00:00:00 sshd: jso [priv]
jso      13584 13466  0 18:53 ?        00:00:00 sshd: jso@pts/5
jso      13587 13584  0 18:53 pts/5    00:00:00 -bash
root     13695 13587  0 18:53 pts/5    00:00:00 -su
root     14056 11231  0 18:54 pts/1    00:00:00 [20020220-1.exe] <defunct>
root     14057 11231  0 18:54 pts/1    00:00:00 [cat] <defunct>
root     14226 10073  0 19:34 pts/1    00:00:00 sleep 30
root     14227 13695  0 19:34 pts/5    00:00:00 ps -ef

# pstree 11228
expect --- [20020220-1.exe]
          + [cat]
          + [expect]

and the console showing me:
       -------------------------------
              \   ^__^
               \  (xx)\_______
                  (__)\       )\/\
                   U  ||----w |
                      ||     ||
expect (pid 11251): Protection id trap (code 27)

      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000001101111111100001111 Not tainted
r00-03  0000000000000000 000000001046a030 00000000101b21ec 000000001fdafb00
r04-07  00000000105c4ce0 0000000000000000 000000000002e4f8 0000000000000001
r08-11  0000000000000000 000000000002e500 00000000000001fe 000000001fdafb00
r12-15  fffffffffffffff2 0000000000000000 00000000000aa000 00000000000f2f08
r16-19  0000000000000000 00000000000f2a88 0000000000000001 000000001f3ec000
r20-23  0000000000000001 0000000000000000 000000000002e4fe 000000001fdafb1a
r24-27  0000000000000000 0000000000000001 000000001b3dac80 00000000105c4ce0
r28-31  0000000000000000 000000001f3ec3c0 000000001f3ec270 0000000000000000
sr0-3   0000000000bc8800 0000000000000000 0000000000000000 0000000000bc8800
sr4-7   0000000000000000 0000000000000000 0000000000000000 0000000000000000

IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000101b22e4 00000000101b22e8
  IIR: 0ed5d240    ISR: 0000000000bc8800  IOR: 000000000002e4fe
  CPU:        0   CR30: 000000001f3ec000 CR31: 0000000010584000
  ORIG_R28: 000000001010e400
  IAOQ[0]: sys_poll+0x274/0x298
  IAOQ[1]: sys_poll+0x278/0x298
  RP(r2): sys_poll+0x17c/0x298

  # disasm 0ed5d240
    0:   0e d5 d2 40     sth r21,0(sr3,r22)

as r22 ended by E, the privilege of this address would be 2 (the last 2 bits?)

> 
> I think that there are issues with expect, tcl and dejagnu.
> 
> 1) Dejagnu asks expect to trap SEGFAULTS.  This is undefined and results
>    in the fault insn being executed repeatively.  It's a simple one line
>    fix to remove this:
> 
> --- runtest.exp.orig    2004-08-25 16:10:38.000000000 -0400
> +++ runtest.exp 2004-08-25 16:11:13.000000000 -0400
> @@ -1503,8 +1503,7 @@
>  if ![exp_debug] {
>       foreach sig "{SIGTERM {terminated}} \
> 		    {SIGINT  {interrupted by user}} \
> -             {SIGQUIT {interrupted by user}} \
> -             {SIGSEGV {segmentation violation}}" {
> +             {SIGQUIT {interrupted by user}}" {
> 	 set signal [lindex $sig 0]
> 	 set str [lindex $sig 1]
> 	 trap "send_error \"got a \[trap -name\] signal, $str \\n\"; log_and_exit;" $signal
> 
>    I've probably munged the diff doing a cut and paste.
> 
Even thought I applied this patch

> 2) There is some kind of timing issue with expect/tcl when a given
>    test ends.  This causes expect to hang.  When this happens, you
>    will see a defunct expect task.  It is a child of the expect task
>    that is hung.
> 
Exactely the one which try to access an address without having enough privilege (if i well understand?)

>    Tcl 8.3 works better than 8.4.  I know they have changed some of
>    the code in this area but I don't know why this happens.  I've also
>    had this happen on x86 but pa seems much more prone to this problem.
> 
>    Tcl 8.3 also works better for tests that generate a lot of output.
>    It is less likely to truncate the output resulting in a test failure.
>    I think this has to do with the handling of pipes at exit.
> 
Well I just rediscover this kind comments, so still have to test this and the rest

> 3) A warning appears compiling expect in a couple of places regarding
>    the second argument of waitpid.  It's always int.  However, expect
>    thinks the type of this argument is WAIT_STATUS_TYPE.  This gets
>    used when NO_UNION_WAIT isn't defined.  This problem can be worked
>    around be adding "-ansi -D_SVID_SOURCE -D_POSIX_SOURCE" to CFLAGS.
>    I had hoped that fixing this would resolve the expect hangs but it
>    doesn't seem to help.  However, I do like a build without warnings.
>    To get this with the above CFLAGS, a number of missing include
>    directives need to be added.
> 
>    I use the following setup:
> 
>    dave@hiauly6:~/gnu/expect-5.43/objdir$ runtest --version
>    WARNING: Couldn't find the global config file.
>    Expect version is       5.43.0
>    Tcl version is          8.3
>    Framework version is    1.4.4
> 
>    I haven't seen any significant difference in behavior between
>    5.42.1 and 5.43.0.  The former is the debian patched source.
> 
> 4) There is a exit timing issue in tcl 8.4.  I tried a patch from the
>    tcl list that claimed to fix this but it didn't seem to fix either
>    the hangs or the truncation problem.
> 
> 
Thanks a lot,
	Joel

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> and the console showing me:
>        -------------------------------
>               \   ^__^
>                \  (xx)\_______
>                   (__)\       )\/\
>                    U  ||----w |
>                       ||     ||
> expect (pid 11251): Protection id trap (code 27)
> 
>       YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00001000000001101111111100001111 Not tainted
> r00-03  0000000000000000 000000001046a030 00000000101b21ec 000000001fdafb00
> r04-07  00000000105c4ce0 0000000000000000 000000000002e4f8 0000000000000001
> r08-11  0000000000000000 000000000002e500 00000000000001fe 000000001fdafb00
> r12-15  fffffffffffffff2 0000000000000000 00000000000aa000 00000000000f2f08
> r16-19  0000000000000000 00000000000f2a88 0000000000000001 000000001f3ec000
> r20-23  0000000000000001 0000000000000000 000000000002e4fe 000000001fdafb1a
> r24-27  0000000000000000 0000000000000001 000000001b3dac80 00000000105c4ce0
> r28-31  0000000000000000 000000001f3ec3c0 000000001f3ec270 0000000000000000
> sr0-3   0000000000bc8800 0000000000000000 0000000000000000 0000000000bc8800
> sr4-7   0000000000000000 0000000000000000 0000000000000000 0000000000000000
> 
> IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000101b22e4 00000000101b22e8
>   IIR: 0ed5d240    ISR: 0000000000bc8800  IOR: 000000000002e4fe
>   CPU:        0   CR30: 000000001f3ec000 CR31: 0000000010584000
>   ORIG_R28: 000000001010e400
>   IAOQ[0]: sys_poll+0x274/0x298
>   IAOQ[1]: sys_poll+0x278/0x298
>   RP(r2): sys_poll+0x17c/0x298
> 
>   # disasm 0ed5d240
>     0:   0e d5 d2 40     sth r21,0(sr3,r22)

Where did this address come from?  IAOQ[0] = 0x101b22e4.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> > sr0-3   0000000000bc8800 0000000000000000 0000000000000000 0000000000bc8800
> > sr4-7   0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > 
> > IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000101b22e4 00000000101b22e8
> >   IIR: 0ed5d240    ISR: 0000000000bc8800  IOR: 000000000002e4fe
> >   CPU:        0   CR30: 000000001f3ec000 CR31: 0000000010584000
> >   ORIG_R28: 000000001010e400
> >   IAOQ[0]: sys_poll+0x274/0x298
> >   IAOQ[1]: sys_poll+0x278/0x298
> >   RP(r2): sys_poll+0x17c/0x298
> > 
> >   # disasm 0ed5d240
> >     0:   0e d5 d2 40     sth r21,0(sr3,r22)
> 
> Where did this address come from?  IAOQ[0] = 0x101b22e4.

Sorry, this is the faulting instruction.  However, this isn't much help.
This isn't GCC code (GCC doesn't generate code using sr3).  It's part of
a syscall asm.  The value in sr3 seems wierd.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> > >   IAOQ[0]: sys_poll+0x274/0x298
> > >   IAOQ[1]: sys_poll+0x278/0x298
> > >   RP(r2): sys_poll+0x17c/0x298
> > > 
> > >   # disasm 0ed5d240
> > >     0:   0e d5 d2 40     sth r21,0(sr3,r22)
> > 
> > Where did this address come from?  IAOQ[0] = 0x101b22e4.
> 
> Sorry, this is the faulting instruction.  However, this isn't much help.
> This isn't GCC code (GCC doesn't generate code using sr3).  It's part of
> a syscall asm.  The value in sr3 seems wierd.

The problem code is in fs/select.c:

                for (j=0; j < walk->len; j++, ufds++) {
			if(__put_user(fds[j].revents, &ufds->revents))
				goto out_fds;
		}

The sth is in the __put_user code.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

> > > The problem code is in fs/select.c:
> > > 
> > >                 for (j=3D0; j < walk->len; j++, ufds++) {
> > > 			if(__put_user(fds[j].revents, &ufds->revents))
> > > 				goto out_fds;
> > > 		}
> > > 
> > > The sth is in the __put_user code.
> > > 
> > Ah I see, just need to recover your lastest patch as basic work (I tr=
usted
> > that I laready tested it here at the office, but no trace: may be on
the
> > system n4k down for now :-( )
> 
> No, I don't believe it will fix the problem as it doesn't affect
> the transfer of shorts.
> 
> It's not clear why the insn is causing a protection fault.  A bad
> pointer could of been passed to the kernel, or the kernel has done
> something bad.
> 
Thanks.

Btw, I reach to install gcc-4.0-pre9 experimental pre-build dpkg and comp=
ile
kernel ;-)
unfortunately:
# grep canon vmlinux-gcc4.dmp
10111a68 <__canonicalize_funcptr_for_compare>:
101271d4:       eb f5 b1 19     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101271e4:       eb f5 b0 f9     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10127230:       eb f5 b0 61     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10127240:       eb f5 b0 41     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10128c7c:       eb f4 bb c9     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10128c88:       eb f4 bb b1     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1013380c:       eb ef a4 a9     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10133818:       eb ef a4 91     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101347e8:       eb ee a4 f5     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101347f4:       eb ee a4 dd     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101349bc:       eb ee a1 4d     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101349c8:       eb ee a1 35     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1013580c:       eb ee a4 a9     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10135818:       eb ee a4 91     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10135afc:       eb ed be cd     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10135b08:       eb ed be b5     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10135c20:       eb ed bc 85     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10135c2c:       eb ed bc 6d     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10136ea4:       eb ed b7 79     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10136eb0:       eb ed b7 61     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101374bc:       eb ed ab 49     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101374c8:       eb ed ab 31     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101374e8:       eb ed aa f1     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101374f4:       eb ed aa d9     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1013e5d0:       eb e9 a9 25     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1013e5dc:       eb e9 a9 0d     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1013e7ac:       eb e9 a5 6d     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1013e7b8:       eb e9 a5 55     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10169554:       eb d4 aa 19     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10169564:       eb d4 a9 f9     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101a2584:       eb b7 a9 bd     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
101a2590:       eb b7 a9 a5     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1020ad2c:       eb 83 ba 69     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1020ad3c:       eb 83 ba 49     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102217cc:       eb 78 a5 29     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102217dc:       eb 78 a5 09     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1022183c:       eb 78 a4 49     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1022184c:       eb 78 a4 29     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10230c28:       eb 70 bc 71     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10230c34:       eb 70 bc 59     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1023199c:       eb 70 a1 89     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102319a8:       eb 70 a1 71     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102319d0:       eb 70 a1 21     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102319dc:       eb 70 a1 09     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10232858:       eb 6f a4 15     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10232868:       eb 6f a3 f5     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10234e10:       eb 6e b8 a1     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10234e1c:       eb 6e b8 89     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10235354:       eb 6e ae 19     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10235364:       eb 6e ad f9     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10236958:       eb 6d a2 15     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10236968:       eb 6d a1 f5     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10255900:       eb 5e a2 c1     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10255910:       eb 5e a2 a1     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10255960:       eb 5e a2 01     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10255970:       eb 5e a1 e1     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10267860:       eb 55 a4 01     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10267870:       eb 55 a3 e1     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1028e64c:       eb 41 a8 2d     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1028e65c:       eb 41 a8 0d     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10294760:       eb 3e a6 05     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10294770:       eb 3e a5 e5     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1029718c:       eb 3d b1 a9     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
1029719c:       eb 3d b1 89     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102c53c4:       eb 26 ad 39     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102c53d0:       eb 26 ad 21     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102ed42c:       eb 12 ac 69     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102ed438:       eb 12 ac 51     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102f3ab8:       eb 0e bf 55     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
102f3ac8:       eb 0e bf 35     b,l 10111a68 <__canonicalize_funcptr_for_=
compare>,%r2
10380978 <__ksymtab___canonicalize_funcptr_for_compare>:
1038542c <__kstrtab___canonicalize_funcptr_for_compare>:

this one doesn't seems to help me to get rid of those call __canonicalize=
_funcptr_for_compare().

Do you think that gcc-4.0 final release will help more?

Thanks,
    Joel


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> 102f3ac8:       eb 0e bf 35     b,l 10111a68 <__canonicalize_funcptr_for_compare>,%r2
> 10380978 <__ksymtab___canonicalize_funcptr_for_compare>:
> 1038542c <__kstrtab___canonicalize_funcptr_for_compare>:
> 
> this one doesn't seems to help me to get rid of those call __canonicalize_funcptr_for_compare().

The only way to get rid of the calls is to not compare function pointers ;)

> Do you think that gcc-4.0 final release will help more?

No.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

Hello Dave,

Come back to expect pb:
	o I just grab dpkg src and while I rebuild it localy I noticed that:
./configure [snip] --enable-threads
[snip]
checking for building with threads... configure: WARNING: Expect is not fully thread-enabled.  Although significant work has been 
done towards that goal, it is not complete.  Continue compiling at your own risk.
no (default)
[snip]
	? do you also used this '--enable-threads' options

	o I also grab the latest 5.43.0 release and btw lfs recommended the patch: expect-5.43.0-spawn-1.patch
	  <http://lfs-matrix.net/lfs/view/development/chapter05/expect.html>
	? do you already test it?

Thanks,
	Joel

John David Anglin wrote:
>>>>  IAOQ[0]: sys_poll+0x274/0x298
>>>>  IAOQ[1]: sys_poll+0x278/0x298
>>>>  RP(r2): sys_poll+0x17c/0x298
>>>>
>>>>  # disasm 0ed5d240
>>>>    0:   0e d5 d2 40     sth r21,0(sr3,r22)
>>>
>>>Where did this address come from?  IAOQ[0] = 0x101b22e4.
>>
>>Sorry, this is the faulting instruction.  However, this isn't much help.
>>This isn't GCC code (GCC doesn't generate code using sr3).  It's part of
>>a syscall asm.  The value in sr3 seems wierd.
> 
> 
> The problem code is in fs/select.c:
> 
>                 for (j=0; j < walk->len; j++, ufds++) {
> 			if(__put_user(fds[j].revents, &ufds->revents))
> 				goto out_fds;
> 		}
> 
> The sth is in the __put_user code.
> 
> Dave
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> Come back to expect pb:
> 	o I just grab dpkg src and while I rebuild it localy I noticed that:
> ./configure [snip] --enable-threads
> [snip]
> checking for building with threads... configure: WARNING: Expect is not fully thread-enabled.  Although significant work has been 
> done towards that goal, it is not complete.  Continue compiling at your own risk.

I don't configure it using --enable-threads.  I've been using something
like this:

# ../configure  --prefix=/home/dave/opt/gnu --host=hppa-linux --build=hppa-linux --with-tcl=/usr/lib/tcl8.3 --with-tk=/usr/lib/tk8.3 --with-tk=/usr/lib/tk8.3 --with-tclinclude=/usr/include/tcl8.3/tcl-private --with-tkinclude=/usr/include/tcl8.3/tk-private

I used the following CFLAGS:

CFLAGS = -O1 -g -ansi -D_SVID_SOURCE -D_POSIX_SOURCE

-ansi and the defines are because of the wait flag issue.

> 	o I also grab the latest 5.43.0 release and btw lfs recommended the patch: expect-5.43.0-spawn-1.patch
> 	  <http://lfs-matrix.net/lfs/view/development/chapter05/expect.html>
> 	? do you already test it?

I'm running 5.43.0 on one system.  I haven't tried the patch.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

John David Anglin wrote:
>>Come back to expect pb:
>>	o I just grab dpkg src and while I rebuild it localy I noticed that:
>>./configure [snip] --enable-threads
>>[snip]
>>checking for building with threads... configure: WARNING: Expect is not fully thread-enabled.  Although significant work has been 
>>done towards that goal, it is not complete.  Continue compiling at your own risk.
> 
> 
> I don't configure it using --enable-threads.  I've been using something
> like this:
> 
> # ../configure  --prefix=/home/dave/opt/gnu --host=hppa-linux --build=hppa-linux --with-tcl=/usr/lib/tcl8.3 --with-tk=/usr/lib/tk8.3 --with-tk=/usr/lib/tk8.3 --with-tclinclude=/usr/include/tcl8.3/tcl-private --with-tkinclude=/usr/include/tcl8.3/tk-private
> 
> I used the following CFLAGS:
> 
> CFLAGS = -O1 -g -ansi -D_SVID_SOURCE -D_POSIX_SOURCE
> 
> -ansi and the defines are because of the wait flag issue.
> 
Ok just rebuild my own dpkg with this interesting options ...

> 
>>	o I also grab the latest 5.43.0 release and btw lfs recommended the patch: expect-5.43.0-spawn-1.patch
>>	  <http://lfs-matrix.net/lfs/view/development/chapter05/expect.html>
>>	? do you already test it?
> 
> 
> I'm running 5.43.0 on one system.  I haven't tried the patch.
> 
and also with this patch

run autoexpect as simple test seems ok ;-)

I will try to rebuild gcc-4.0 dpkg now...

Thanks for advise,
	Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

Hello Dave,

John David Anglin wrote:
>>>4.0 has a
>>>new option, -mfixed_range=, that was introduced so that a small range
>>>of fp registers could be used for the xmpyu multiplication insn.  It
>>>might be useful to experiment with this option to see if it useful.
>>
>>I don't know enough about ABI to understand the issues here.
>>AFAIK, we currently are using FP registers because that's
>>the way multiplication is implemented in the integer math libs
>>we inherited.
> 
> 
> No.  Currently in kernel builds, the use of FP registers is completely
> disabled and integer multiplication is done using the millicode library.
> However with a few FP regs, integer multiplication (32 bit) can be
> done in hardware except of course on machines that don't have FP
> hardware.  The downside is that the kernel has to save whatever
> FP registers it uses.
> 
> The -mfixed_range= option "fixes" a range if registers.  GCC won't
> use registers that are fixed.
> 
Sorry to come back so late with this question but what would be the range of fp registers?
or how may I try to define it as accurately as possible?
(I objdump a operating 2.6.12-rc.-pa. 64bit to grep some 'fr[12][0..9]' and all of them seems to be used?
Do I have to look elsewhere; tausq also spoke about: sic
[...]One proposal that has been talked about before is if we can
compile a version of the millicode lib that uses limited fpregs range
and compile the kernel using this new option that Dave is talking about,
then we will be able to get by using a (much) smaller subset of fp regs
and we won't have to save/restore them in the kernel. )

Thanks,
     Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> Sorry to come back so late with this question but what would be the range of fp registers?
> or how may I try to define it as accurately as possible?
> (I objdump a operating 2.6.12-rc.-pa. 64bit to grep some 'fr[12][0..9]' and all of them seems to be used?
> Do I have to look elsewhere; tausq also spoke about: sic
> [...]One proposal that has been talked about before is if we can
> compile a version of the millicode lib that uses limited fpregs range
> and compile the kernel using this new option that Dave is talking about,
> then we will be able to get by using a (much) smaller subset of fp regs
> and we won't have to save/restore them in the kernel. )

/* Parse the -mfixed-range= option string.  */

static void
fix_range (const char *const_str)
{
  int i, first, last;
  char *str, *dash, *comma;

  /* str must be of the form REG1'-'REG2{,REG1'-'REG} where REG1 and
  REG2 are either register names or register numbers.  The effect
  of this option is to mark the registers in the range from REG1 to
  REG2 as ``fixed'' so they won't be used by the compiler.  This is
  used, e.g., to ensure that kernel mode code doesn't use f32-f127.  */

You are probably best to use register names.  There are 28 fp registers
starting at fr4.  The number for fr4 is 32.  I see there is a typo
in the comment regarding the range, "f32-f127".  This is a cut and
paste error.

The millicode routines don't use the fp regs.  However, libgcc does
and the kernel is linked against libgcc.  Thus, for this to work, you
will need to build both a kernel build version of gcc and the kernel
with the -mfixed-range option.  You probably want to leave about four
fp registers unfixed for integer multiplcation.  This is essential on
hppa64 as we don't have millicode support for 64-bit integer
multiplication.  This support is provided by libgcc routines.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Grant Grundler]

On Wed, Jun 22, 2005 at 07:54:54PM +0000, Joel Soete wrote:
> of fp registers?
> or how may I try to define it as accurately as possible?
> (I objdump a operating 2.6.12-rc.-pa. 64bit to grep some 'fr[12][0..9]' and 
> all of them seems to be used?

Of course they will all be used - kernel has to save and restore
process state when switching context. You have to look at each
use and determine why FP is being used. There shouldn't
be that many different uses.

> Do I have to look elsewhere; tausq also spoke about: sic
> [...]One proposal that has been talked about before is if we can
> compile a version of the millicode lib that uses limited fpregs range
> and compile the kernel using this new option that Dave is talking about,
> then we will be able to get by using a (much) smaller subset of fp regs
> and we won't have to save/restore them in the kernel. )

That's correct - but we will still have to save/restore all FP regs
on a general context switch - just a subset of those when
entering/leaving the kernel (e.g. handling an external interrupt).

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

> -- Original Message --
> Date: Wed, 22 Jun 2005 23:27:53 -0600
> From: Grant Grundler <grundler@parisc-linux.org>
> To: Joel Soete <soete.joel@tiscali.be>
> Cc: parisc-linux@lists.parisc-linux.org
> Subject: Re: [parisc-linux] [gcc] should we teach gcc some new tricks?
> 
> 
> On Wed, Jun 22, 2005 at 07:54:54PM +0000, Joel Soete wrote:
> > of fp registers?
> > or how may I try to define it as accurately as possible?
> > (I objdump a operating 2.6.12-rc.-pa. 64bit to grep some 'fr[12][0..9=
]'
> and 
> > all of them seems to be used?
> 
> Of course they will all be used - kernel has to save and restore
> process state when switching context.
Oops I missed it (my bad)

> You have to look at each
> use and determine why FP is being used. There shouldn't
> be that many different uses.
> 
Thanks for enlightenment,

I still have to make a lot of progress ;-)

> > Do I have to look elsewhere; tausq also spoke about: sic
> > [...]One proposal that has been talked about before is if we can
> > compile a version of the millicode lib that uses limited fpregs range=

> > and compile the kernel using this new option that Dave is talking abo=
ut,
> > then we will be able to get by using a (much) smaller subset of fp re=
gs
> > and we won't have to save/restore them in the kernel. )
> 
> That's correct - but we will still have to save/restore all FP regs
> on a general context switch - just a subset of those when
> entering/leaving the kernel (e.g. handling an external interrupt).
> 
Thanks,
    Joel


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

...
>
> /* Parse the -mfixed-range=3D option string.  */
>
> static void
> fix_range (const char *const_str)
> {
>   int i, first, last;
>   char *str, *dash, *comma;
>
>   /* str must be of the form REG1'-'REG2{,REG1'-'REG} where REG1 and
>   REG2 are either register names or register numbers.  The effect
>   of this option is to mark the registers in the range from REG1 to
>   REG2 as ``fixed'' so they won't be used by the compiler.  This is
>   used, e.g., to ensure that kernel mode code doesn't use f32-f127.  */=

>
That confirms well the gcc info description:
`-mfixed-range=3DREGISTER-RANGE'
      Generate code treating the given register range as fixed registers.=

      A fixed register is one that the register allocator can not use.
      This is useful when compiling kernel code. A register range is
      specified as two registers separated by a dash. Multiple register
      ranges can be specified separated by a comma.
 ;-)

> You are probably best to use register names.
I would prefer too.

> There are 28 fp registers
> starting at fr4.  The number for fr4 is 32.  I see there is a typo
> in the comment regarding the range, "f32-f127".  This is a cut and
> paste error.
>
Nice add on (tx),

> The millicode routines don't use the fp regs.  However, libgcc does
> and the kernel is linked against libgcc.  Thus, for this to work, you
> will need to build both a kernel build version of gcc and the kernel
> with the -mfixed-range option.  You probably want to leave about four
> fp registers unfixed for integer multiplcation.  This is essential on
> hppa64 as we don't have millicode support for 64-bit integer
> multiplication.  This support is provided by libgcc routines.
>
my main interest is still 32bit kernel  for the moment(the most of my sys=
tems
 b180,  c110, d380 ;-)):
2.6.8 ans 2.6.9-rc2-pa1 works fine when compiled with -mdisable-fpregs op=
tion
but panicing quickly whitout?

And effectively with -mdisable-fpregs option a function like <do_setitime=
r>
(amoung others) used __muldi3 as in:
[...]
1012b630:       e8 4b 01 61     b,l 101016e8 <__muldi3>,rp
[...]
1012b650:       e8 4b 01 21     b,l 101016e8 <__muldi3>,rp
1012b654:       08 03 02 5a     copy r3,r26
[...]

while without it obviously compile something like:
[...]
1012ba00:       27 88 10 16     fldw 4(,ret0),fr22
1012ba04:       30 00 40 16     fcpy,sgl fr0,fr22
1012ba08:       37 b6 1c 29     ldo -11ec(ret1),r22
1012ba0c:       22 bc 8d 1a     ldil 68db8000,r21
1012ba10:       27 c1 12 16     fstw fr22,-10(,sp)
1012ba14:       36 b8 17 5a     ldo bad(r21),r24
1012ba18:       34 01 1f fe     ldi fff,r1
1012ba1c:       34 02 3f ff     ldi -1,rp
1012ba20:       22 a6 22 06     ldil 1030d000,r21
1012ba24:       0f c1 10 93     ldw -10(,sp),r19
1012ba28:       36 b5 09 a0     ldo 4d0(r21),r21
1012ba2c:       2e a0 10 17     fldd 0(,r21),fr23
1012ba30:       d2 77 1c 1f     extrw,s r19,0,1,r23
1012ba34:       3a d7 57 17     xmpyu fr22,fr23R,fr23
1012ba38:       0b 17 02 17     and r23,r24,r23
1012ba3c:       2f c1 12 17     fstd fr23,-10(,sp)
[...]

But that doesn't make me yet understand what it could make as side effect=

versus
the 64bit twin kernel??

I still have to learn more ;-)

Thanks a lot,
    Joel


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> And effectively with -mdisable-fpregs option a function like <do_setitimer>
> (amoung others) used __muldi3 as in:
> [...]
> 1012b630:       e8 4b 01 61     b,l 101016e8 <__muldi3>,rp
> [...]
> 1012b650:       e8 4b 01 21     b,l 101016e8 <__muldi3>,rp
> 1012b654:       08 03 02 5a     copy r3,r26
> [...]

The same issue that I mentioned previously applies to -mdisable-fpregs.
__muldi3 and similar routines in libgcc use fp regs and the xmpyu for
64-bit multiplation.  It takes two 32-bit values and produces a 64-bit
result.  In millicode, we can multiple to 32 bit values and produce a
32-bit result.  This isn't sufficient to implement __muldi3.  GCC needs
a pattern to duplicate xmpyu using millicode.  This could be done by
"long" multiplication.  Break the 32-bit values into two 16-bit chunks
and use the millicode multiply.

HPUX has millicode routines to do larger multiplication but these
routines weren't released.

I'm a bit surprised that 32-bit kernels needs 64-bit multiplication.
Anyway, xmpyu is much more efficient for multiplication than software.
Possibly, I should look at using the -mfixed-range option when building
libgcc as a first step.  Looking at libgcc, I think it needs fr4, fr5
and fr22-fr26.  __mulvdi3 needs the most registers.  The argument
registers are needed for some floating point conversion routines.
I doubt the kernel uses these.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> mmm do I well understand that to force gcc to on;y use fr4-f5 and fr22-fr26
> (as do __muldi3), I had to use option:
> cflags-y        += -mfixed-range=fr6-fr21,fr27-fr28

Close, I used the change below.  This seems to build and check ok.
I don't know if it would be possible to cut back another register or not.
If I was going to try, I would add fr26 to the fixed list.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index: config/pa/pa.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/pa/pa.c,v
retrieving revision 1.294
diff -u -3 -p -r1.294 pa.c
--- config/pa/pa.c	23 Apr 2005 21:28:33 -0000	1.294
+++ config/pa/pa.c	24 Jun 2005 02:37:47 -0000
@@ -306,7 +306,7 @@ fix_range (const char *const_str)
      REG2 are either register names or register numbers.  The effect
      of this option is to mark the registers in the range from REG1 to
      REG2 as ``fixed'' so they won't be used by the compiler.  This is
-     used, e.g., to ensure that kernel mode code doesn't use f32-f127.  */
+     used, e.g., to ensure that kernel mode code doesn't use fr4-fr31.  */
 
   i = strlen (const_str);
   str = (char *) alloca (i + 1);
Index: config/pa/t-linux
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/pa/t-linux,v
retrieving revision 1.8
diff -u -3 -p -r1.8 t-linux
--- config/pa/t-linux	5 Dec 2002 01:57:27 -0000	1.8
+++ config/pa/t-linux	24 Jun 2005 02:37:47 -0000
@@ -6,7 +6,8 @@ LIB1ASMFUNCS = _divI _divU _remI _remU _
 LIB1ASMSRC = pa/milli64.S
 
 # Compile libgcc2.a as PIC.
-TARGET_LIBGCC2_CFLAGS = -fPIC -DELF=1 -DLINUX=1
+TARGET_LIBGCC2_CFLAGS = -fPIC -DELF=1 -DLINUX=1 \
+  -mfixed-range="fr6-fr21,fr27-fr31"
 
 LIB2FUNCS_EXTRA=fptr.c
 
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

John David Anglin wrote:
>>mmm do I well understand that to force gcc to on;y use fr4-f5 and fr22-fr26
>>(as do __muldi3), I had to use option:
>>cflags-y        += -mfixed-range=fr6-fr21,fr27-fr28
> 
> 
> Close, I used the change below.
mmm I definetely have to go back to elementary school (4 + 28 -1 = 31 and not 28, my bad !!!)

>  This seems to build and check ok.
Ok I will try to rebuild libgcc2 and kernel with same options.

Btw 2.6.12-pa1 already build and boot fine with above mentioned options.
Anyway still hanging after 44 min of stress test.

So imho 2 first thinks to do:
	o apply the right 'fixed-range' option
	o apply 2.6.12.1 patch

> I don't know if it would be possible to cut back another register or not.
> If I was going to try, I would add fr26 to the fixed list.
> 
If still not work, the 3rd test I will do ;-)

I will advise.

Thanks again,
     Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

Helo Dave and all,

Just a small update with some success ;-)

for remind:
(with gcc-3.3)
    o 2.6.9-rc2-pa1 with default compile option '-mdisable-fpregs' works
fine on my b180 (stress test ok)

    o the same 2.6.9-rc2-pa1 without this option (i.e. new default) crash=
ed
on stress test (about 2h test)
    o the later 2.6.9-rc2-pa13 (without '-mdisable-fpregs' by default) cr=
ashed
also.

good news with gcc-4.0 (debian pakage) and '-mfixed-range=3Dfr6-fr21,fr27=
-fr31'

    o 2.6.9-rc2-pa1 seems to works as fine as with original option
    o 2.6.9-rc2-pa13 the same 

(just have to backport some small stuff to  reach to compile kernels)

I apply my stress test (tar loops + kernel build loops) during a full day=

for each one without any pb ;-)

I can now try a step forward: 2.6.10-pa + gcc-4.0, ...

Thanks,
    Joel

> 
> 
> John David Anglin wrote:
> >>mmm do I well understand that to force gcc to on;y use fr4-f5 and fr2=
2-fr26
> >>(as do __muldi3), I had to use option:
> >>cflags-y        +=3D -mfixed-range=3Dfr6-fr21,fr27-fr28
> > 
> > 
> > Close, I used the change below.
> mmm I definetely have to go back to elementary school (4 + 28 -1 =3D 31=
 and
> not 28, my bad !!!)
> 
> >  This seems to build and check ok.
> Ok I will try to rebuild libgcc2 and kernel with same options.
> 
> Btw 2.6.12-pa1 already build and boot fine with above mentioned options=
.
> Anyway still hanging after 44 min of stress test.
> 
> So imho 2 first thinks to do:
> 	o apply the right 'fixed-range' option
> 	o apply 2.6.12.1 patch
> 
> > I don't know if it would be possible to cut back another register or
not.
> > If I was going to try, I would add fr26 to the fixed list.
> > 
> If still not work, the 3rd test I will do ;-)
> 
> I will advise.
> 
> Thanks again,
>      Joel
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> > good news with gcc-4.0 (debian pakage) and '-mfixed-range=fr6-fr21,fr27-fr31'
> > 
> >     o 2.6.9-rc2-pa1 seems to works as fine as with original option
> >     o 2.6.9-rc2-pa13 the same 
> > 
> > (just have to backport some small stuff to  reach to compile kernels)
> > 
> > I apply my stress test (tar loops + kernel build loops) during a full day
> > for each one without any pb ;-)
> > 
> > I can now try a step forward: 2.6.10-pa + gcc-4.0, ...

I'll have to try a gcc-4.0 built kernel to see if it improves things
on the c3k.

Just a note, a patch to fix the function pointer canonicalization
issue that you and others noticed was installed Friday to the 4.0 branch,
and Saturday to the GCC head.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

Hello Dave,

> 
> > > good news with gcc-4.0 (debian pakage) and '-mfixed-range=3Dfr6-fr2=
1,fr27-fr31'
> > > 
> > >     o 2.6.9-rc2-pa1 seems to works as fine as with original option
> > >     o 2.6.9-rc2-pa13 the same 
> > > 
> > > (just have to backport some small stuff to  reach to compile kernel=
s)
> > > 
> > > I apply my stress test (tar loops + kernel build loops) during a fu=
ll
> day
> > > for each one without any pb ;-)
> > > 
> > > I can now try a step forward: 2.6.10-pa + gcc-4.0, ...
> 
> I'll have to try a gcc-4.0 built kernel to see if it improves things
> on the c3k.
> 
cool ;-)

btw for the 2.6.10-pa11 I had to apply those small backports:
diff -NaurX dontdiff linux-2.6.10-pa10-20050112/arch/parisc/Makefile linu=
x-2.6.10-pa10-20050112-gcc40/arch/parisc/Makefile
--- linux-2.6.10-pa10-20050112/arch/parisc/Makefile     2005-01-04 07:37:=
20.000000000
+0100
+++ linux-2.6.10-pa10-20050112-gcc40/arch/parisc/Makefile       2005-07-0=
1
17:30:00.000000000 +0200
@@ -44,6 +44,7 @@
 # If that gets optimized, we might need to disable the use of fpregs in
the
 # kernel.
 #cflags-y      +=3D -mdisable-fpregs
+cflags-y       +=3D -mfixed-range=3Dfr6-fr21,fr27-fr31
 
 # Without this, "ld -r" results in .text sections that are too big
 # (> 0x40000) for branches to reach stubs.
diff -NaurX dontdiff linux-2.6.10-pa10-20050112/drivers/eisa/Makefile lin=
ux-2.6.10-pa10-20050112-gcc40/drivers/eisa/Makefile
--- linux-2.6.10-pa10-20050112/drivers/eisa/Makefile    2003-09-08 23:42:=
02.000000000
+0200
+++ linux-2.6.10-pa10-20050112-gcc40/drivers/eisa/Makefile      2005-07-0=
1
18:12:25.000000000 +0200
@@ -1,8 +1,5 @@
 # Makefile for the Linux device tree
 
-# Being anal sometimes saves a crash/reboot cycle... ;-)
-EXTRA_CFLAGS    :=3D -Werror
-
 obj-$(CONFIG_EISA)             +=3D eisa-bus.o
 obj-${CONFIG_EISA_PCI_EISA}     +=3D pci_eisa.o
 
diff -NaurX dontdiff linux-2.6.10-pa10-20050112/include/linux/fb.h linux-=
2.6.10-pa10-20050112-gcc40/include/linux/fb.h
--- linux-2.6.10-pa10-20050112/include/linux/fb.h       2004-11-30 07:45:=
36.000000000
+0100
+++ linux-2.6.10-pa10-20050112-gcc40/include/linux/fb.h 2005-07-01 18:38:=
07.000000000
+0200
@@ -857,7 +857,6 @@
 
 /* drivers/video/modedb.c */
 #define VESA_MODEDB_SIZE 34
-extern const struct fb_videomode vesa_modes[];
 extern void fb_var_to_videomode(struct fb_videomode *mode,
                                struct fb_var_screeninfo *var);
 extern void fb_videomode_to_var(struct fb_var_screeninfo *var,
@@ -902,6 +901,8 @@
        u32 flag;
 };
 
+extern const struct fb_videomode vesa_modes[];
+
 struct fb_modelist {
        struct list_head list;
        struct fb_videomode mode;
=3D=3D=3D=3D<>=3D=3D=3D=3D

And eventualy:
diff -NaurX dontdiff linux-2.6.10-pa10-20050112/Makefile linux-2.6.10-pa1=
0-20050112-gcc40/Makefile
--- linux-2.6.10-pa10-20050112/Makefile 2005-01-10 12:00:43.000000000 +01=
00
+++ linux-2.6.10-pa10-20050112-gcc40/Makefile   2005-07-01 17:29:16.00000=
0000
+0200
@@ -201,7 +201,7 @@
          else if [ -x /bin/bash ]; then echo /bin/bash; \
          else echo sh; fi ; fi)
 
-HOSTCC         =3D gcc
+HOSTCC         =3D gcc-4.0
 HOSTCXX        =3D g++
 HOSTCFLAGS     =3D -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
 HOSTCXXFLAGS   =3D -O2
@@ -318,7 +318,7 @@
 
 AS             =3D $(CROSS_COMPILE)as
 LD             =3D $(CROSS_COMPILE)ld
-CC             =3D $(CROSS_COMPILE)gcc
+CC             =3D $(CROSS_COMPILE)gcc-4.0
 CPP            =3D $(CC) -E
 AR             =3D $(CROSS_COMPILE)ar
 NM             =3D $(CROSS_COMPILE)nm
=3D=3D=3D=3D<>=3D=3D=3D=3D

Still have to find back what should still have to be backported (as kyle
did for 2.6.8) for b2k ;-)

> Just a note, a patch to fix the function pointer canonicalization
> issue that you and others noticed was installed Friday to the 4.0 branc=
h,
> and Saturday to the GCC head.
> 
Thanks for feedback (I will try it asap),

    Joel


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]

Hello Dave and * pa,

I trust, it's already a good news:
# cat /proc/cpuinfo ; uname -a ; echo " "; uptime
processor       : 0
cpu family      : PA-RISC 1.1e
cpu             : PA7300LC (PCX-L2)
cpu MHz         : 180.000000
model           : 9000/778/B180L
model name      : Merlin L2+ 180 (9000/778/B180L)
hversion        : 0x00005040
sversion        : 0x00000481
I-cache         : 64 KB
D-cache         : 64 KB (WB, 0-way associative)
ITLB entries    : 96
DTLB entries    : 96 - shared with ITLB
BTLB fixed      : max. 16384 pages, pagesize=4096 (64MB)
BTLB fix-entr.  : 0 instruction, 0 data (8 combined)
BTLB var-entr.  : 0 instruction, 0 data (0 combined)
bogomips        : 119.60
software id     : 2010134099

Linux patst004 2.6.10-pa10-b180 #1 Fri Jul 1 18:49:47 CEST 2005 parisc GNU/Linux

 16:43:53 up 2 days, 23:16,  4 users,  load average: 7.85, 7.10, 7.15
====<>====
# cat /proc/cpuinfo ; uname -a ; echo " "; uptime
processor       : 0
cpu family      : PA-RISC 2.0
cpu             : PA8600 (PCX-W+)
cpu MHz         : 400.000000
model           : 9000/785/B2000
model name      : Kazoo W+
hversion        : 0x00005d00
sversion        : 0x00000481
I-cache         : 512 KB
D-cache         : 1024 KB (WB, 0-way associative)
ITLB entries    : 160
DTLB entries    : 160 - shared with ITLB
bogomips        : 794.62
software id     : 2011773200

Linux patst005 2.6.10-pa11-b2k32 #2 Mon Jul 4 19:37:53 CEST 2005 parisc GNU/Linux

 16:44:35 up 21:03,  6 users,  load average: 8.23, 8.08, 8.10
======<>====

Previously those 32bit kernel was panicing more/less quickly after the start
of my "stress test" (respectively 2h and 5min)
>

> >
> > > > good news with gcc-4.0 (debian pakage) and '-mfixed-range=fr6-fr21,fr27-fr31'
> > > >
> > > >     o 2.6.9-rc2-pa1 seems to works as fine as with original option
> > > >     o 2.6.9-rc2-pa13 the same
> > > >
> > > > (just have to backport some small stuff to  reach to compile kernels)
> > > >
> > > > I apply my stress test (tar loops + kernel build loops) during a
full
> > day
> > > > for each one without any pb ;-)
> > > >
> > > > I can now try a step forward: 2.6.10-pa + gcc-4.0, ...
> >
> > I'll have to try a gcc-4.0 built kernel to see if it improves things
> > on the c3k.
> >
> cool ;-)
>
[...]
(in case of interest I attached my diff file)

>
> > Just a note, a patch to fix the function pointer canonicalization
> > issue that you and others noticed was installed Friday to the 4.0 branch,
> > and Saturday to the GCC head.
> >
Next test (tomorow :-)

Thanks,
    Joel



[-- Attachment #2: patch-2.6.10-pa11-gcc40.gz --]
[-- Type: application/gzip, Size: 3643 bytes --]

[-- Attachment #3: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

Hello Dave,

> 
> > >  I managed to hang my c3k with a gcc-4.0.0 built kernel
> > Sorry but which kernel did you use?
> 
> 2.6.10-pa11.
> 
Ok I boot the same and grab recent gcc-4.1 src (about 6h gmt) and build i=
t
with build-tls-tools with following options:
--enable-shared --with-system-zlib --disable-nls --enable-debug --host=3D=
hppa-linux
--tar
get=3Dhppa-linux --disable-libmudflap --enable-languages=3Dc,c++

and it hang also in a g++ test:
[...]
PASS: g++.dg/opt/inline3.C (test for excess errors)
Executing on host: /CAD/parisc-linux/build/gcc/gcc/testsuite/../g++ -B/CA=
D/parisc-linux/build/gcc/gcc/testsuite/../
/CAD/parisc-linux/sources/gcc/gcc/testsuite/g++.dg/opt/inline4.C  -nostdi=
nc++
-I/CAD/parisc-linux/build/gcc/hppa-linux/libstdc++-v3/include/hppa-linux
-I/CAD/parisc-linux/build/gcc/hppa-linux/libstdc++-v3/include -I/CAD/pari=
sc-linux/sources/gcc/libstdc++-v3/libsupc++
-I/CAD/parisc-linux/sources/gcc/libstdc++-v3/include/backward -I/CAD/pari=
sc-linux/sources/gcc/libstdc++-v3/testsuite
-fmessage-length=3D0  -O2 -ftemplate-depth-20000  -S  -o inline4.s    (ti=
meout
=3D 300)

My very bad error was to forget to save the System.map, so it's hard to s=
ay
if the pim analyse is relevant:
-----------------  Processor 0 TOC Information -------------------

GR of CPU[0]
00-03   0000000000000000  0000000000000000  000000001010fc68  00000000fb7=
00100
04-07   00000000ffffffff  00000000fb700040  0000000000000000  00000000122=
ab2c8
08-11   0000000000000000  00000000fb700064  00000000fffffff2  00000000000=
0000b
12-15   0000000000000000  00000000122ab4c4  00000000119900a0  00000000119=
90090
16-19   00000000122ab2c8  0000000000590000  00000000faf0231c  00000000122=
ab0f8
20-23   0000000000000000  00000000fffffff2  00000000fb700064  00000000000=
00000
24-27   00000000119900a0  00000000119900a0  00000000fb700064  00000000103=
c1010
28-31   00000000fb7000f0  0000000001990240  0000000011990480  00000000119=
900a0

GR[02] =3D=3D rp =3D 000000001010fc68

Func: do_signal, Off: 0xfc, Addr: 0x1010fc68

1010fc60:       e8 10 b1 04     b,l 101314e8 <copy_siginfo_to_user>,%r2
1010fc64:       34 08 00 00     ldi 0,r8
1010fc68:       08 1c 02 55     copy ret0,r21
1010fc6c:       03 c0 08 bc     mfctl tr6,ret0

GR[22] =3D=3D t1(32bits) =3D=3D arg4(64bits) =3D 00000000fb700064

GR[21] =3D=3D t2(32bits) =3D=3D arg5(64bits) =3D 00000000fffffff2

GR[20] =3D=3D t3(32bits) =3D=3D arg6(64bits) =3D 0000000000000000

GR[19] =3D=3D t4(32bits) =3D=3D arg7(64bits) =3D 00000000122ab0f8

GR[26] =3D=3D arg0 =3D 00000000fb700064

GR[25] =3D=3D arg1 =3D 00000000119900a0

GR[24] =3D=3D arg2 =3D 00000000119900a0

GR[23] =3D=3D arg3 =3D 0000000000000000

GR[27] =3D=3D dp =3D 00000000103c1010

Func: $global$, Off: 0x0, Addr: 0x103c1010


GR[28] =3D=3D ret0 =3D 00000000fb7000f0

GR[29] =3D=3D ret1 or sl =3D 0000000001990240

GR[30] =3D=3D sp =3D 0000000011990480

GR[31] =3D=3D ble rp =3D 00000000119900a0

Func: _end, Off: 0x14972dc, Addr: 0x119900a0


CR of CPU[0]
00-03   0000000000000000  0000000000000000  0000000000000000  00000000000=
00000
04-07   0000000000000000  0000000000000000  0000000000000000  00000000000=
00000
08-11   000000000000836e  0000000000000000  00000000000000c0  00000000000=
00015
12-15   0000000000000000  0000000000000000  000000000010a000  00000000ff8=
00000
16-19   00000c893eed18c2  0000000000000000  000000001010b64c  000000000f9=
4d280
20-23   00000000000041b7  c0000000fb7000f0  000000ff0004ff00  00000000800=
00000
24-27   0000000000474000  0000000008262000  0000000000044021  00000000405=
dab80
28-31   0000000055555555  0000000055555555  0000000011990000  00000000104=
80000



SR of CPU[0]
00-03   00000000          00000000          000041b7          000041b7
04-07   00000000          00000000          00000000          00000000

SR[00] =3D=3D ts0 =3D 00000000

SR[01] =3D=3D ts1 =3D 00000000

SR[03] =3D=3D cpp =3D 000041b7
...
IIA Offset                   =3D 0x000000001010b650
...

e.g. IAOQ =3D 0x000000001010b650

Parse IAOQ =3D 0x000000001010b650 for CPU[0]

Func: L42, Off: 0x4, Addr: 0x1010b650

1010b650:       0f a2 12 90     stw rp,8(,ret1)
1010b654:       0f a3 12 98     stw r3,c(,ret1)
1010b658:       6b a4 00 20     stw r4,10(,ret1)
1010b65c:       6b a5 00 28     stw r5,14(,ret1)

Thanks,
    Joel


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

> Ok I boot the same and grab recent gcc-4.1 src (about 6h gmt) and build it
> with build-tls-tools with following options:
> --enable-shared --with-system-zlib --disable-nls --enable-debug --host=hppa-linux
> --tar
> get=hppa-linux --disable-libmudflap --enable-languages=c,c++

Don't use 4.1 unless you want to help with fixing GCC bugs!

> My very bad error was to forget to save the System.map, so it's hard to say
> if the pim analyse is relevant:

objdump -d will tell you everything you need to know.

According to the grapevine, most of the current stability problems
are probably caused by not properly saving fpregs in all context switches.
The 32-bit port used to be built with -mdisable-fpregs but this was removed
when memcpy was made more efficient.  Note that disabling fpregs when
building the kernel isn't a complete solution as libgcc uses various
floating-point instructions which may or may not get linked into the
kernel (e.g., for integer multiplication).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[John David Anglin]

Joel,

>  #cflags-y      += -mdisable-fpregs
> +cflags-y       += -mfixed-range=fr6-fr21,fr27-fr31

See <http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2005-July/035965.html>.
It's now clear why you had success with the -mfixed-range in gcc 4.0.
The range above disables gcc's use of the floating-point no clobber
registers.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [gcc] should we teach gcc some new tricks?

[Joel Soete]

I know it's just a w-a but I also test 2.6.12.2-pa2 on the b180 and it also survive to my stress test for more then a day:
# cat /proc/cpuinfo ; uname -a ; echo " "; uptime
processor       : 0
cpu family      : PA-RISC 1.1e
cpu             : PA7300LC (PCX-L2)
cpu MHz         : 180.000000
model           : 9000/778/B180L
model name      : Merlin L2+ 180 (9000/778/B180L)
hversion        : 0x00005040
sversion        : 0x00000481
I-cache         : 64 KB
D-cache         : 64 KB (WB, 0-way associative)
ITLB entries    : 96
DTLB entries    : 96 - shared with ITLB
BTLB fixed      : max. 16384 pages, pagesize=4096 (64MB)
BTLB fix-entr.  : 0 instruction, 0 data (8 combined)
BTLB var-entr.  : 0 instruction, 0 data (0 combined)
bogomips        : 119.60
software id     : 2010134099

Linux patst004 2.6.12.2-pa2-b180 #2 Fri Jul 8 12:15:14 CEST 2005 parisc GNU/Linux

  17:00:15 up 1 day,  4:31,  4 users,  load average: 8.86, 8.69, 8.88

Still have to find why it help a bit (for relatively high I/O)?

Why this g++ test (4.1 and not debian 4.0) make hanging the kernel?

Joel

Joel Soete wrote:
>>>Ok I boot the same and grab recent gcc-4.1 src (about 6h gmt) and build
>>
>>it
>>
>>>with build-tls-tools with following options:
>>>--enable-shared --with-system-zlib --disable-nls --enable-debug --host=hppa-linux
>>>--tar
>>>get=hppa-linux --disable-libmudflap --enable-languages=c,c++
>>
>>Don't use 4.1 
> 
> 
> Ok but that was just  to reproduce the pb you encountered :-)
> 
> 
>>unless you want to help with fixing GCC bugs!
>>
> 
> I would so like but I am just able to drive some test as accurately as possible.
> 
> 
[...]
>>The range above disables gcc's use of the floating-point no clobber
>>registers.
> 
btw which fpr do you called 'no clobber'?

I am a bit confused by those other comment in our entry.S:
...
          /* Floating point registers (FIXME: what do we do with these?)

             %fr0  - %fr3    status/exception, not preserved
             %fr4  - %fr7    arguments
             %fr8  - %fr11   not preserved by C code
             %fr12 - %fr21   preserved by C code
             %fr22 - %fr31   not preserved by C code
           */
...

and according to your answer <http://lists.parisc-linux.org/pipermail/parisc-linux/2005-April/026256.html>
fr12 - fr21 (the preserved by C code) would remain unchanged across a call?

Thanks again,
	Joel

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux