On Sun, Jul 19, 2015 at 04:32:16PM -0400, Noah Misch wrote:
> On Sun, Jul 19, 2015 at 04:22:47PM -0400, Tom Lane wrote:
> > More: if the compiler does have a bug like that, how much confidence can
> > we have, really, that there are no other miscompiled places and won't be
> > any in the future? If we are going to support this configuration, I think
> > what the patch ought to do is disable PG_USE_INLINE globally when this
> > compiler is detected. That would revert the behavior to what it was
> > before 43d89a2.
>
> That's a reasonable alternative.
Here's the patch implementing it.
diff --git a/config/test_quiet_include.h b/config/test_quiet_include.h
index f4fa4d3..732b231 100644
--- a/config/test_quiet_include.h
+++ b/config/test_quiet_include.h
@@ -7,3 +7,12 @@ fun()
{
return 0;
}
+
+/*
+ * "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline
+ * expansions of ginCompareItemPointers() "long long" arithmetic. To take
+ * advantage of inlining, build a 64-bit PostgreSQL.
+ */
+#if defined(__ILP32__) && defined(__IBMC__)
+#error "known inlining bug"
+#endif
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
