[parisc-linux] TLS toolchain update (6 regressions left)

[parisc-linux] TLS toolchain update (6 regressions left)

[Carlos O'Donell]

Please stand up and pat yourself on the back:

make[2]: *** [/glibc/math/test-fenv.out] Error 1
	= Regression (1)
make[2]: *** [/glibc/math/test-float.out] Error 1
make[2]: *** [/glibc/math/test-double.out] Error 1
make[2]: *** [/glibc/math/test-ifloat.out] Error 1
make[2]: *** [/glibc/math/test-idouble.out] Error 1
make[1]: *** [math/tests] Error 2
make[2]: *** [/glibc/stdlib/tst-strtod.out] Error 1
make[2]: *** [/glibc/stdlib/bug-strtod.out] Error 1
make[1]: *** [stdlib/tests] Error 2
make[2]: [/glibc/posix/annexc.out] Error 1 (ignored)
make[2]: *** [/glibc/elf/tst-array1.out] Error 1
make[2]: *** [/glibc/elf/tst-array2.out] Error 1
make[2]: *** [/glibc/elf/tst-array3.out] Error 1
make[2]: *** [/glibc/elf/tst-array4.out] Error 1
make[2]: *** [/glibc/elf/tst-array1-static.out] Error 1
	= Regressions (5)
make[2]: *** [/glibc/elf/tst-tls13.out] Error 1
	= TIMEOUTFACTOR=10 required.
make[1]: *** [elf/tests] Error 2
make: *** [check] Error 2

That's 6 regressions for the C Library, which I'll target over the next
couple of weeks.

The last big error was that glibc was considering the build a
cross-compile and the environment just puked.

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

[parisc-linux] Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Fri, Jul 15, 2005 at 10:26:10AM -0400, Carlos O'Donell wrote:
> make[2]: *** [/glibc/math/test-fenv.out] Error 1
> 	= Regression (1)
> make[2]: *** [/glibc/math/test-float.out] Error 1
> make[2]: *** [/glibc/math/test-double.out] Error 1
> make[2]: *** [/glibc/math/test-ifloat.out] Error 1
> make[2]: *** [/glibc/math/test-idouble.out] Error 1
> make[1]: *** [math/tests] Error 2
> make[2]: *** [/glibc/stdlib/tst-strtod.out] Error 1
> make[2]: *** [/glibc/stdlib/bug-strtod.out] Error 1
> make[1]: *** [stdlib/tests] Error 2
> make[2]: [/glibc/posix/annexc.out] Error 1 (ignored)
> make[2]: *** [/glibc/elf/tst-array1.out] Error 1
> make[2]: *** [/glibc/elf/tst-array2.out] Error 1
> make[2]: *** [/glibc/elf/tst-array3.out] Error 1
> make[2]: *** [/glibc/elf/tst-array4.out] Error 1
> make[2]: *** [/glibc/elf/tst-array1-static.out] Error 1
> 	= Regressions (5)
> make[2]: *** [/glibc/elf/tst-tls13.out] Error 1
> 	= TIMEOUTFACTOR=10 required.
> make[1]: *** [elf/tests] Error 2
> make: *** [check] Error 2

Fixed binutils...

Make that 1 regression:

make[2]: *** [/glibc/math/test-fenv.out] Error 1
make[2]: *** [/glibc/math/test-float.out] Error 1
make[2]: *** [/glibc/math/test-double.out] Error 1
make[2]: *** [/glibc/math/test-ifloat.out] Error 1
make[2]: *** [/glibc/math/test-idouble.out] Error 1
make[1]: *** [math/tests] Error 2
make[2]: *** [/glibc/stdlib/tst-strtod.out] Error 1
make[2]: *** [/glibc/stdlib/bug-strtod.out] Error 1
make[1]: *** [stdlib/tests] Error 2
make[2]: [/glibc/posix/annexc.out] Error 1 (ignored)
make: *** [check] Error 2

However, the following is troubling and where trouble goes, so does the
blame on the compiler.

test-float.out (Non-inline float):
 Test suite completed:
   2599 test cases plus 2384 tests for exception flags executed.
-  39 errors occurred.
+  4363 errors occurred.

test-double.out (Non-inline double):
 Test suite completed:
   2624 test cases plus 2399 tests for exception flags executed.
-  38 errors occurred.
+  4388 errors occurred.

Although the numbers don't add up with the errors a cursory check shows
*none* of the non-inline math tests passed.

The inline math does *much* better, observe:

test-ifloat.out (Inline float):
 Test suite completed:
   2537 test cases plus 2322 tests for exception flags executed.
-  1 errors occurred.
+  11 errors occurred.

test-idbouble.out (Inline double):
 Test suite completed:
   2562 test cases plus 2337 tests for exception flags executed.
-  1 errors occurred.
+  10 errors occurred.


c.

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

[parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> However, the following is troubling and where trouble goes, so does the
> blame on the compiler.
> 
> test-float.out (Non-inline float):
>  Test suite completed:
>    2599 test cases plus 2384 tests for exception flags executed.
> -  39 errors occurred.
> +  4363 errors occurred.
> 
> test-double.out (Non-inline double):
>  Test suite completed:
>    2624 test cases plus 2399 tests for exception flags executed.
> -  38 errors occurred.
> +  4388 errors occurred.
> 
> Although the numbers don't add up with the errors a cursory check shows
> *none* of the non-inline math tests passed.

I don't want to throw stones but I posted a message to parisc two
days ago indicating that we have at least one kernel bug in its math
emulation ;)

Ok, PA 2.0 support could be suspect.  I doubt very much there are
major FP issues with PA 1.1.  In PA 1.1, essentially all the operations
are supported in hardware (I hate assist).  There's an issue with
complex support using PA 1.0 but if the compiler didn't die that's
not likely the problem.  That's fixed in main.  Finally, you've got
the glibc issue in handling 64-bit long doubles.  I would suspect a
glibc issue first.  GCC doesn't have much to do with exception support
or control of rounding modes, although you would think the compiler
would need to know about rounding mode.

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

[parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Fri, Jul 15, 2005 at 08:08:43PM -0400, John David Anglin wrote:
> > However, the following is troubling and where trouble goes, so does the
> > blame on the compiler.
> > 
> > test-float.out (Non-inline float):
> >  Test suite completed:
> >    2599 test cases plus 2384 tests for exception flags executed.
> > -  39 errors occurred.
> > +  4363 errors occurred.
> > 
> > test-double.out (Non-inline double):
> >  Test suite completed:
> >    2624 test cases plus 2399 tests for exception flags executed.
> > -  38 errors occurred.
> > +  4388 errors occurred.
> > 
> > Although the numbers don't add up with the errors a cursory check shows
> > *none* of the non-inline math tests passed.
> 
> I don't want to throw stones but I posted a message to parisc two
> days ago indicating that we have at least one kernel bug in its math
> emulation ;)

I knew I'd draw you ire if I blamed the compiler! :)
 
> Ok, PA 2.0 support could be suspect.  I doubt very much there are
> major FP issues with PA 1.1.  In PA 1.1, essentially all the operations
> are supported in hardware (I hate assist).  There's an issue with
> complex support using PA 1.0 but if the compiler didn't die that's
> not likely the problem.  That's fixed in main.  Finally, you've got
> the glibc issue in handling 64-bit long doubles.  I would suspect a
> glibc issue first.  GCC doesn't have much to do with exception support
> or control of rounding modes, although you would think the compiler
> would need to know about rounding mode.

I'm only testing float and double support, I have temporarily disabled
long double support for hppa during testing.

I don't quite understand how something like "fpclassify" can *ever* fail
under any implementation.

Could you review these files:
http://cvs.parisc-linux.org/glibc/sysdeps/hppa/fpu/

With an eye to correct asm statement? If these don't work then it all
goes down the tubes. I'm sure gcc is probably doing the right thing and
that asm is doing the wrong thing.

c.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Fri, Jul 15, 2005 at 08:57:15PM -0400, Carlos O'Donell wrote:
> I don't quite understand how something like "fpclassify" can *ever* fail
> under any implementation.
> 
> Could you review these files:
> http://cvs.parisc-linux.org/glibc/sysdeps/hppa/fpu/
> 
> With an eye to correct asm statement? If these don't work then it all
> goes down the tubes. I'm sure gcc is probably doing the right thing and
> that asm is doing the wrong thing.

I think gcc is to blame, or the constraints in the assembly?

--- GCC 4.0 ---

0x40349890 <feclearexcept+0>:   ldo 40(sp),sp
0x40349894 <feclearexcept+4>:   ldo -38(sp),ret0
0x40349898 <feclearexcept+8>:   stw r19,-20(,sp)
0x4034989c <feclearexcept+12>:  fstd fr0,0(,ret0)
0x403498a0 <feclearexcept+16>:  fldd 0(,ret0),fr0
0x403498a4 <feclearexcept+20>:  ldi 0,ret0
0x403498a8 <feclearexcept+24>:  bv r0(rp)
0x403498ac <feclearexcept+28>:  ldo -40(sp),sp

Notice that it thinks the argument is on the stack? Are the assembly
constraints confusing gcc?

The above is competely bogus.

--- GCC 3.3.5 ---

00000000 <feclearexcept>:
   0:   37 de 00 80     ldo 40(sp),sp
   4:   d7 5a 0b 7b     depw,z r26,4,5,r26
   8:   6b d3 3f c1     stw r19,-20(,sp)
   c:   37 d4 3f 91     ldo -38(sp),r20
  10:   2e 80 12 00     fstd fr0,0(,r20)
  14:   4b d5 3f 91     ldw -38(,sp),r21
  18:   0b 55 00 1a     andcm r21,r26,r26
  1c:   6b da 3f 91     stw r26,-38(,sp)
  20:   2e 80 10 00     fldd 0(,r20),fr0
  24:   34 1c 00 00     ldi 0,ret0
  28:   e8 40 c0 00     bv r0(rp)
  2c:   37 de 3f 81     ldo -40(sp),sp

This one properly loads the value from r26.
This one works.

c.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> I think gcc is to blame, or the constraints in the assembly?
> 
> --- GCC 4.0 ---
> 
> 0x40349890 <feclearexcept+0>:   ldo 40(sp),sp
> 0x40349894 <feclearexcept+4>:   ldo -38(sp),ret0
> 0x40349898 <feclearexcept+8>:   stw r19,-20(,sp)
> 0x4034989c <feclearexcept+12>:  fstd fr0,0(,ret0)
> 0x403498a0 <feclearexcept+16>:  fldd 0(,ret0),fr0
> 0x403498a4 <feclearexcept+20>:  ldi 0,ret0
> 0x403498a8 <feclearexcept+24>:  bv r0(rp)
> 0x403498ac <feclearexcept+28>:  ldo -40(sp),sp

PR time.  Please add danglin@gcc.gnu.org to the CC list.

> Notice that it thinks the argument is on the stack? Are the assembly
> constraints confusing gcc?

Probably, but its not clear at the moment.  I think the asm's need
the volatile keyword as they have side effects that aren't known to
gcc (i.e., scheduling might move a floating point operation past
the asm's should the functions be inlined.

Taking a quick look, I see the and has been removed from the initial
rtl generation.  So, this is a tree optimization bug.

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] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Fri, Jul 15, 2005 at 09:54:25PM -0400, John David Anglin wrote:
> > I think gcc is to blame, or the constraints in the assembly?
> > 
> > --- GCC 4.0 ---
> > 
> > 0x40349890 <feclearexcept+0>:   ldo 40(sp),sp
> > 0x40349894 <feclearexcept+4>:   ldo -38(sp),ret0
> > 0x40349898 <feclearexcept+8>:   stw r19,-20(,sp)
> > 0x4034989c <feclearexcept+12>:  fstd fr0,0(,ret0)
> > 0x403498a0 <feclearexcept+16>:  fldd 0(,ret0),fr0
> > 0x403498a4 <feclearexcept+20>:  ldi 0,ret0
> > 0x403498a8 <feclearexcept+24>:  bv r0(rp)
> > 0x403498ac <feclearexcept+28>:  ldo -40(sp),sp
> 
> PR time.  Please add danglin@gcc.gnu.org to the CC list.
> 
> > Notice that it thinks the argument is on the stack? Are the assembly
> > constraints confusing gcc?
> 
> Probably, but its not clear at the moment.  I think the asm's need
> the volatile keyword as they have side effects that aren't known to
> gcc (i.e., scheduling might move a floating point operation past
> the asm's should the functions be inlined.

I hadn't considered the effects of rescheduling. I guess this can happen
to any code between the asm statements.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> I hadn't considered the effects of rescheduling. I guess this can happen
> to any code between the asm statements.

As long as the dependencies are correct, then then shouldn't happen.
Possibly, adding a dependency on register "CCFP" is what's needed.
I don't know if that actually works but it's how we handle floating-point
condition codes internally.  I think that would allow inlining of these
routines in code that does floating-point compares and tests.

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] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Sat, Jul 16, 2005 at 03:15:34PM -0400, John David Anglin wrote:
> > I hadn't considered the effects of rescheduling. I guess this can happen
> > to any code between the asm statements.
> 
> As long as the dependencies are correct, then then shouldn't happen.
> Possibly, adding a dependency on register "CCFP" is what's needed.
> I don't know if that actually works but it's how we handle floating-point
> condition codes internally.  I think that would allow inlining of these
> routines in code that does floating-point compares and tests.

What sort of dependancy on CCFP? Do you have an example somewhere?

c.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> What sort of dependancy on CCFP? Do you have an example somewhere?

No.

  If your assembler instruction can alter the condition code register, add
  @samp{cc} to the list of clobbered registers.  GCC on some machines
  represents the condition codes as a specific hardware register;
  @samp{cc} serves to name this register.  On other machines, the
  condition code is handled differently, and specifying @samp{cc} has no
  effect.  But it is valid no matter what the machine.

Thinking a little more, I believe specifying "r0" in the clobber list
of the asm will do the job.  Register 0 is used to hold condition codes
for both integer and floating point comparisons.  I don't think there's
a way to express that the register is only used.  There's no constraint
letter for r0, etc.

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] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Sat, Jul 16, 2005 at 03:48:10PM -0400, John David Anglin wrote:
> > What sort of dependancy on CCFP? Do you have an example somewhere?
> 
> No.
> 
>   If your assembler instruction can alter the condition code register, add
>   @samp{cc} to the list of clobbered registers.  GCC on some machines
>   represents the condition codes as a specific hardware register;
>   @samp{cc} serves to name this register.  On other machines, the
>   condition code is handled differently, and specifying @samp{cc} has no
>   effect.  But it is valid no matter what the machine.
> 
> Thinking a little more, I believe specifying "r0" in the clobber list
> of the asm will do the job.  Register 0 is used to hold condition codes
> for both integer and floating point comparisons.  I don't think there's
> a way to express that the register is only used.  There's no constraint
> letter for r0, etc.

