Regression test on FBSD 3.3 & 4.2, IRIX 6.5 (was Re: Re: Call for platforms)

On Mon, Mar 26, 2001 at 07:09:38PM -0500, Tom Lane allegedly wrote:
> Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> > That is not already available from the Irix support code?
> 
> What we have for IRIX is
> 
> #if defined(__sgi)
> /*
>  * SGI IRIX 5
>  * slock_t is defined as a unsigned long. We use the standard SGI
>  * mutex API.
>  *
>  * The following comment is left for historical reasons, but is probably
>  * not a good idea since the mutex ABI is supported.
>  *
>  * This stuff may be supplemented in the future with Masato Kataoka's MIPS-II
>  * assembly from his NECEWS SVR4 port, but we probably ought to retain this
>  * for the R3000 chips out there.
>  */
> #include "mutex.h"
> #define TAS(lock)    (test_and_set(lock,1))
> #define S_UNLOCK(lock)    (test_then_and(lock,0))
> #define S_INIT_LOCK(lock)    (test_then_and(lock,0))
> #define S_LOCK_FREE(lock)    (test_then_add(lock,0) == 0)
> #endif     /* __sgi */
> 
> Doesn't look to me like it's likely to work on anything but IRIX ...
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

I just tried to compile 7.1RC1 on my IRIX 6.5 box using gcc 2.95.2.
Appearently gcc chokes on some assembly in src/backend/storage/buffer/s_lock.c
(tas_dummy on line 235 to be precise).

Here's the offending code:

#if defined(__mips__)
static void
tas_dummy()
{       __asm__         _volatile__(                                                                               "\
.global tas                                             \n\
tas:                                                    \n\                       .frame  $sp, 0, $31     \n\
           ll              $14, 0($4)      \n\                       or              $15, $14, 1     \n\
      sc              $15, 0($4)      \n\                       beq             $15, 0, fail\n\
bne            $14, 0, fail\n\                       li              $2, 0           \n\                       .livereg
0x2000FF0E,0x00000FFF \n\                       j               $31                     \n\
 
fail:                                                   \n\                       li              $2, 1           \n\
                   j       $31                     \n\
 
");
}

Notice the single underscore before volatile. I just checked the CVS
version of s_lock.c and this is still not fixed. Fixing this causes
as (the SGI version, not GNU as) to choke on the '.global tas' statement.

s_lock.c: At top level:
s_lock.c:234: warning: `tas_dummy' defined but not used
as: Error: /var/tmp/ccoUdrOb.s, line 421: undefined assembler operation: .global     .global tas
gmake[4]: *** [s_lock.o] Error 1

Commenting out the .global statements does produce a binary, but it can't
complete the regression test due to other problems.

IpcSemaphoreCreate: semctl(id=0, 0, SETALL, ...) failed: Bad address

I'll see if I can come up with a solution for the .global and the
semaphore problem. I'll check wether pgsql 7.0 does run on this box too.
One wonders how Robert Bruccoleri did get 7.1RC1 to work properly. I'll
check the archive for clues.

On my FreeBSD 4.2 box 7.1RC1 runs flawlessly. I've also tested the CVS
version a few days ago on a 4.1.1 box without any problems.

FreeBSD 3.3 however does have some problems.

*** ./expected/float8-small-is-zero.out Fri Mar 31 07:30:31 2000
--- ./results/float8.out  Tue Mar 27 02:28:07 2001
***************
*** 214,220 ****    SET f1 = FLOAT8_TBL.f1 * '-1'    WHERE FLOAT8_TBL.f1 > '0.0'; SELECT '' AS bad, f.f1 * '1e200' from
FLOAT8_TBLf;
 
! ERROR:  Bad float8 input format -- overflow SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f; ERROR:  pow() result
isout of range SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
 
--- 214,220 ----    SET f1 = FLOAT8_TBL.f1 * '-1'    WHERE FLOAT8_TBL.f1 > '0.0'; SELECT '' AS bad, f.f1 * '1e200' from
FLOAT8_TBLf;
 
! ERROR:  floating point exception! The last floating point operation either exceeded legal ranges or was a divide by
zeroSELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f; ERROR:  pow() result is out of range SELECT '' AS bad, ln(f.f1)
fromFLOAT8_TBL f where f.f1 = '0.0' ;
 

Some geometry tests also fail. I'll check those tomorrow, erm, today. The
same goes for 7.1RC1 on Solaris 8 (Intel and Sparc).

Cheers,

Mathijs
-- 
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.                                                   Erik Naggum