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