Will this ever happen during inlining?

fstd chain -> memory
operation 1
			fstd chain -> memory
fldd chain -> regs
			operation 2
			fldd chain -> regs

Operation 2 could trap when expected that it couldn't because the fstd
had cleared the traps.

c.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> Will this ever happen during inlining?
> 
> fstd chain -> memory
> operation 1
> 			fstd chain -> memory
> fldd chain -> regs
> 			operation 2
> 			fldd chain -> regs
> 
> Operation 2 could trap when expected that it couldn't because the fstd
> had cleared the traps.

I guess clobbering all the fp registers plus r0 will stop this.

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] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Sat, Jul 16, 2005 at 04:29:54PM -0400, John David Anglin wrote:
> > Will this ever happen during inlining?
> > 
> > fstd chain -> memory
> > operation 1
> > 			fstd chain -> memory
> > fldd chain -> regs
> > 			operation 2
> > 			fldd chain -> regs
> > 
> > Operation 2 could trap when expected that it couldn't because the fstd
> > had cleared the traps.
> 
> I guess clobbering all the fp registers plus r0 will stop this.

That seems like overkill, I just don't want gcc schedule between the asm
statements. The fstd chain, and fldd chain are always asm statements.

Is there no other way? Clobbering will add huge register pressure and
force gcc to spill all the fpregs and restore after the call.

