- 02 4月, 2016 1 次提交
-
-
由 Noah Misch 提交于
-
- 09 10月, 2015 1 次提交
-
-
由 Robert Haas 提交于
This is like BSWAP32, but for 64-bit values. Since we've got two of them now and they have use cases (like sortsupport) beyond CRCs, move the definitions to their own header file. Peter Geoghegan
-
- 17 8月, 2015 1 次提交
-
-
由 Andres Freund 提交于
With optimizations enabled at least one compiler, clang 3.7, optimized away the crc intrinsics knowing that the result went on unused and has no side effects. That can trigger errors in code generation when the intrinsic is used, as we chose to use the intrinsics without any additional compiler flag. Return the computed value to prevent that. With some more pedantic warning flags (-Wold-style-definition) the configure test failed to recognize the existence of _mm_crc32_u* intrinsics due to an independent warning in the test because the test turned on -Werror, but that's not actually needed here. Discussion: 20150814092039.GH4955@awork2.anarazel.de Backpatch: 9.5, where the use of crc intrinsics was integrated.
-
- 06 8月, 2015 1 次提交
-
-
由 Andres Freund 提交于
So far we have worked around the fact that some very old compilers do not support 'inline' functions by only using inline functions conditionally (or not at all). Since such compilers are very rare by now, we have decided to rely on inline functions from 9.6 onwards. To avoid breaking these old compilers inline is defined away when not supported. That'll cause "function x defined but not used" type of warnings, but since nobody develops on such compilers anymore that's ok. This change in policy will allow us to more easily employ inline functions. I chose to remove code previously conditional on PG_USE_INLINE as it seemed confusing to have code dependent on a define that's always defined. Blacklisting of compilers, like in c53f7387, now has to be done differently. A platform template can define PG_FORCE_DISABLE_INLINE to force inline to be defined empty. Discussion: 20150701161447.GB30708@awork2.anarazel.de
-
- 03 7月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
AC_TRY_COMPILE(...) -> AC_COMPILE_IFELSE([AC_LANG_PROGRAM(...)]) AC_TRY_LINK(...) -> AC_LINK_IFELSE([AC_LANG_PROGRAM(...)]) AC_TRY_RUN(...) -> AC_RUN_IFELSE([AC_LANG_PROGRAM(...)]) AC_LANG_SAVE/RESTORE -> AC_LANG_PUSH/POP AC_DECL_SYS_SIGLIST -> AC_CHECK_DECLS(...) (per snippet in autoconf manual) Also use AC_LANG_SOURCE instead of AC_LANG_PROGRAM, where the main() function is not needed. With these changes, autoconf -Wall doesn't complain anymore. Andreas Karlsson
-
- 15 4月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
Eliminate the separate 'len' variable from the loops, and also use the 4 byte instruction. This shaves off a few more cycles. Even though this routine that uses the special SSE 4.2 instructions is much faster than a generic routine, it's still a hot spot, so let's make it as fast as possible. Change the configure test to not test _mm_crc32_u64. That variant is only available in the 64-bit x86-64 architecture, not in 32-bit x86. Modify pg_comp_crc32c_sse42 so that it only uses _mm_crc32_u64 on x86-64. With these changes, the SSE accelerated CRC-32C implementation can also be used on 32-bit x86 systems. This also fixes the 32-bit MSVC build.
-
- 14 4月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
Modern x86 and x86-64 processors with SSE 4.2 support have special instructions, crc32b and crc32q, for calculating CRC-32C. They greatly speed up CRC calculation. Whether the instructions can be used or not depends on the compiler and the target architecture. If generation of SSE 4.2 instructions is allowed for the target (-msse4.2 flag on gcc and clang), use them. If they are not allowed by default, but the compiler supports the -msse4.2 flag to enable them, compile just the CRC-32C function with -msse4.2 flag, and check at runtime whether the processor we're running on supports it. If it doesn't, fall back to the slicing-by-8 algorithm. (With the common defaults on current operating systems, the runtime-check variant is what you get in practice.) Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
-
- 20 3月, 2015 1 次提交
-
-
由 Andres Freund 提交于
We will, for the foreseeable future, not expose 128 bit datatypes to SQL. But being able to use 128bit math will allow us, in a later patch, to use 128bit accumulators for some aggregates; leading to noticeable speedups over using numeric. So far we only detect a gcc/clang extension that supports 128bit math, but no 128bit literals, and no *printf support. We might want to expand this in the future to further compilers; if there are any that that provide similar support. Discussion: 544BB5F1.50709@proxel.se Author: Andreas Karlsson, with significant editorializing by me Reviewed-By: Peter Geoghegan, Oskari Saarenmaa
-
- 10 2月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
This speeds up WAL generation and replay. The new algorithm is significantly faster with large inputs, like full-page images or when inserting wide rows. It is slower with tiny inputs, i.e. less than 10 bytes or so, but the speedup with longer inputs more than make up for that. Even small WAL records at least have 24 byte header in the front. The output is identical to the current byte-at-a-time computation, so this does not affect compatibility. The new algorithm is only used for the CRC-32C variant, not the legacy version used in tsquery or the "traditional" CRC-32 used in hstore and ltree. Those are not as performance critical, and are usually only applied over small inputs, so it seems better to not carry around the extra lookup tables to speed up those rare cases. Abhijit Menon-Sen
-
- 23 11月, 2014 1 次提交
-
-
由 Noah Misch 提交于
This eliminates gobs of "unrecognized format function type" warnings under MinGW compilers predating GCC 4.4.
-
- 26 9月, 2014 1 次提交
-
-
由 Andres Freund 提交于
Several upcoming performance/scalability improvements require atomic operations. This new API avoids the need to splatter compiler and architecture dependent code over all the locations employing atomic ops. For several of the potential usages it'd be problematic to maintain both, a atomics using implementation and one using spinlocks or similar. In all likelihood one of the implementations would not get tested regularly under concurrency. To avoid that scenario the new API provides a automatic fallback of atomic operations to spinlocks. All properties of atomic operations are maintained. This fallback - obviously - isn't as fast as just using atomic ops, but it's not bad either. For one of the future users the atomics ontop spinlocks implementation was actually slightly faster than the old purely spinlock using implementation. That's important because it reduces the fear of regressing older platforms when improving the scalability for new ones. The API, loosely modeled after the C11 atomics support, currently provides 'atomic flags' and 32 bit unsigned integers. If the platform efficiently supports atomic 64 bit unsigned integers those are also provided. To implement atomics support for a platform/architecture/compiler for a type of atomics 32bit compare and exchange needs to be implemented. If available and more efficient native support for flags, 32 bit atomic addition, and corresponding 64 bit operations may also be provided. Additional useful atomic operations are implemented generically ontop of these. The implementation for various versions of gcc, msvc and sun studio have been tested. Additional existing stub implementations for * Intel icc * HUPX acc * IBM xlc are included but have never been tested. These will likely require fixes based on buildfarm and user feedback. As atomic operations also require barriers for some operations the existing barrier support has been moved into the atomics code. Author: Andres Freund with contributions from Oskari Saarenmaa Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com, 20131015123303.GH5300@awork2.anarazel.de, 20131028205522.GI20248@awork2.anarazel.de
-
- 02 5月, 2014 1 次提交
-
-
由 Tom Lane 提交于
This test used to just define an unused static inline function and check whether that causes a warning. But newer clang versions warn about unused static inline functions when defined inside a .c file, but not when defined in an included header, which is the case we care about. Change the test to cope. Andres Freund
-
- 30 4月, 2013 1 次提交
-
-
由 Simon Riggs 提交于
Ants Aasma and Jeff Davis
-
- 14 1月, 2013 1 次提交
-
-
由 Tom Lane 提交于
In commit 71450d7f, we added code to inform suitably-intelligent compilers that ereport() doesn't return if the elevel is ERROR or higher. This patch extends that to elog(), and also fixes a double-evaluation hazard that the previous commit created in ereport(), as well as reducing the emitted code size. The elog() improvement requires the compiler to support __VA_ARGS__, which should be available in just about anything nowadays since it's required by C99. But our minimum language baseline is still C89, so add a configure test for that. The previous commit assumed that ereport's elevel could be evaluated twice, which isn't terribly safe --- there are already counterexamples in xlog.c. On compilers that have __builtin_constant_p, we can use that to protect the second test, since there's no possible optimization gain if the compiler doesn't know the value of elevel. Otherwise, use a local variable inside the macros to prevent double evaluation. The local-variable solution is inferior because (a) it leads to useless code being emitted when elevel isn't constant, and (b) it increases the optimization level needed for the compiler to recognize that subsequent code is unreachable. But it seems better than not teaching non-gcc compilers about unreachability at all. Lastly, if the compiler has __builtin_unreachable(), we can use that instead of abort(), resulting in a noticeable code savings since no function call is actually emitted. However, it seems wise to do this only in non-assert builds. In an assert build, continue to use abort(), so that the behavior will be predictable and debuggable if the "impossible" happens. These changes involve making the ereport and elog macros emit do-while statement blocks not just expressions, which forces small changes in a few call sites. Andres Freund, Tom Lane, Heikki Linnakangas
-
- 09 10月, 2012 1 次提交
-
-
由 Alvaro Herrera 提交于
The former name was too likely to conflict with symbols from external headers; and, as seen in recent buildfarm failures in member spoonbill, it has now happened at least in plpython.
-
- 01 10月, 2012 1 次提交
-
-
由 Tom Lane 提交于
Currently, the macros only work with fairly recent gcc versions, but there is room to expand them to other compilers that have comparable features. Heavily revised and autoconfiscated version of a patch by Andres Freund.
-
- 27 5月, 2011 1 次提交
-
-
由 Tom Lane 提交于
This is reported to be necessary on some versions of that OS. In service of this, cause PGAC_PROG_CC_CFLAGS_OPT to reject switches that result in compiler warnings, since on yet other versions of that OS, the switch does nothing except provoke a warning. Report and patch by Ibrar Ahmed, further tweaking by me.
-
- 30 9月, 2010 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 21 9月, 2010 1 次提交
-
-
由 Magnus Hagander 提交于
-
- 19 8月, 2010 1 次提交
-
-
由 Peter Eisentraut 提交于
at end of files.
-
- 26 5月, 2010 1 次提交
-
-
由 Michael Meskes 提交于
-
- 25 5月, 2010 1 次提交
-
-
由 Michael Meskes 提交于
Added a configure test for "long long" datatypes. So far this is only used in ecpg and replaces the old test that was kind of hackish.
-
- 13 2月, 2010 1 次提交
-
-
由 Tom Lane 提交于
compilers, by applying a configure check to see if the compiler will accept an unreferenced "static inline foo ..." function without warnings. It is believed that such warnings are the only reason not to declare inlined functions in headers, if the compiler understands "inline" at all. Kurt Harriman
-
- 27 6月, 2008 1 次提交
-
-
由 Tom Lane 提交于
vintage Linux is even more broken than we realized: a link to libreadline will succeed, and fail only at runtime. It seems that an AC_TRY_RUN test is the only reliable way to check whether this is really safe. Per report from Tatsuo.
-
- 20 5月, 2008 1 次提交
-
-
由 Tom Lane 提交于
libreadline. What we will do for compatibility :-(
-
- 19 5月, 2008 1 次提交
-
-
由 Tom Lane 提交于
shared libraries. We've tried this before and had problems with libreadline not linking properly on some platforms, but that seems to be a libreadline bug that may have been fixed by now. In any case, it's early enough in the 8.4 devel cycle that we can afford to have some transient breakage while we work out any portability problems. On Darwin, we try -Wl,-dead_strip_dylibs, which seems to be the equivalent incantation there.
-
- 19 4月, 2008 1 次提交
-
-
由 Alvaro Herrera 提交于
uses of the long-deprecated float32 in contrib/seg; the definitions themselves are still there, but no longer used. fmgr/README updated to match. I added a CREATE FUNCTION to account for existing seg_center() code in seg.c too, and some tests for it and the neighbor functions. At the same time, remove checks for NULL which are not needed (because the functions are declared STRICT). I had to do some adjustments to contrib's btree_gist too. The choices for representation there are not ideal for changing the underlying types :-( Original patch by Zoltan Boszormenyi, with some adjustments by me.
-
- 18 2月, 2008 1 次提交
-
-
由 Peter Eisentraut 提交于
- Change configure.in to use Autoconf 2.61 and update generated files. - Update build system and documentation to support now directory variables offered by Autoconf 2.61. - Replace usages of PGAC_CHECK_ALIGNOF by AC_CHECK_ALIGNOF, now available in Autoconf 2.61. - Drop our patched version of AC_C_INLINE, as Autoconf now has the change.
-
- 17 12月, 2004 1 次提交
-
-
由 Bruce Momjian 提交于
binary compiles, and adjust configure tests for AIX.
-
- 20 10月, 2004 1 次提交
-
-
由 Neil Conway 提交于
-O2 -Wall -Wmissing-prototypes -Wpointer-arith Check whether the version of GCC we are using supports any of: -Wdeclaration-after-statement -Wendif-labels -Wold-style-definition And add the supported flags to CFLAGS.
-
- 02 2月, 2004 1 次提交
-
-
由 Tom Lane 提交于
-fno-strict-aliasing.
-
- 30 11月, 2003 1 次提交
-
-
由 PostgreSQL Daemon 提交于
$Header: -> $PostgreSQL Changes ...
-
- 02 11月, 2003 1 次提交
-
-
由 Peter Eisentraut 提交于
When --enable-debug is used, then the default CFLAGS for non-GCC is just -g without -O. Backpatch enhancement of Autoconf inline test that detects problems with the HP C compiler.
-
- 25 10月, 2003 1 次提交
-
-
由 Peter Eisentraut 提交于
option -fno-strict-aliasing is available.
-
- 25 4月, 2003 1 次提交
-
-
由 Tom Lane 提交于
rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
-
- 07 4月, 2003 1 次提交
-
-
由 Peter Eisentraut 提交于
parts. Standardize spelling of comments in pg_config.h.
-
- 29 1月, 2003 1 次提交
-
-
由 Peter Eisentraut 提交于
separate macro. Also add support for %I64d which is the way on Windows. The code that checks for the 64-bit int type now gives more reasonable results when cross-compiling: In that case we just take the compiler's information and trust that the arithmetic works. Disabling int64 is too pessimistic.
-
- 30 3月, 2002 1 次提交
-
-
由 Peter Eisentraut 提交于
calls with new or now-built-in versions. Make sure that all calls to AC_DEFINE have a third argument, for possible use of autoheader in the future.
-
- 02 12月, 2001 1 次提交
-
-
由 Peter Eisentraut 提交于
which include files to consider. Should fix BeOS problems with int8 types.
-
- 29 8月, 2000 1 次提交
-
-
由 Peter Eisentraut 提交于
-