Обсуждение: BUG #13498: make check failures

Поиск
Список
Период
Сортировка

BUG #13498: make check failures

От
pete@petelancashire.com
Дата:
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

Re: BUG #13498: make check failures

От
Tom Lane
Дата:
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

Re: BUG #13498: make check failures

От
Pete Lancashire
Дата:
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:

> 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
>
>

Re: BUG #13498: make check failures

От
Andres Freund
Дата:
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 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%

You could try with gcc -O3...

Re: BUG #13498: make check failures

От
Pete Lancashire
Дата:
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:

> 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 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%
>
> You could try with gcc -O3...
>
>