c.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> > I guess clobbering all the fp registers plus r0 will stop this.
> 
> That seems like overkill, I just don't want gcc schedule between the asm
> statements. The fstd chain, and fldd chain are always asm statements.
> 
> Is there no other way? Clobbering will add huge register pressure and
> force gcc to spill all the fpregs and restore after the call.

Hmmm, this seems tricky:

  For example, on many targets there is a system
  register which can be set to control the rounding mode of
  floating point operations.  You might try
  setting it with a volatile @code{asm}, like this PowerPC example:

  @smallexample
	asm volatile("mtfsf 255,%0" : : "f" (fpenv));
	sum = x + y;
  @end smallexample

  @noindent
  This will not work reliably, as the compiler may move the addition back
  before the volatile @code{asm}.  To make it work you need to add an
  artificial dependency to the @code{asm} referencing a variable in the code
  you don't want moved, for example:

  @smallexample
	asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
	sum = x + y;
  @end smallexample

  ...

  For reasons similar to those described above, it is not possible to give
  an assembler instruction access to the condition code left by previous
  instructions.

If you clobber memory in the asm, then I think it will be a barrier
for memory accesses.  I think a function call is ok:

  a = b + c;
  z = xyzzy ();

I don't think gcc can reorder the two operations unless it can prove
the function is pure and doesn't write all memory.

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] TLS toolchain update (6 regressions left)

