On Wed, Mar 18, 2015 at 3:16 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> For another, Andreas has chosen to lump together __int128 and unsigned
>> __int128 into one test, where the latter really doesn't receive
>> coverage.
>
> On my urging actually. It's pretty darn unlikely that only one variant
> will work.
I think that makes sense. Since we're targeting GCC here, and we're
comfortable with that, I guess that's okay after all.
> The reason we need a link test (vs just a compile test) is that gcc
> links to helper functions to do math - even if they're not present on
> the target platform. Compiling will succeed, but linking won't.
Okay. Attached revision has a few tweaks that reflect the status of
int128/uint128 as specialized types that are basically only useful for
this optimization, or other similar optimizations on compilers that
either are GCC, or aim to be compatible with it. I don't think
Andreas' V9 reflected that sufficiently.
Also, I now always use PolyNumAggState (the typedef), even for #define
HAVE_INT128 code, which I think is a bit clearer. Note that I have
generated a minimal diff, without the machine generated changes that
are ordinarily included in the final commit when autoconf tests are
added, mostly because I do not have the exact version of autoconf on
my development machine required to do this without creating irrelevant
cruft.
Marked "Ready for committer".
A committer that has the exact right version of autoconf (GNU Autoconf
2.69), or perhaps Andreas can build the machine generated parts.
Andres may wish to take another look at the autoconf changes.
--
Peter Geoghegan