Horton

Re: Improving and extending int128.h to more of numeric.c

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: John Naylor <johncnaylorls@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-09T17:27:50Z
Lists: pgsql-hackers 
Hi,

On 2025-07-09 10:38:31 +0100, Dean Rasheed wrote:
> On Wed, 9 Jul 2025 at 07:41, John Naylor <johncnaylorls@gmail.com> wrote:
> >
> > Hi Dean, I went to take a look at this and got stuck at building the
> > test file. The usual pointing gcc to the src and build include
> > directories didn't cut it. How did you get it to work?
> >
>
> Yes, it wasn't immediately obvious how to do it. I first built
> postgres as normal, including the  pg_config tool, and then used that
> to compile the test as follows:
>
> gcc -O3 -g \
>     src/tools/testint128.c \
>     -I$(pg_config --includedir-server) \
>     -o src/tools/testint128 \
>     $(pg_config --libs)
>
> It actually only needs -lpgcommon -lpgport -lm, but it seemed easier
> just to include all of the pg_config --libs.

I think we should wire this up to the buildsystem and our testsuite...  Having
testcode that is not run automatically may be helpful while originally
developing something, but it doesn't do anything to detect portability issues
or regressions.

Greetings,

Andres Freund

Commits

  1. Guard against division by zero in test_int128 module.

  2. Extend int128.h to support more numeric code.

  3. Simplify non-native 64x64-bit multiplication in int128.h.

  4. Optimise non-native 128-bit addition in int128.h.

  5. Refactor int128.h, bringing the native and non-native code together.

  6. Convert src/tools/testint128.c into a test module.