[Carlos O'Donell]

On Fri, Jul 15, 2005 at 10:26:10AM -0400, Carlos O'Donell wrote:
> Please stand up and pat yourself on the back:
> 
> make[2]: *** [/glibc/math/test-fenv.out] Error 1
> 	= Regression (1)
> make[2]: *** [/glibc/math/test-float.out] Error 1
> make[2]: *** [/glibc/math/test-double.out] Error 1
> make[2]: *** [/glibc/math/test-ifloat.out] Error 1
> make[2]: *** [/glibc/math/test-idouble.out] Error 1
> make[1]: *** [math/tests] Error 2
> make[2]: *** [/glibc/stdlib/tst-strtod.out] Error 1
> make[2]: *** [/glibc/stdlib/bug-strtod.out] Error 1
> make[1]: *** [stdlib/tests] Error 2
> make[2]: [/glibc/posix/annexc.out] Error 1 (ignored)
> make[2]: *** [/glibc/elf/tst-array1.out] Error 1
> make[2]: *** [/glibc/elf/tst-array2.out] Error 1
> make[2]: *** [/glibc/elf/tst-array3.out] Error 1
> make[2]: *** [/glibc/elf/tst-array4.out] Error 1
> make[2]: *** [/glibc/elf/tst-array1-static.out] Error 1
> 	= Regressions (5)
> make[2]: *** [/glibc/elf/tst-tls13.out] Error 1
> 	= TIMEOUTFACTOR=10 required.
> make[1]: *** [elf/tests] Error 2
> make: *** [check] Error 2

Patched up the floating point asm constraints.

make[2]: *** [/glibc/math/test-float.out] Error 1
make[2]: *** [/glibc/math/test-double.out] Error 1
make[2]: *** [/glibc/math/test-ifloat.out] Error 1
make[2]: *** [/glibc/math/test-idouble.out] Error 1
make[1]: *** [math/tests] Error 2
make[2]: *** [/glibc/stdlib/tst-strtod.out] Error 1
make[2]: *** [/glibc/stdlib/bug-strtod.out] Error 1
make[1]: *** [stdlib/tests] Error 2
make[2]: [/glibc/posix/annexc.out] Error 1 (ignored)
make: *** [check] Error 2

No regressions. But we still have a couple of functions that look like
the math is a bit wrong. However, we are doing better than non-tls, I
figure because the constraints are still a bit wrong.


----- GCC 4.0 (glibc + fp constriant fix + tls) -----
==> test-double.out <==

Test suite completed:
  2624 test cases plus 2399 tests for exception flags executed.
  24 errors occurred.

==> test-float.out <==

Test suite completed:
  2599 test cases plus 2384 tests for exception flags executed.
  23 errors occurred.

==> test-idouble.out <==

Test suite completed:
  2562 test cases plus 2337 tests for exception flags executed.
  10 errors occurred.

==> test-ifloat.out <==

Test suite completed:
  2537 test cases plus 2322 tests for exception flags executed.
  11 errors occurred.

----- GCC 3.3.5 (glibc) -----

==> test-double.out <==

Test suite completed:
  2624 test cases plus 2399 tests for exception flags executed.
  38 errors occurred.

==> test-float.out <==

Test suite completed:
  2599 test cases plus 2384 tests for exception flags executed.
  39 errors occurred.

==> test-idouble.out <==

Test suite completed:
  2562 test cases plus 2337 tests for exception flags executed.
  1 errors occurred.

==> test-ifloat.out <==

Test suite completed:
  2537 test cases plus 2322 tests for exception flags executed.
  1 errors occurred.

We are on par with the previous test results. I'm very pleased.
-----

Looking at the test failures in test-float, I see the following:

testing float (without inline functions)
Failure: Test: atan2 (-0.00756827042671106339, -.001792735857538728036)
== -1.80338464113663849327153994379639112
Result:
 is:         -1.80338394641876220703e+00  -0x1.cdaa9200000000000000p+0
 should be:  -1.80338466167449951172e+00  -0x1.cdaa9e00000000000000p+0
 difference:  7.15255737304687500000e-07   0x1.80000000000000000000p-21
 ulp       :  6.0000  
 max.ulp   :  0.0000  

I can't seem to fix this test, but I figure it's because I haven't
played enough with ulps settings that flag the test as failed.
The error is in the e-06 rang which really sucks. Any thoughts?

Next is a set of failures all related to "rint" for rounding an integer
to the correct value. The failures are very werid.

Failure: Test: rint (1.5) == 1.0
Result:
 is:          2.00000000000000000000e+00   0x1.00000000000000000000p+1
 should be:   1.00000000000000000000e+00   0x1.00000000000000000000p+0
 difference:  1.00000000000000000000e+00   0x1.00000000000000000000p+0
 ulp       :  8388608.0000
 max.ulp   :  0.0000  

That ulp is bogus? Not to mention that the rounding direction is wrong.

Lastly is:

Failure: Real part of: cacos (inf + NaN i) == NaN + inf i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: cacos (-inf + NaN i) == NaN + inf i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN + inf i) == NaN - inf i: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN - inf i) == NaN + inf i: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN + NaN i) == NaN + NaN i: Exception "Invalid operation" set
Failure: Real part of: ccosh (inf + NaN i) == inf + NaN i: Exception "Invalid operation" set
Failure: Real part of: ccosh (-inf + NaN i) == inf + NaN i: Exception "Invalid operation" set
Failure: Real part of: cpow (NaN + NaN i, NaN + NaN i) == NaN + NaN i: Exception "Invalid operation" set
Failure: Real part of: csinh (0.0 + NaN i) == 0.0 + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (-0 + NaN i) == 0.0 + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (inf + NaN i) == inf + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (-inf + NaN i) == inf + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set

