On Mon, Apr 18, 2016 at 09:17:46AM -0400, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
> > On Mon, Apr 18, 2016 at 12:31 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> >> I don't know if it's worth tracking this as an open item and thus
> >> kind-of release blocker if no one else has the problem. But I
> >> definitely still have it. My initial suspicion was that this had
> >> something to do with a partial upgrade to gcc 6 (not yet released), in
> >> other words a messed up system. But I was able to reproduce it in a
> >> freshly installed chroot. It only happens with various versions of gcc,
> >> but not with clang. So I'm going to have to keep digging.
>
> > gcc is moving slowly but surely to have 6.0 in a released state btw:
> > https://gcc.gnu.org/ml/gcc/2016-04/msg00103.html
>
> Given that it's apparently showing the results of asind as NULL, the
> theory that comes to mind is some sort of optimization issue affecting
> the output tuple's null-flags. I have no idea why only this test would
> be affected, though. Anyway, a good way to test that theory would be
> to see if the -O level affects it.
I doubt asind is returning NULL. Here's the query, which uses a CASE to
report NULL if asind returns any value not on a whitelist:
SELECT x, CASE WHEN asind(x) IN (-90,-30,0,30,90) THEN asind(x) END AS asind, CASE WHEN acosd(x) IN
(0,60,90,120,180)THEN acosd(x) END AS acosd, CASE WHEN atand(x) IN (-45,0,45) THEN atand(x) END AS atand
FROM (VALUES (-1), (-0.5), (0), (0.5), (1)) AS t(x);
I can see the benefit for atand(-0.5) and for atand(0.5), since those are
inexact. Does the CASE gain us anything for asind or acosd?
Results under -O0 would be a helpful data point, nonetheless.
