Thread: Configure checks and optimizations/crc32 tests
Hi, when building with optimizations clang-3.7, probably some older compilers as well, fail with a funny error: fatal error: error in backend: Cannot select: intrinsic %llvm.x86.sse42.crc32.64.64 turns out that is because configure chose to use the crc32 instruction, without the according compiler -msse4.2 flag. Why you ask? Because the whole configure test is optimized away. Nothing depends on it's output... We can easily fix the issue by adding /* return values dependent on crc, to prevent optimizations */ return crc == 0; or so to the end of PGAC_SSE42_CRC32_INTRINSICS. But we've played that whack-a-mole game in a bunch of configure tests now, and it seems likely that more are coming with compilers getting better. I'd not be surprised if some tests actually always succeed, we just don't notice it because it's only on new compilers that have the tested feature anyway... One way trying to fix this would be to explicitly disable optimizations during tests. I'm not sure that's a good idea, but it's one. Greetings, Andres Freund
On 08/14/2015 12:20 PM, Andres Freund wrote: > Hi, > > when building with optimizations clang-3.7, probably some older > compilers as well, fail with a funny error: > > fatal error: error in backend: Cannot select: intrinsic %llvm.x86.sse42.crc32.64.64 > > turns out that is because configure chose to use the crc32 instruction, > without the according compiler -msse4.2 flag. Why you ask? Because the > whole configure test is optimized away. Nothing depends on it's > output... Oh, interesting. > We can easily fix the issue by adding > /* return values dependent on crc, to prevent optimizations */ > return crc == 0; > or so to the end of PGAC_SSE42_CRC32_INTRINSICS. Yeah, seems like a simple fix. > But we've played that whack-a-mole game in a bunch of configure tests > now, and it seems likely that more are coming with compilers getting > better. I'd not be surprised if some tests actually always succeed, we > just don't notice it because it's only on new compilers that have the > tested feature anyway... Yeah, wouldn't be surprised if the other similar tests for all __sync_* family of functions had the same problem. > One way trying to fix this would be to explicitly disable optimizations > during tests. I'm not sure that's a good idea, but it's one. I think adding the "return" is better. - Heikki
Hi, On 2015-08-14 15:35:45 +0300, Heikki Linnakangas wrote: > >But we've played that whack-a-mole game in a bunch of configure tests > >now, and it seems likely that more are coming with compilers getting > >better. I'd not be surprised if some tests actually always succeed, we > >just don't notice it because it's only on new compilers that have the > >tested feature anyway... > > Yeah, wouldn't be surprised if the other similar tests for all __sync_* > family of functions had the same problem. I don't think those are vulnerable because atomics do have a side effect - they're memory barriers. Maybe if we'd specified relaxed (we don't) consistency mode for the __atomic_* ones. > >One way trying to fix this would be to explicitly disable optimizations > >during tests. I'm not sure that's a good idea, but it's one. > > I think adding the "return" is better. Ok, will do. Greetings, Andres Freund
Hi, On 2015-08-14 11:20:39 +0200, Andres Freund wrote: > when building with optimizations clang-3.7, probably some older > compilers as well, fail with a funny error: > > fatal error: error in backend: Cannot select: intrinsic %llvm.x86.sse42.crc32.64.64 > > turns out that is because configure chose to use the crc32 instruction, > without the according compiler -msse4.2 flag. Why you ask? Because the > whole configure test is optimized away. Nothing depends on it's > output... > > We can easily fix the issue by adding > /* return values dependent on crc, to prevent optimizations */ > return crc == 0; > or so to the end of PGAC_SSE42_CRC32_INTRINSICS. Going over my vpaths I noticed another problem with the test. With gcc I get slice-by-8 instead of the runtime variant: checking for builtin __atomic int64 atomic operations... yes checking for __get_cpuid... yes checking for __cpuid... no checking for _mm_crc32_u8 and _mm_crc32_u32 with CFLAGS=... no checking for _mm_crc32_u8 and _mm_crc32_u32 with CFLAGS=-msse4.2... no checking which CRC-32C implementation to use... slicing-by-8 That's because I get a warning conftest.c:179:1: warning: old-style function definition [-Wold-style-definition]main ()^ and PGAC_SSE42_CRC32_INTRINSICS turns on ac_c_werror_flag. Now I can work around this by , but I don't really see why that test needs to turn on -Werror? Isn't the point of using a linker test that we'd get a proper linker failure if the functions don't exist? Greetings, Andres Freund
On 08/14/2015 07:42 PM, Andres Freund wrote: > Going over my vpaths I noticed another problem with the test. With gcc I > get slice-by-8 instead of the runtime variant: > > checking for builtin __atomic int64 atomic operations... yes > checking for __get_cpuid... yes > checking for __cpuid... no > checking for _mm_crc32_u8 and _mm_crc32_u32 with CFLAGS=... no > checking for _mm_crc32_u8 and _mm_crc32_u32 with CFLAGS=-msse4.2... no > checking which CRC-32C implementation to use... slicing-by-8 > > That's because I get a warning > conftest.c:179:1: warning: old-style function definition [-Wold-style-definition] > main () > ^ > and PGAC_SSE42_CRC32_INTRINSICS turns on ac_c_werror_flag. Now I can > work around this by , but I don't really see why that test needs to turn on > -Werror? Isn't the point of using a linker test that we'd get a proper > linker failure if the functions don't exist? Yeah, it was probably just copy-pasted from the other macros in c-compiler.m4 without thinking. - Heikki