Which all looks like corner case tets for these functions and the processor
is raising an exception. I've never had a chance or desire to look at these
but I will when I have nothing better to do ;)

c.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> > I think gcc is to blame, or the constraints in the assembly?
> > 
> > --- GCC 4.0 ---
> > 
> > 0x40349890 <feclearexcept+0>:   ldo 40(sp),sp
> > 0x40349894 <feclearexcept+4>:   ldo -38(sp),ret0
> > 0x40349898 <feclearexcept+8>:   stw r19,-20(,sp)
> > 0x4034989c <feclearexcept+12>:  fstd fr0,0(,ret0)
> > 0x403498a0 <feclearexcept+16>:  fldd 0(,ret0),fr0
> > 0x403498a4 <feclearexcept+20>:  ldi 0,ret0
> > 0x403498a8 <feclearexcept+24>:  bv r0(rp)
> > 0x403498ac <feclearexcept+28>:  ldo -40(sp),sp
> 
> PR time.  Please add danglin@gcc.gnu.org to the CC list.

Changed my mind.  It's not a GCC bug.  The second asm has to show that
it uses the memory set by the first:

#include <fenv.h>

int
feclearexcept (int excepts)
{
  struct { unsigned int sw[2]; } s;

  /* Get the current status word. */
  __asm__ volatile ("fstd %%fr0,0(%1)" : "=m" (s) : "r" (&s));

  /* Clear all the relevant bits. */
  s.sw[0] &= ~((excepts & FE_ALL_EXCEPT) << 27);
  __asm__ volatile ("fldd 0(%0),%%fr0" : : "r" (&s), "m" (s));

  /* Success.  */
  return 0;
}

