On Mon, Apr 18, 2016 at 09:17:46AM -0400, Tom Lane wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: > > On Mon, Apr 18, 2016 at 12:31 PM, Peter Eisentraut <pete...@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. -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers