Обсуждение: Re: [HACKERS] int8 type -- call for porting results!

Tom. (Lockhart)

Things were broken for int8 on SPARC/Linux, showing a regression test
failure.

Since makeing your suggested change (removing "&& defined(i386)") I'm
getting a "pass" on the int8 tests.


The platform is SPARCstation IPX, Redhat 4.2.
PostgreSQL (latest CVS).
GCC 2.7.2.1.

Thanks,
Keith.

Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
>
> > > I implemented it on a gcc/x86/Linux machine, and we will need to
> > > ensure that it works on other platforms.
<snip>
>
> OK, so GCC on 32-bit machines has a convention that "long long int" is a
> 64-bit quantity. On my machine there is library support for simple
> 64-bit integer math; we'll need to have addition, subtraction,
> multiplication and division. I'll warn you that on a previous release of
> gcc on my Linux box I had to poke around in obscure directories to find
> the subtraction or division routine, but my more recent installations
> seem to have all of the routines up in the normal places.
>
> So, it may be sufficient for testing purposes to remove the
> "&& defined(i386)" and see what you get. We can tailor the defines to
> your machine later.
>
>                       - Tom
>

> Things were broken for int8 on SPARC/Linux, showing a regression test
> failure.
>
> Since making your suggested change (removing "&& defined(i386)") I'm
> getting a "pass" on the int8 tests.
>
> The platform is SPARCstation IPX, Redhat 4.2.
> PostgreSQL (latest CVS).
> GCC 2.7.2.1.

OK, great. Do you have a suggestion for a pre-defined compiler value I
can check? Is "sparc" or "__sparc" defined? On my machine I can run
  gcc -v
which tells me where to look for specs, and in that file is a line of
"predefines". I think that there is another way to check this, but I've
forgotten how.

I wonder if we can try enabling int8's for all gcc compilers? The only
machines that might break on are other 64-bit machines (like some
SGI's?).

                     - Tom

> I wonder if we can try enabling int8's for all gcc compilers? The only
> machines that might break on are other 64-bit machines (like some
> SGI's?).

Yep, should work.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

>> I wonder if we can try enabling int8's for all gcc compilers? The only
>> machines that might break on are other 64-bit machines (like some
>> SGI's?).

> Yep, should work.

Autoconf, my boys, think autoconf.  This sort of guess-and-hope
configuration is exactly what autoconf was invented to prevent.

I'll gin up a few lines of autoconf test code and send them in.
I'd suggest we say that the autoconf test will deliver the
following symbols in config.h:

HAVE_LONG_INT_64    # defined if "long int" works and is 8 bytes
HAVE_LONG_LONG_INT_64    # defined if "long long int" works and is 8 bytes

Are there any other possibilities to worry about?

How hard should the test code try to make sure that int64 actually
works?  Judging from Tom's comments, we'd better try a multiply and
a divide at least.

            regards, tom lane