I used a struct so that GCC would know exactly what memory was affected.

There is one other issue that I'm not sure about.  I presume that you
used fldd to access the floating-point status register to avoid the
situation where a floating-point identify instruction has been previously
been executed and the status register is in format three.  It's not
clear from the arch whether the fldd returns the result of the identify
or not.

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] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Fri, Jul 15, 2005 at 10:55:26PM -0400, John David Anglin wrote:
> > PR time.  Please add danglin@gcc.gnu.org to the CC list.
> 
> Changed my mind.  It's not a GCC bug.  The second asm has to show that
> it uses the memory set by the first:

Ah, thank you for the clarification. I'll try to examine the rest of
them and cleanup the assembly.
 
> #include <fenv.h>
> 
> int
> feclearexcept (int excepts)
> {
>   struct { unsigned int sw[2]; } s;
> 
>   /* Get the current status word. */
>   __asm__ volatile ("fstd %%fr0,0(%1)" : "=m" (s) : "r" (&s));
> 
>   /* Clear all the relevant bits. */
>   s.sw[0] &= ~((excepts & FE_ALL_EXCEPT) << 27);
>   __asm__ volatile ("fldd 0(%0),%%fr0" : : "r" (&s), "m" (s));
> 
>   /* Success.  */
>   return 0;
> }
> 
> I used a struct so that GCC would know exactly what memory was affected.
> 
> There is one other issue that I'm not sure about.  I presume that you
> used fldd to access the floating-point status register to avoid the
> situation where a floating-point identify instruction has been previously
> been executed and the status register is in format three.  It's not
> clear from the arch whether the fldd returns the result of the identify
> or not.

