Re: BUG #6760: make check fails on strings SQL T581 regex test - Mailing list pgsql-bugs

This problem has been resolved; following a couple of suggestions from Tom =
Lane, it became apparent that the cause was due to the xlc compiler.  This =
mail summarizes the steps and findings, in the hope that it might be useful=
 to someone else.

My server environment is AIXv7.1 running on POWER7, with xlcV11.1.0.0.  I u=
sed the following configure command:

LDFLAGS=3D"-L/usr/local/lib" LIBS=3D"-lmass" CC=3Dxlc_r CFLAGS=3D"-qtune=3D=
auto -qarch=3Dauto -qcache=3Dauto -O2 -I/u
sr/local/include" ./configure --with-openssl --disable-nls

After editing src/include/pg_config.h to comment out the HAVE_WCSTOMBS_L (w=
hich configure incorrectly detects on AIX) I ran make check.  This produced=
 the regex error described in the initial report.

I edited the src/Makefile.global to remove all optimization and ran "make c=
lean check", to find that I no longer had the regex error.

As this behaviour pointed to a compiler issue, I  updated the compiler to x=
lcV12.1.0.0 and reran the "make clean check" and the result was no regex er=
ror even with the O2 optimization.

As you may have noticed, I stipulated the use of IBM high-performance maths=
 library, lmass, in the configure command.  Unfortunately, the configure sc=
ript places the -lm in front of -lmass in Makefile.global, which as most of=
 the APIs in lmass are duplicates of those in lm, the lmass routines never =
get called.  Swapping the order of lm and lmass, such that the LIBS line re=
ads:

LIBS =3D -lssl -lcrypto -lz -lreadline -lcurses -lld -lmass -lm

Has not only made the maths faster, but has also removed the float8 roundin=
g error, so the end of the make check now prints:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D shutting down postmaster        =
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 All 126 tests passed.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


  Jez Wain

On 25 Jul 2012, at 19:10, Tom Lane wrote:

> jez.wain@bull.net writes:
>> ***************
>> *** 347,354 ****
>>   three |          f1          |       exp_ln_f1=20=20=20=20=20=20=20
>>  -------+----------------------+-----------------------
>>         |               1004.3 |                1004.3
>> !        | 1.2345678901234e+200 | 1.23456789012338e+200
>> !        | 1.2345678901234e-200 | 1.23456789012339e-200
>>  (3 rows)
>=20
>>  -- cube root
>> --- 347,354 ----
>>   three |          f1          |       exp_ln_f1=20=20=20=20=20=20=20
>>  -------+----------------------+-----------------------
>>         |               1004.3 |                1004.3
>> !        | 1.2345678901234e+200 | 1.23456789012337e+200
>> !        | 1.2345678901234e-200 |  1.2345678901234e-200
>>  (3 rows)
>=20
> This doesn't seem terribly surprising as a platform-specific difference.
>=20
>>  -- T581 regular expression substring (with SQL99's bizarre regexp synta=
x)
>>  SELECT SUBSTRING('abcdefg' FROM 'a#"(b_d)#"%' FOR '#') AS "bcd";
>> ! ERROR:  invalid regular expression: parentheses () not balanced
>> ! CONTEXT:  SQL function "substring" statement 1
>=20
> This however isn't too good.  It suggests a platform-specific issue in
> the regex library, but hard to say what.  Can you dig a little deeper,
> maybe get a stack trace back from the call to errfinish()?  Does
> compiling with -O0 change the behavior?
>=20
>             regards, tom lane