Re: Fwd: Re: Compile fails on AIX 6.1

Sorry, here is my message for the mailing list.

> ---------- Ursprüngliche Nachricht ----------
> Von: "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de>
> An: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Datum: 14. Juli 2014 um 17:23
> Betreff: Re: [BUGS] Compile fails on AIX 6.1
>
> Hello Tom,
>
> > >> PPC what exactly?
>
> PowerPC_POWER5:
> System Model: IBM,9110-51A
> Machine Serial Number: *********
> Processor Type: PowerPC_POWER5
> Processor Implementation Mode: POWER 5
> Processor Version: PV_5_2
> Number Of Processors: 4
> Processor Clock Speed: 1499 MHz
> CPU Type: 64-bit
> Kernel Type: 64-bit
> LPAR Info: 1 **********
> Memory Size: 7936 MB
> Good Memory Size: 7936 MB
> Platform Firmware level: SF240_418
> Firmware Version: IBM,SF240_418
> Full Core: false
>
>
>
> Would it help to use a POWER7 system as followed?
> System Model: IBM,8202-E4C
> Machine Serial Number: *********
> Processor Type: PowerPC_POWER7
> Processor Implementation Mode: POWER 7
> Processor Version: PV_7_Compat
> Number Of Processors: 4
> Processor Clock Speed: 3024 MHz
> CPU Type: 64-bit
> Kernel Type: 64-bit
> LPAR Info: 15 ************
> Memory Size: 8192 MB
> Good Memory Size: 8192 MB
> Platform Firmware level: AL740_126
> Firmware Version: IBM,AL740_100
> Full Core: false
>
>
> > Still, configure should have caught that. Does configure end up
> > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h?
>
> Yes, I HAVE_PPC_LWARX_MUTEX_HINT was defined.
>
> [...]
> /* Define to 1 if you have the POSIX signal interface. */
> #define HAVE_POSIX_SIGNALS /**/
>
> /* Define to 1 if the assembler supports PPC's LWARX mutex hint bit. */
> #define HAVE_PPC_LWARX_MUTEX_HINT 1
>
> /* Define to 1 if you have the `pstat' function. */
> /* #undef HAVE_PSTAT */
>
> /* Define to 1 if the PS_STRINGS thing exists. */
> /* #undef HAVE_PS_STRINGS */
> [...]
>
>
>
> > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set,
> > I'd suggest commenting out the #define for USE_PPC_LWSYNC in
> > pg_config_manual.h and see if it gets better. If that is the
> > answer then I guess we will need a configure-time test for lwsync
> > support after all.
>
> Commenting out USE_PPC_LWSYNC did not help. Also, commenting
> USE_PPC_LWSYNC out and set HAVE_PPC_LWARX_MUTEX_HINT to "0", was
> not successful.
>
>
> Best regards
> Lars
>
>
>
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> hat am 11. Juli 2014 um 16:55 geschrieben:
> >
> >
> > [ please keep the mailing list cc'd ]
> >
> > "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> writes:
> > > Thank you for answering very fast.
> >
> > >> PPC what exactly?
> >
> > > chrp with 64-bit.
> > > MACHINE_ARCHITECTURE: chrp
> > > HARDWARE_BITMODE: 64
> >
> > > Do you need further information regarding the system?
> >
> > Yes, please; CHRP is pretty non-specific as regards the processor
> > generation. However, it's probably *old* since CHRP wasn't too
> > successful according to Wikipedia. If the CPU predates POWER6 or
> > thereabouts, then lack of LWARX hint support in the assembler
> > wouldn't be surprising.
> >
> > Still, configure should have caught that. Does configure end up
> > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h?
> >
> > Hmm ... looking at s_lock.h some more, I wonder if maybe it's
> > LWSYNC and not LWARX that's causing the problem. We currently
> > set USE_PPC_LWSYNC for any PPC64 build (see pg_config_manual.h).
> > IIRC we knew that there were a few machines for which that heuristic
> > would fail, but we didn't think anybody would be using Postgres
> > on them.
> >
> > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set,
> > I'd suggest commenting out the #define for USE_PPC_LWSYNC in
> > pg_config_manual.h and see if it gets better. If that is the
> > answer then I guess we will need a configure-time test for lwsync
> > support after all.
> >
> > >> I think the odds are pretty high that the problem here is that we tried
> > >> to
> > >> use the "mutex hint" option in our PPC spinlock assembly code, and the
> > >> system's assembler doesn't recognize that.
> >
> > > Would it help to use another compiler, e.g. XL C?
> >
> > It'd be worth trying if you have another one at hand, but it's
> > hard to say what the results would be.
> >
> > Note that there's a question here not only as to whether it will
> > build, but whether it will run on your hardware. I'd definitely
> > try "make check" before believing that you have a working build.
> >
> > >> However, we only try to use that option after the configure script has
> > >> confirmed that the syntax is
> > >> accepted, so it's not real clear how you got this result. Perhaps you
> > >> tried to change compilers without redoing the configure run?
> >
> > > No. I did not change the compiler. By the way, I always run "make clean"
> > > and
> > > then re"configure"
> > > to recompile the code.
> >
> > That might be good enough, but personally I always do "make distclean"
> > before reconfiguring.
> >
> > regards, tom lane
>

Hello,
could you try IBM XLC/C++ instead of gcc?

Bye
Rainer

On 15.07.2014 18:51, Lars Ewald (web.de) wrote:
> Sorry, here is my message for the mailing list.
>> ---------- Ursprüngliche Nachricht ----------
>> Von: "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de>
>> An: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> Datum: 14. Juli 2014 um 17:23
>> Betreff: Re: [BUGS] Compile fails on AIX 6.1
>>
>> Hello Tom,
>>
>> > >> PPC what exactly?
>>
>> PowerPC_POWER5:
>> System Model: IBM,9110-51A
>> Machine Serial Number: *********
>> Processor Type: PowerPC_POWER5
>> Processor Implementation Mode: POWER 5
>> Processor Version: PV_5_2
>> Number Of Processors: 4
>> Processor Clock Speed: 1499 MHz
>> CPU Type: 64-bit
>> Kernel Type: 64-bit
>> LPAR Info: 1 **********
>> Memory Size: 7936 MB
>> Good Memory Size: 7936 MB
>> Platform Firmware level: SF240_418
>> Firmware Version: IBM,SF240_418
>> Full Core: false
>>
>>
>>
>> Would it help to use a POWER7 system as followed?
>> System Model: IBM,8202-E4C
>> Machine Serial Number: *********
>> Processor Type: PowerPC_POWER7
>> Processor Implementation Mode: POWER 7
>> Processor Version: PV_7_Compat
>> Number Of Processors: 4
>> Processor Clock Speed: 3024 MHz
>> CPU Type: 64-bit
>> Kernel Type: 64-bit
>> LPAR Info: 15 ************
>> Memory Size: 8192 MB
>> Good Memory Size: 8192 MB
>> Platform Firmware level: AL740_126
>> Firmware Version: IBM,AL740_100
>> Full Core: false
>>
>>
>> > Still, configure should have caught that. Does configure end up
>> > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h?
>>
>> Yes, I HAVE_PPC_LWARX_MUTEX_HINT was defined.
>>
>> [...]
>> /* Define to 1 if you have the POSIX signal interface. */
>> #define HAVE_POSIX_SIGNALS /**/
>>
>> /* Define to 1 if the assembler supports PPC's LWARX mutex hint bit. */
>> #define HAVE_PPC_LWARX_MUTEX_HINT 1
>>
>> /* Define to 1 if you have the `pstat' function. */
>> /* #undef HAVE_PSTAT */
>>
>> /* Define to 1 if the PS_STRINGS thing exists. */
>> /* #undef HAVE_PS_STRINGS */
>> [...]
>>
>>
>>
>> > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set,
>> > I'd suggest commenting out the #define for USE_PPC_LWSYNC in
>> > pg_config_manual.h and see if it gets better. If that is the
>> > answer then I guess we will need a configure-time test for lwsync
>> > support after all.
>>
>> Commenting out USE_PPC_LWSYNC did not help. Also, commenting
>> USE_PPC_LWSYNC out and set HAVE_PPC_LWARX_MUTEX_HINT to "0", was
>> not successful.
>>
>>
>> Best regards
>> Lars
>>
>>
>>
>> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> hat am 11. Juli 2014 um 16:55
>> geschrieben:
>> >
>> >
>> > [ please keep the mailing list cc'd ]
>> >
>> > "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> writes:
>> > > Thank you for answering very fast.
>> >
>> > >> PPC what exactly?
>> >
>> > > chrp with 64-bit.
>> > > MACHINE_ARCHITECTURE: chrp
>> > > HARDWARE_BITMODE: 64
>> >
>> > > Do you need further information regarding the system?
>> >
>> > Yes, please; CHRP is pretty non-specific as regards the processor
>> > generation. However, it's probably *old* since CHRP wasn't too
>> > successful according to Wikipedia. If the CPU predates POWER6 or
>> > thereabouts, then lack of LWARX hint support in the assembler
>> > wouldn't be surprising.
>> >
>> > Still, configure should have caught that. Does configure end up
>> > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h?
>> >
>> > Hmm ... looking at s_lock.h some more, I wonder if maybe it's
>> > LWSYNC and not LWARX that's causing the problem. We currently
>> > set USE_PPC_LWSYNC for any PPC64 build (see pg_config_manual.h).
>> > IIRC we knew that there were a few machines for which that heuristic
>> > would fail, but we didn't think anybody would be using Postgres
>> > on them.
>> >
>> > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set,
>> > I'd suggest commenting out the #define for USE_PPC_LWSYNC in
>> > pg_config_manual.h and see if it gets better. If that is the
>> > answer then I guess we will need a configure-time test for lwsync
>> > support after all.
>> >
>> > >> I think the odds are pretty high that the problem here is that
>> we tried to
>> > >> use the "mutex hint" option in our PPC spinlock assembly code,
>> and the
>> > >> system's assembler doesn't recognize that.
>> >
>> > > Would it help to use another compiler, e.g. XL C?
>> >
>> > It'd be worth trying if you have another one at hand, but it's
>> > hard to say what the results would be.
>> >
>> > Note that there's a question here not only as to whether it will
>> > build, but whether it will run on your hardware. I'd definitely
>> > try "make check" before believing that you have a working build.
>> >
>> > >> However, we only try to use that option after the configure
>> script has
>> > >> confirmed that the syntax is
>> > >> accepted, so it's not real clear how you got this result.
>> Perhaps you
>> > >> tried to change compilers without redoing the configure run?
>> >
>> > > No. I did not change the compiler. By the way, I always run "make
>> clean" and
>> > > then re"configure"
>> > > to recompile the code.
>> >
>> > That might be good enough, but personally I always do "make distclean"
>> > before reconfiguring.
>> >
>> > regards, tom lane
>
>

Hello,
The PostgreSQL release 9.2.7 do build on AIX 7.1 TL3 SP3 on a Power 8
machine without a problem:

bash ./configure \
--with-includes=/opt/freeware/include/readline \
--with-libraries=/opt/freeware/lib \
--prefix=/usr/local/pgsql-9.2.7 \
--with-CC=cc_r \
--without-tcl \
--without-python

../../../src/test/regress/pg_regress --inputdir=.
--temp-install=./tmp_check --top-builddir=../../.. --dlpath=.
--schedule=./parallel_schedule
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 57439 with PID 13369528
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok
parallel group (18 tests): char name int2 oid int4 varchar txid float4
text boolean float8 money int8 bit uuid enum numeric rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
test strings ... ok
test numerology ... ok
parallel group (19 tests): path lseg point circle time timetz box
polygon reltime abstime tinterval comments macaddr interval date tstypes
inet timestamp timestamptz
point ... ok
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
tstypes ... ok
comments ... ok
parallel group (6 tests): geometry horology regex type_sanity oidjoins
opr_sanity
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (2 tests): copyselect copy
copy ... ok
copyselect ... ok
parallel group (2 tests): create_operator create_misc
create_misc ... ok
create_operator ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (10 tests): create_cast create_aggregate
create_function_3 drop_if_exists typed_table vacuum constraints
create_table_like triggers inherit
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (19 tests): select_distinct select_distinct_on
select_implicit select_having select_into random btree_index update case
namespace delete hash_index transactions union portals arrays aggregates
subselect join
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... ok
select_having ... ok
subselect ... ok
union ... ok
case ... ok
join ... ok
aggregates ... ok
transactions ... ok
random ... ok
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
delete ... ok
parallel group (3 tests): security_label collate privileges
privileges ... ok
security_label ... ok
collate ... ok
test misc ... ok
test rules ... ok
parallel group (16 tests): portals_p2 combocid tsdicts xmlmap
advisory_lock json guc dependency functional_deps cluster tsearch
select_views foreign_data window foreign_key bitmapops
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... ok
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
parallel group (18 tests): limit conversion prepare plancache xml copy2
temp returning sequence polymorphism with domain without_oid rowtypes
rangefuncs largeobject truncate alter_table
plancache ... ok
limit ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... ok
xml ... ok
test stats ... ok
============== shutting down postmaster ==============

=======================
All 129 tests passed.
=======================

Bye
Rainer

Rainer Tammer <pgsql(at)spg(dot)schulergroup(dot)com> writes:
> The PostgreSQL release 9.2.7 do build on AIX 7.1 TL3 SP3 on a Power 8
> machine without a problem:

That's good news! I hope you will set up a buildfarm member so we can
make sure it keeps working.

regards, tom lane

Hello,
This was a first test in that direction...

I have tried to run a parallel build, but that was not successful.
Should a parallel build (make -j n; n > 1) work?

Bye
Rainer

On 24.07.2014 19:22, Tom Lane wrote:
> Rainer Tammer <pgsql(at)spg(dot)schulergroup(dot)com> writes:
>> The PostgreSQL release 9.2.7 do build on AIX 7.1 TL3 SP3 on a Power 8
>> machine without a problem:
> That's good news! I hope you will set up a buildfarm member so we can
> make sure it keeps working.
>
> regards, tom lane
>
>

Rainer Tammer <pgsql(at)spg(dot)schulergroup(dot)com> writes:
> I have tried to run a parallel build, but that was not successful.
> Should a parallel build (make -j n; n > 1) work?

Yes; I routinely do -j8 or so, and I think many of the buildfarm members
are configured to use -j with various multipliers. Having said that,
we have seen (and worked around) some bugs in the parallel-build support
in some versions of gmake. There might be more :-(. What make version
are you using, and what failure did you see exactly?

(Of course, you could configure a buildfarm member with -j 1 as a
first step, and worry about parallelism later ...)

regards, tom lane

Hello,
I have used an old version:

root(at)aixtest06 rc:0 # gmake --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

But I can upgrade to a new version, that's no problem.
Which version do you recommend?

Bye
Rainer

On 25.07.2014 08:48, Tom Lane wrote:
> Rainer Tammer <pgsql(at)spg(dot)schulergroup(dot)com> writes:
>> I have tried to run a parallel build, but that was not successful.
>> Should a parallel build (make -j n; n > 1) work?
> Yes; I routinely do -j8 or so, and I think many of the buildfarm members
> are configured to use -j with various multipliers. Having said that,
> we have seen (and worked around) some bugs in the parallel-build support
> in some versions of gmake. There might be more :-(. What make version
> are you using, and what failure did you see exactly?
>
> (Of course, you could configure a buildfarm member with -j 1 as a
> first step, and worry about parallelism later ...)
>
> regards, tom lane
>
>

Hello Tom,

today I was able to do some tests compiling Postgres on our AIX machine.

And...it worked! :-) Configuring without spinlocks and readline worked fine for
me and did not abort after compiling xlog.o/xlog.c.
Any ideas why it does not work with spinlocks?

Best regards,
Lars

p. s. Compiling against xlC did not work. I think our xlC installation is a bit
curious. :-(

> "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> hat am 15. Juli 2014 um
> 18:51 geschrieben:
>
> Sorry, here is my message for the mailing list.
>
> > > ---------- Ursprüngliche Nachricht ----------
> > Von: "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de>
> > An: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> > Datum: 14. Juli 2014 um 17:23
> > Betreff: Re: [BUGS] Compile fails on AIX 6.1
> >
> > Hello Tom,
> >
> > > >> PPC what exactly?
> >
> > PowerPC_POWER5:
> > System Model: IBM,9110-51A
> > Machine Serial Number: *********
> > Processor Type: PowerPC_POWER5
> > Processor Implementation Mode: POWER 5
> > Processor Version: PV_5_2
> > Number Of Processors: 4
> > Processor Clock Speed: 1499 MHz
> > CPU Type: 64-bit
> > Kernel Type: 64-bit
> > LPAR Info: 1 **********
> > Memory Size: 7936 MB
> > Good Memory Size: 7936 MB
> > Platform Firmware level: SF240_418
> > Firmware Version: IBM,SF240_418
> > Full Core: false
> >
> >
> >
> > Would it help to use a POWER7 system as followed?
> > System Model: IBM,8202-E4C
> > Machine Serial Number: *********
> > Processor Type: PowerPC_POWER7
> > Processor Implementation Mode: POWER 7
> > Processor Version: PV_7_Compat
> > Number Of Processors: 4
> > Processor Clock Speed: 3024 MHz
> > CPU Type: 64-bit
> > Kernel Type: 64-bit
> > LPAR Info: 15 ************
> > Memory Size: 8192 MB
> > Good Memory Size: 8192 MB
> > Platform Firmware level: AL740_126
> > Firmware Version: IBM,AL740_100
> > Full Core: false
> >
> >
> > > Still, configure should have caught that. Does configure end up
> > > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h?
> >
> > Yes, I HAVE_PPC_LWARX_MUTEX_HINT was defined.
> >
> > [...]
> > /* Define to 1 if you have the POSIX signal interface. */
> > #define HAVE_POSIX_SIGNALS /**/
> >
> > /* Define to 1 if the assembler supports PPC's LWARX mutex hint bit. */
> > #define HAVE_PPC_LWARX_MUTEX_HINT 1
> >
> > /* Define to 1 if you have the `pstat' function. */
> > /* #undef HAVE_PSTAT */
> >
> > /* Define to 1 if the PS_STRINGS thing exists. */
> > /* #undef HAVE_PS_STRINGS */
> > [...]
> >
> >
> >
> > > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set,
> > > I'd suggest commenting out the #define for USE_PPC_LWSYNC in
> > > pg_config_manual.h and see if it gets better. If that is the
> > > answer then I guess we will need a configure-time test for lwsync
> > > support after all.
> >
> > Commenting out USE_PPC_LWSYNC did not help. Also, commenting
> > USE_PPC_LWSYNC out and set HAVE_PPC_LWARX_MUTEX_HINT to "0", was
> > not successful.
> >
> >
> > Best regards
> > Lars
> >
> >
> >
> > > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> hat am 11. Juli 2014 um 16:55 geschrieben:
> > >
> > >
> > > [ please keep the mailing list cc'd ]
> > >
> > > "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> writes:
> > > > Thank you for answering very fast.
> > >
> > > >> PPC what exactly?
> > >
> > > > chrp with 64-bit.
> > > > MACHINE_ARCHITECTURE: chrp
> > > > HARDWARE_BITMODE: 64
> > >
> > > > Do you need further information regarding the system?
> > >
> > > Yes, please; CHRP is pretty non-specific as regards the processor
> > > generation. However, it's probably *old* since CHRP wasn't too
> > > successful according to Wikipedia. If the CPU predates POWER6 or
> > > thereabouts, then lack of LWARX hint support in the assembler
> > > wouldn't be surprising.
> > >
> > > Still, configure should have caught that. Does configure end up
> > > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h?
> > >
> > > Hmm ... looking at s_lock.h some more, I wonder if maybe it's
> > > LWSYNC and not LWARX that's causing the problem. We currently
> > > set USE_PPC_LWSYNC for any PPC64 build (see pg_config_manual.h).
> > > IIRC we knew that there were a few machines for which that heuristic
> > > would fail, but we didn't think anybody would be using Postgres
> > > on them.
> > >
> > > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set,
> > > I'd suggest commenting out the #define for USE_PPC_LWSYNC in
> > > pg_config_manual.h and see if it gets better. If that is the
> > > answer then I guess we will need a configure-time test for lwsync
> > > support after all.
> > >
> > > >> I think the odds are pretty high that the problem here is that we
> > > >> tried to
> > > >> use the "mutex hint" option in our PPC spinlock assembly code, and
> > > >> the
> > > >> system's assembler doesn't recognize that.
> > >
> > > > Would it help to use another compiler, e.g. XL C?
> > >
> > > It'd be worth trying if you have another one at hand, but it's
> > > hard to say what the results would be.
> > >
> > > Note that there's a question here not only as to whether it will
> > > build, but whether it will run on your hardware. I'd definitely
> > > try "make check" before believing that you have a working build.
> > >
> > > >> However, we only try to use that option after the configure script
> > > >> has
> > > >> confirmed that the syntax is
> > > >> accepted, so it's not real clear how you got this result. Perhaps you
> > > >> tried to change compilers without redoing the configure run?
> > >
> > > > No. I did not change the compiler. By the way, I always run "make
> > > > clean" and
> > > > then re"configure"
> > > > to recompile the code.
> > >
> > > That might be good enough, but personally I always do "make distclean"
> > > before reconfiguring.
> > >
> > > regards, tom lane
> >
> > >
>
>

"Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> writes:
> Hello Tom,
> today I was able to do some tests compiling Postgres on our AIX machine.

> And...it worked! :-) Configuring without spinlocks and readline worked fine for
> me and did not abort after compiling xlog.o/xlog.c.
> Any ideas why it does not work with spinlocks?

Well, spinlocks are what uses the assembler code that you're having
trouble with.

Note that while you can build with --disable-spinlocks, performance is
not likely to be acceptable. We don't really consider a platform
supported unless it's got working spinlocks.

regards, tom lane

Hello,
What PostgreSQl exact version are you trying to compile?
I like to test this with the IBM compiler.

Bye
Rainer

On 26.07.2014 00:32, Tom Lane wrote:
> "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> writes:
>> Hello Tom,
>> today I was able to do some tests compiling Postgres on our AIX machine.
>> And...it worked! :-) Configuring without spinlocks and readline worked fine for
>> me and did not abort after compiling xlog.o/xlog.c.
>> Any ideas why it does not work with spinlocks?
> Well, spinlocks are what uses the assembler code that you're having
> trouble with.
>
> Note that while you can build with --disable-spinlocks, performance is
> not likely to be acceptable. We don't really consider a platform
> supported unless it's got working spinlocks.
>
> regards, tom lane
>
>

Hello,
PostgreSQL 9.3.5 does pass all regression tests on AIX 7.1 TL3 SP3:

bash ./configure \
--with-includes=/opt/freeware/include/readline \
--with-libraries=/opt/freeware/lib \
--prefix=/usr/local/pgsql-9.3.5 \
--with-CC=cc_r \
--without-tcl \
--without-python

../../../src/test/regress/pg_regress --inputdir=.
--temp-install=./tmp_check --top-builddir=../../.. --dlpath=.
--schedule=./parallel_schedule
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 57537 with PID 6357156
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok
parallel group (18 tests): name char oid float4 float8 int2 int4
boolean varchar text money int8 txid bit uuid enum numeric rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
test strings ... ok
test numerology ... ok
parallel group (19 tests): lseg point path box polygon circle time
comments timetz reltime abstime macaddr tinterval tstypes date interval
inet timestamp timestamptz
point ... ok
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
tstypes ... ok
comments ... ok
parallel group (6 tests): geometry regex horology type_sanity oidjoins
opr_sanity
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (2 tests): copyselect copy
copy ... ok
copyselect ... ok
parallel group (2 tests): create_operator create_misc
create_misc ... ok
create_operator ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (11 tests): create_aggregate create_cast
create_function_3 drop_if_exists typed_table vacuum constraints
create_table_like triggers updatable_views inherit
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
updatable_views ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (20 tests): select_distinct_on select_distinct
select_implicit select_into select_having case update btree_index random
namespace delete hash_index transactions portals union subselect
aggregates arrays join prepared_xacts
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... ok
select_having ... ok
subselect ... ok
union ... ok
case ... ok
join ... ok
aggregates ... ok
transactions ... ok
random ... ok
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
prepared_xacts ... ok
delete ... ok
parallel group (4 tests): security_label collate privileges matview
privileges ... ok
security_label ... ok
collate ... ok
matview ... ok
parallel group (3 tests): psql alter_generic misc
alter_generic ... ok
misc ... ok
psql ... ok
test rules ... ok
test event_trigger ... ok
parallel group (16 tests): portals_p2 combocid tsdicts advisory_lock
dependency xmlmap guc json functional_deps select_views cluster window
tsearch foreign_data foreign_key bitmapops
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... ok
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
parallel group (19 tests): limit plancache conversion prepare xml
returning temp polymorphism copy2 sequence without_oid with rowtypes
domain largeobject rangefuncs truncate alter_table plpgsql
plancache ... ok
limit ... ok
plpgsql ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... ok
xml ... ok
test stats ... ok
============== shutting down postmaster ==============

=======================
All 136 tests passed.
=======================

Bye
Rainer

On 25.07.2014 09:22, Rainer Tammer wrote:
> Hello,
> I have used an old version:
>
> root(at)aixtest06 rc:0 # gmake --version
> GNU Make 3.80
> Copyright (C) 2002 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>
> But I can upgrade to a new version, that's no problem.
> Which version do you recommend?
>
> Bye
> Rainer
>
> On 25.07.2014 08:48, Tom Lane wrote:
>> Rainer Tammer <pgsql(at)spg(dot)schulergroup(dot)com> writes:
>>> I have tried to run a parallel build, but that was not successful.
>>> Should a parallel build (make -j n; n > 1) work?
>> Yes; I routinely do -j8 or so, and I think many of the buildfarm members
>> are configured to use -j with various multipliers. Having said that,
>> we have seen (and worked around) some bugs in the parallel-build support
>> in some versions of gmake. There might be more :-(. What make version
>> are you using, and what failure did you see exactly?
>>
>> (Of course, you could configure a buildfarm member with -j 1 as a
>> first step, and worry about parallelism later ...)
>>
>> regards, tom lane
>>
>>
>
>

Hello,
PostgreSQL 9.4 Beta 2 does pass all regression tests on AIX 7.1 TL3 SP3:

bash ./configure \
--with-includes=/opt/freeware/include/readline \
--with-libraries=/opt/freeware/lib \
--prefix=/usr/local/pgsql-9.4.b2 \
--with-CC=cc_r \ <-- IBM XLC/C++ V12
--without-tcl \
--without-python

../../../src/test/regress/pg_regress --inputdir=.
--temp-install=./tmp_check --top-builddir=../../.. --dlpath=.
--schedule=./parallel_schedule
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 57632 with PID 11468860
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok
parallel group (20 tests): name int4 int2 oid varchar char text float4
float8 regproc money boolean txid pg_lsn int8 bit uuid enum numeric
rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
pg_lsn ... ok
regproc ... ok
test strings ... ok
test numerology ... ok
parallel group (20 tests): line lseg point path box polygon circle time
timetz abstime comments date tinterval reltime interval tstypes macaddr
inet timestamp timestamptz
point ... ok
lseg ... ok
line ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
tstypes ... ok
comments ... ok
parallel group (6 tests): geometry regex horology type_sanity oidjoins
opr_sanity
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (2 tests): copyselect copy
copy ... ok
copyselect ... ok
parallel group (2 tests): create_operator create_misc
create_misc ... ok
create_operator ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (11 tests): create_cast create_aggregate
create_function_3 drop_if_exists typed_table vacuum constraints
create_table_like triggers inherit updatable_views
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
updatable_views ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (20 tests): select_distinct select_distinct_on
select_implicit select_having select_into case btree_index random update
hash_index delete namespace transactions union portals subselect arrays
aggregates join prepared_xacts
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... ok
select_having ... ok
subselect ... ok
union ... ok
case ... ok
join ... ok
aggregates ... ok
transactions ... ok
random ... ok
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
prepared_xacts ... ok
delete ... ok
parallel group (6 tests): lock security_label replica_identity collate
privileges matview
privileges ... ok
security_label ... ok
collate ... ok
matview ... ok
lock ... ok
replica_identity ... ok
parallel group (4 tests): async psql alter_generic misc
alter_generic ... ok
misc ... ok
psql ... ok
async ... ok
test rules ... ok
test event_trigger ... ok
parallel group (18 tests): portals_p2 combocid tsdicts guc
advisory_lock xmlmap dependency json functional_deps cluster
select_views tsearch jsonb foreign_data window foreign_key bitmapops
indirect_toast
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... ok
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
jsonb ... ok
indirect_toast ... ok
parallel group (19 tests): limit plancache conversion prepare xml
returning temp copy2 sequence polymorphism without_oid with rowtypes
domain truncate rangefuncs largeobject alter_table plpgsql
plancache ... ok
limit ... ok
plpgsql ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... ok
xml ... ok
test stats ... ok
============== shutting down postmaster ==============

=======================
All 144 tests passed.
=======================

Bye
Rainer

On 25.07.2014 09:22, Rainer Tammer wrote:
> Hello,
> I have used an old version:
>
> root(at)aixtest06 rc:0 # gmake --version
> GNU Make 3.80
> Copyright (C) 2002 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>
> But I can upgrade to a new version, that's no problem.
> Which version do you recommend?
>
> Bye
> Rainer
>
> On 25.07.2014 08:48, Tom Lane wrote:
>> Rainer Tammer <pgsql(at)spg(dot)schulergroup(dot)com> writes:
>>> I have tried to run a parallel build, but that was not successful.
>>> Should a parallel build (make -j n; n > 1) work?
>> Yes; I routinely do -j8 or so, and I think many of the buildfarm members
>> are configured to use -j with various multipliers. Having said that,
>> we have seen (and worked around) some bugs in the parallel-build support
>> in some versions of gmake. There might be more :-(. What make version
>> are you using, and what failure did you see exactly?
>>
>> (Of course, you could configure a buildfarm member with -j 1 as a
>> first step, and worry about parallelism later ...)
>>
>> regards, tom lane
>>
>>
>
>

Hello,
PostgreSQL 9.3.5 does pass all regression tests on AIX 7.1 TL3 SP3:

bash ./configure \
--with-includes=/opt/freeware/include/readline \
--with-libraries=/opt/freeware/lib \
--prefix=/usr/local/pgsql-9.3.5 \
--with-CC=cc_r \ <-- IBM XLC/C++ V12
--without-tcl \
--without-python

../../../src/test/regress/pg_regress --inputdir=.
--temp-install=./tmp_check --top-builddir=../../.. --dlpath=.
--schedule=./parallel_schedule
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 57537 with PID 6357156
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok
parallel group (18 tests): name char oid float4 float8 int2 int4
boolean varchar text money int8 txid bit uuid enum numeric rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
test strings ... ok
test numerology ... ok
parallel group (19 tests): lseg point path box polygon circle time
comments timetz reltime abstime macaddr tinterval tstypes date interval
inet timestamp timestamptz
point ... ok
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
tstypes ... ok
comments ... ok
parallel group (6 tests): geometry regex horology type_sanity oidjoins
opr_sanity
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (2 tests): copyselect copy
copy ... ok
copyselect ... ok
parallel group (2 tests): create_operator create_misc
create_misc ... ok
create_operator ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (11 tests): create_aggregate create_cast
create_function_3 drop_if_exists typed_table vacuum constraints
create_table_like triggers updatable_views inherit
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
updatable_views ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (20 tests): select_distinct_on select_distinct
select_implicit select_into select_having case update btree_index random
namespace delete hash_index transactions portals union subselect
aggregates arrays join prepared_xacts
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... ok
select_having ... ok
subselect ... ok
union ... ok
case ... ok
join ... ok
aggregates ... ok
transactions ... ok
random ... ok
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
prepared_xacts ... ok
delete ... ok
parallel group (4 tests): security_label collate privileges matview
privileges ... ok
security_label ... ok
collate ... ok
matview ... ok
parallel group (3 tests): psql alter_generic misc
alter_generic ... ok
misc ... ok
psql ... ok
test rules ... ok
test event_trigger ... ok
parallel group (16 tests): portals_p2 combocid tsdicts advisory_lock
dependency xmlmap guc json functional_deps select_views cluster window
tsearch foreign_data foreign_key bitmapops
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... ok
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
parallel group (19 tests): limit plancache conversion prepare xml
returning temp polymorphism copy2 sequence without_oid with rowtypes
domain largeobject rangefuncs truncate alter_table plpgsql
plancache ... ok
limit ... ok
plpgsql ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... ok
xml ... ok
test stats ... ok
============== shutting down postmaster ==============

=======================
All 136 tests passed.
=======================

Bye
Rainer

On 25.07.2014 09:22, Rainer Tammer wrote:
> Hello,
> I have used an old version:
>
> root(at)aixtest06 rc:0 # gmake --version
> GNU Make 3.80
> Copyright (C) 2002 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>
> But I can upgrade to a new version, that's no problem.
> Which version do you recommend?
>
> Bye
> Rainer
>
> On 25.07.2014 08:48, Tom Lane wrote:
>> Rainer Tammer <pgsql(at)spg(dot)schulergroup(dot)com> writes:
>>> I have tried to run a parallel build, but that was not successful.
>>> Should a parallel build (make -j n; n > 1) work?
>> Yes; I routinely do -j8 or so, and I think many of the buildfarm members
>> are configured to use -j with various multipliers. Having said that,
>> we have seen (and worked around) some bugs in the parallel-build support
>> in some versions of gmake. There might be more :-(. What make version
>> are you using, and what failure did you see exactly?
>>
>> (Of course, you could configure a buildfarm member with -j 1 as a
>> first step, and worry about parallelism later ...)
>>
>> regards, tom lane
>>
>>
>
>

Hello Tom

> We don't really consider a platform
> supported unless it's got working spinlocks.

I am a little bit confused about that.

On the page "supported platforms" there is written that PowerPC or PowerPC 64 is
a supported
platform, so that I can compile postgres WITH spinlocks.
http://www.postgresql.org/docs/9.3/static/supported-platforms.html

Or is there a problem on the specific machine? Or is there something disabled
in the kernel?

Best regards
Lars

> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> hat am 26. Juli 2014 um 00:32 geschrieben:
>
>
> "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> writes:
> > Hello Tom,
> > today I was able to do some tests compiling Postgres on our AIX machine.
>
> > And...it worked! :-) Configuring without spinlocks and readline worked fine
> > for
> > me and did not abort after compiling xlog.o/xlog.c.
> > Any ideas why it does not work with spinlocks?
>
> Well, spinlocks are what uses the assembler code that you're having
> trouble with.
>
> Note that while you can build with --disable-spinlocks, performance is
> not likely to be acceptable. We don't really consider a platform
> supported unless it's got working spinlocks.
>
> regards, tom lane

Hello Rainer,

> What PostgreSQl exact version are you trying to compile?
9.3.4

Bye,
Lars

> Rainer Tammer <pgsql(at)spg(dot)schulergroup(dot)com> hat am 28. Juli 2014 um 07:58
> geschrieben:
>
>
> Hello,
> What PostgreSQl exact version are you trying to compile?
> I like to test this with the IBM compiler.
>
> Bye
> Rainer
>
> On 26.07.2014 00:32, Tom Lane wrote:
> > "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> writes:
> >> Hello Tom,
> >> today I was able to do some tests compiling Postgres on our AIX machine.
> >> And...it worked! :-) Configuring without spinlocks and readline worked fine
> >> for
> >> me and did not abort after compiling xlog.o/xlog.c.
> >> Any ideas why it does not work with spinlocks?
> > Well, spinlocks are what uses the assembler code that you're having
> > trouble with.
> >
> > Note that while you can build with --disable-spinlocks, performance is
> > not likely to be acceptable. We don't really consider a platform
> > supported unless it's got working spinlocks.
> >
> > regards, tom lane
> >
> >
>

"Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> writes:
>> We don't really consider a platform
>> supported unless it's got working spinlocks.

> I am a little bit confused about that.

Well, so are we.

> Or is there a problem on the specific machine? Or is there something disabled
> in the kernel?

It seems to be a toolchain problem, ie, compiler or assembler doing
something unexpected with our PPC spinlock code. But we don't really
have enough info to diagnose. I can think of a bunch of ways it might
have gone wrong, but we seem to have eliminated all those theories :-(

regards, tom lane

Hello,
Please try the IBM C/C++ compiler.

Could you use 9.3.5? This is the latest 9.3.x version.
I have tested 9.3.5 on AIX 6.1 and AIX 7.1 without a compilation/test
failure.

Please could you post your exact ./configure call?

Bye
Rainer

On 01.08.2014 19:59, Lars Ewald (web.de) wrote:
> Hello Tom
>
> > We don't really consider a platform
> > supported unless it's got working spinlocks.
>
> I am a little bit confused about that.
>
> On the page "supported platforms" there is written that PowerPC or
> PowerPC 64 is a supported
> platform, so that I can compile postgres WITH spinlocks.
> http://www.postgresql.org/docs/9.3/static/supported-platforms.html
>
> Or is there a problem on the specific machine? Or is there something
> disabled
> in the kernel?
>
> Best regards
> Lars
>
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> hat am 26. Juli 2014 um 00:32 geschrieben:
> >
> >
> > "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> writes:
> > > Hello Tom,
> > > today I was able to do some tests compiling Postgres on our AIX
> machine.
> >
> > > And...it worked! :-) Configuring without spinlocks and readline
> worked fine for
> > > me and did not abort after compiling xlog.o/xlog.c.
> > > Any ideas why it does not work with spinlocks?
> >
> > Well, spinlocks are what uses the assembler code that you're having
> > trouble with.
> >
> > Note that while you can build with --disable-spinlocks, performance is
> > not likely to be acceptable. We don't really consider a platform
> > supported unless it's got working spinlocks.
> >
> > regards, tom lane

A year ago we had a thread about assembler syntax errors on AIX, but it
died off when the original complainant stopped responding. I was recently
contacted off-list by Steve Underwood, who was seeing the same symptoms
on AIX 7.1. After some investigation, we found that the problem is that
IBM's assembler doesn't understand the "local symbol" notation supported
by the GNU assembler ("bne 1f" referencing the next occurrence of "1:").
So s_lock.h's PowerPC assembly code works if you have gcc configured to
use gas as backend, but not if it's configured to use the native AIX
assembler. Steve says the latter configuration is pretty common.

Curiously, our build goes through just fine if you use the gcc 4.2.0
build available from IBM's website. But it turns out it's using the
"generic AIX" stanza of s_lock.h, ie _check_lock(), rather than the
lwarx assembly code. AFAICS this must mean that that gcc build does
not define __ppc__ --- very weird. But a bit offtopic.

So now that we know what is happening, what do we want to do about it?
AFAICS there are two plausible ways to fix it:

1. Add a configure-time test to see if the assembler supports local
symbols. If not, don't try to use the lwarx assembly stanza, but let
it fall through to using _check_lock(). This would be simple but
there would presumably be some performance hit.

2. Don't rely on local symbols in the PPC spinlock assembly code. This
is a bit ugly, because the only way to do that is to hard-code branch
offsets, as in the attached draft patch. If there were any likelihood
that we'd be changing the PPC spinlock code in future, I would regard
this as unmaintainable ... but really, that code is pretty static.
So I think this is a viable alternative.

Comments?

regards, tom lane

On Thu, Aug 27, 2015 at 10:36:46AM -0400, Tom Lane wrote:
> the problem is that
> IBM's assembler doesn't understand the "local symbol" notation supported
> by the GNU assembler ("bne 1f" referencing the next occurrence of "1:").
> So s_lock.h's PowerPC assembly code works if you have gcc configured to
> use gas as backend, but not if it's configured to use the native AIX
> assembler. Steve says the latter configuration is pretty common.

These days, the latter configuration is all but universal. Per the GCC
installation instructions, "The GNU Assembler has not been updated to support
AIX 6 or AIX 7."

> So now that we know what is happening, what do we want to do about it?
> AFAICS there are two plausible ways to fix it:
>
> 1. Add a configure-time test to see if the assembler supports local
> symbols. If not, don't try to use the lwarx assembly stanza, but let
> it fall through to using _check_lock(). This would be simple but
> there would presumably be some performance hit.
>
> 2. Don't rely on local symbols in the PPC spinlock assembly code. This
> is a bit ugly, because the only way to do that is to hard-code branch
> offsets, as in the attached draft patch. If there were any likelihood
> that we'd be changing the PPC spinlock code in future, I would regard
> this as unmaintainable ... but really, that code is pretty static.
> So I think this is a viable alternative.

A third option is to use __sync intrinsics, like we do on ARM. I like (2).

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Thu, Aug 27, 2015 at 10:36:46AM -0400, Tom Lane wrote:
>> the problem is that
>> IBM's assembler doesn't understand the "local symbol" notation supported
>> by the GNU assembler ("bne 1f" referencing the next occurrence of "1:").
>> So s_lock.h's PowerPC assembly code works if you have gcc configured to
>> use gas as backend, but not if it's configured to use the native AIX
>> assembler. Steve says the latter configuration is pretty common.

> These days, the latter configuration is all but universal. Per the GCC
> installation instructions, "The GNU Assembler has not been updated to support
> AIX 6 or AIX 7."

Ouch. I'm surprised we've not gotten more complaints.

>> 2. Don't rely on local symbols in the PPC spinlock assembly code. This
>> is a bit ugly, because the only way to do that is to hard-code branch
>> offsets, as in the attached draft patch. If there were any likelihood
>> that we'd be changing the PPC spinlock code in future, I would regard
>> this as unmaintainable ... but really, that code is pretty static.
>> So I think this is a viable alternative.

> A third option is to use __sync intrinsics, like we do on ARM. I like (2).

I've been waiting to hear confirmation from Steve that the proposed patch
works with IBM's assembler. (For all I know, it uses "*" rather than ".",
or some other randomness.) He's not responded yet though. Are you in
a position to test the patch?

regards, tom lane

I wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
>> On Thu, Aug 27, 2015 at 10:36:46AM -0400, Tom Lane wrote:
>>> 2. Don't rely on local symbols in the PPC spinlock assembly code.

>> A third option is to use __sync intrinsics, like we do on ARM. I like (2).

> I've been waiting to hear confirmation from Steve that the proposed patch
> works with IBM's assembler. (For all I know, it uses "*" rather than ".",
> or some other randomness.) He's not responded yet though. Are you in
> a position to test the patch?

Steve got back to me with the news that AIX's assembler thinks that "."
is an ordinary symbol, not the current location. Some googling says that
that assembler likes "$" for current location. I did a quick check on my
oldest OS X PPC box, and it seems to be happy with "$" as well, so maybe
we can use that --- though I see nothing about "$" in the GNU Assembler
manual, which makes me a bit worried about whether it works on all PPC
systems.

regards, tom lane

I wrote:
> ... that assembler likes "$" for current location. I did a quick check on my
> oldest OS X PPC box, and it seems to be happy with "$" as well, so maybe
> we can use that --- though I see nothing about "$" in the GNU Assembler
> manual, which makes me a bit worried about whether it works on all PPC
> systems.

A look into the current gas sources finds this in config/tc-ppc.h:

/* $ is used to refer to the current location. */
#define DOLLAR_DOT

so apparently this is indeed standard behavior for gas on PPC. There's
no indication that you could turn it off without manually hacking this
config header.

Source code access to one's tools is so pleasant ...

regards, tom lane

On Fri, Aug 28, 2015 at 09:58:46AM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > On Thu, Aug 27, 2015 at 10:36:46AM -0400, Tom Lane wrote:
> >> So s_lock.h's PowerPC assembly code works if you have gcc configured to
> >> use gas as backend, but not if it's configured to use the native AIX
> >> assembler. Steve says the latter configuration is pretty common.
>
> > These days, the latter configuration is all but universal. Per the GCC
> > installation instructions, "The GNU Assembler has not been updated to support
> > AIX 6 or AIX 7."
>
> Ouch. I'm surprised we've not gotten more complaints.

That surprised me, too. Perhaps almost everyone has used either xlc or that
IBM-provided gcc you wrote about.

> >> 2. Don't rely on local symbols in the PPC spinlock assembly code.

> > A third option is to use __sync intrinsics, like we do on ARM. I like (2).
>
> I've been waiting to hear confirmation from Steve that the proposed patch
> works with IBM's assembler. (For all I know, it uses "*" rather than ".",
> or some other randomness.) He's not responded yet though. Are you in
> a position to test the patch?

I tested a gcc 64-bit build. Consistent with your followup, "b .+12" doesn't
build, but "b $+12" builds and passes "make check". I am attaching the exact
diff I tested.

On GNU/Linux ppc, I get the same opcodes before and after the change.

Noah Misch <noah(at)leadboat(dot)com> writes:
> I tested a gcc 64-bit build. Consistent with your followup, "b .+12" doesn't
> build, but "b $+12" builds and passes "make check". I am attaching the exact
> diff I tested.
> On GNU/Linux ppc, I get the same opcodes before and after the change.

Thanks for checking! I have some other business to attend to today, but
I'll get this committed soon.

Please consider spinning up a gcc buildfarm critter on the machine running
hornet & mandrill.

regards, tom lane