Who previously executed the COPR,0,0?

I use the fldd to set the new cleared state of the status register.

If the thread had previously executed 'fstd' followed by a 'copr,0,0'
and had not immediately thereafter executed another 'fstd' then the
operation is *undefined* as per PA 1.1 6-63.

Context switching should save and restore the states properly for this
to work.

I think the arch is very clear about the issue, but perhaps I'm
misreading something. Do you have a case where the above wouldn't work?

c.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> Who previously executed the COPR,0,0?

I dunno, incorrect identify sequence?  I agree the 1.1 arch is specific
about how to do an identify sequence.

> I use the fldd to set the new cleared state of the status register.

I had been wondering if fstw and fldw could be used, but it's an
undefined operation to set T with fldw and fstd clears T, so I believe
your use of fstd and fldd is correct in this sequence.

However, you have to be careful in using fstd to get the fp status
register as it clears T after the insn.

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] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> However, you have to be careful in using fstd to get the fp status
> register as it clears T after the insn.

And, indeed the following is wrong for the above reason:

#include <fenv.h>

int
fetestexcept (int excepts)
{
  unsigned int sw[2];

  /* Get the current status word. */
  __asm__ ("fstd %%fr0,0(%1)" : "=m" (*sw) : "r" (sw));

  return (sw[0] >> 27) & excepts & FE_ALL_EXCEPT;
}

You need to add a 'fldd' to the asm to restore the T bit.  Another
option might be to use fstw to access the status register in this
situation.

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] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Sat, Jul 16, 2005 at 01:54:48PM -0400, John David Anglin wrote:
> > However, you have to be careful in using fstd to get the fp status
> > register as it clears T after the insn.
> 
> And, indeed the following is wrong for the above reason:
> 
> #include <fenv.h>
> 
> int
> fetestexcept (int excepts)
> {
>   unsigned int sw[2];
> 
>   /* Get the current status word. */
>   __asm__ ("fstd %%fr0,0(%1)" : "=m" (*sw) : "r" (sw));
> 
>   return (sw[0] >> 27) & excepts & FE_ALL_EXCEPT;
> }
> 
> You need to add a 'fldd' to the asm to restore the T bit.  Another
> option might be to use fstw to access the status register in this
> situation.

I'm going to test the use of fstw.

fegetexcept, fegetround also need this fix (maybe more).

There is another potential bug, I should make sure the fr0 restore is
always at the end too incase it rearms a trap.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> There is another potential bug, I should make sure the fr0 restore is
> always at the end too incase it rearms a trap.

hpux uses two little hand-coded functions to avoid this problem.  The
get operation uses fstd but it immediately restores the previous status
value with fldd.  The put does the restore in the delay slot of the return.

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] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Sat, Jul 16, 2005 at 01:37:50PM -0400, John David Anglin wrote:
> > Who previously executed the COPR,0,0?
> 
> I dunno, incorrect identify sequence?  I agree the 1.1 arch is specific
> about how to do an identify sequence.
 
There is no way to prevent this. An application can always shoot itself
in the foot.

And since the identify sequence should be written in assembly the
compiler can't schedule it around.

It should also be save to execute such a sequence at any point in the
insn stream.

> > I use the fldd to set the new cleared state of the status register.
> 
> I had been wondering if fstw and fldw could be used, but it's an
> undefined operation to set T with fldw and fstd clears T, so I believe
> your use of fstd and fldd is correct in this sequence.

I have to read this again to make sure I did it all right.

> However, you have to be careful in using fstd to get the fp status
> register as it clears T after the insn.

Yes, I might have some mistakes there.

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