BUG #13498: make check failures
The following bug has been logged on the website:
Bug reference: 13498
Logged by: Pete Lancashire
Email address: pete@petelancashire.com
PostgreSQL version: 9.4.4
Operating system: AIX
Description:
Environment
oslevel -s 7100-03-03-1415
/usr/bin/ld: LD 7.1.3(4/1/14)
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
Version: 12.01.0000.0000
Driver Version: 12.01(C/C++) Level: 120315
C Front End Version: 12.01(C/C++) Level: 120322
C++ Front End Version: 12.01(C/C++) Level: 120315
High-Level Optimizer Version: 12.01(C/C++) and 14.01(Fortran) Level: 120315
Low-Level Optimizer Version: 12.01(C/C++) and 14.01(Fortran) Level: 120321
OBJECT_MODE 64
CC xlc_r
CXX xlc++_r
LDFLAGS -L/usr/local/lib64 -L/usr/local/lib -bmaxdata:0x80000000 -brtl
CFLAGS <-O see below> -qmaxmem=-1 -qarch=pwr7 -qtune=pwr7 -qcache=auto
-I/usr/local/include
CXXFLAGS=$CFLAGS
LDPATH /usr/local/lib:/usr/lib
make runs w/o errors
make check
-O2 passes w/o errors
-O3 with or without -strict fails
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 ... FAILED
parallel group (20 tests): select_distinct_on select_distinct select_having
select_implicit btree_index random hash_index delete namespace case update
select_into transactions union portals subselect arrays aggregates join
prepared_xacts
aggregates ... FAILED
I have regression.diffs and .out
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
pete@petelancashire.com writes:
make check
-O2 passes w/o errors
-O3 with or without -strict fails
Presumably what is happening here (and also in your followon #13499)
is that xlc with higher optimization levels generates bad code. Whether
this is a compiler bug, or is traceable to a valid deficiency in our code,
is really impossible to tell for anyone without access to that compiler
(and even with access, it might be a lot of work). If you want to trace
it down I'm afraid it's going to be pretty much your responsibility to do
it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I'll agree to a point.
I'll see what else I can find out. Is there an option to make the test more
verbose ? And I'll see what I can get out of the what changes the
optimization does
Its a pitty, I'd love to get postgresql screaming on a P-series. In other
things level 3 can increase the performance 20-30% and level 5 in one
program that does a lot of array searching 50-70%
On Mon, Jul 13, 2015 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
pete@petelancashire.com writes:
make check
-O2 passes w/o errors
-O3 with or without -strict failsPresumably what is happening here (and also in your followon #13499)
is that xlc with higher optimization levels generates bad code. Whether
this is a compiler bug, or is traceable to a valid deficiency in our code,
is really impossible to tell for anyone without access to that compiler
(and even with access, it might be a lot of work). If you want to trace
it down I'm afraid it's going to be pretty much your responsibility to do
it.regards, tom lane
On 2015-07-13 14:15:58 -0700, Pete Lancashire wrote:
I'll agree to a point.
I'll see what else I can find out. Is there an option to make the test more
verbose ? And I'll see what I can get out of the what changes the
optimization doesIts a pitty, I'd love to get postgresql screaming on a P-series. In other
things level 3 can increase the performance 20-30% and level 5 in one
program that does a lot of array searching 50-70%
You could try with gcc -O3...
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I dont at this time have GCC installed. The goal was to be able to take
advantage of optimization that understood the actual hardware
by setting -qarch=pwr7 -qtune=pwr7 the xlc compiler starting at -O3 up to
-O5 make optimization decisions that are unique to the hardware, in this
case the p7 architecture,
O4 and O5 then take it quite a but more, O5 can take what compiles in a a
few second to more then 10 minutes.
It is pretty rare that -O3 used with -strict will break anything, actually
this is the first time I've seen it happen.
On Mon, Jul 13, 2015 at 2:20 PM, Andres Freund <andres@anarazel.de> wrote:
Show quoted text
On 2015-07-13 14:15:58 -0700, Pete Lancashire wrote:
I'll agree to a point.
I'll see what else I can find out. Is there an option to make the test
more
verbose ? And I'll see what I can get out of the what changes the
optimization doesIts a pitty, I'd love to get postgresql screaming on a P-series. In other
things level 3 can increase the performance 20-30% and level 5 in one
program that does a lot of array searching 50-70%You could try with gcc -O3...