Re: BUG #13498: make check failures

From: Pete Lancashire <pete(at)petelancashire(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #13498: make check failures
Date: 2015-07-13 21:15:58
Message-ID: CAA-F0u9NG8S7W5mq=psFG8ZHaqLvONXipjDbk0csYbVb6t0E9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> pete(at)petelancashire(dot)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
>
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2015-07-13 21:20:06 Re: BUG #13498: make check failures
Previous Message Tom Lane 2015-07-13 20:13:38 Re: BUG #13498: make check failures