Date: Mon, 04 Nov 2013 23:45:36 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: MAYBE_INLINE Solar, On 2013-10-29 18:17, magnum wrote: > On 2013-10-29 15:31, Solar Designer wrote: >> icc 14.0.0 requires that if __attribute__((always_inline)) is specified, >> the keyword inline must also be specified. This detail is even mention >> in icc release notes. >> >> This is the same behavior that is seen with recent gcc, except that icc >> claims to be an older gcc version, so jumbo's current #if meant to cover >> this case is not triggered for icc, resulting in a failed compile. >> >> In JtR core tree, I simply use: >> >> #ifdef __GNUC__ >> #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1) >> #define MAYBE_INLINE __attribute__((always_inline)) __inline__ >> #else >> #define MAYBE_INLINE __inline__ >> #endif >> #elif __STDC_VERSION__ >= 199901L >> #define MAYBE_INLINE inline >> #else >> #define MAYBE_INLINE >> #endif >> I think we should reconsider and bring jumbo's #if's around MAYBE_INLINE >> to be the same as core's. Probably not many people care about the older >> clang, and there will be even fewer of them with time - whereas icc >> 14.0.0 >> is recent. It's also just cleaner and simpler code. No workaround is >> necessary to support recent versions of all of: gcc, icc, clang - >> whereas the old clang workaround (extra complexity) hurts new icc. >> IIRC, the reason why we went with more elaborate #if's in jumbo was that >> some older version of clang failed to process the combination of these >> two directives, despite of claiming to be gcc'ish enough to pass the >> core tree's #if above. > Agreed and committed. This led to problems on OSX 10.9 Mavericks. I didn't notice because I normally use a real gcc. The native /usr/bin/gcc is now clang (used to be llvm-gcc), and we currently get this build failure: Undefined symbols for architecture x86_64: "_MD5_body", referenced from: _DynamicFunc__crypt_md5 in dynamic_fmt.o _DynamicFunc__POCrypt in dynamic_fmt.o _DynamicFunc__crypt2_md5 in dynamic_fmt.o _DynamicFunc__crypt_md5_in1_to_out2 in dynamic_fmt.o _DynamicFunc__crypt_md5_in2_to_out1 in dynamic_fmt.o _DynamicFunc__crypt_md5_to_input_raw in dynamic_fmt.o _DynamicFunc__crypt_md5_to_input_raw_Overwrite_NoLen_but_setlen_in_SSE in dynamic_fmt.o ... ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [../run/john] Error 1 make: *** [macosx-x86-64] Error 2 There is no warning or complaint about the macro preceeding the linking failure but apparently the extra "inline" makes clang drop the whole function without notice. $ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix $ gcc -dM -E -x c /dev/null | grep GNUC #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC_STDC_INLINE__ 1 #define __GNUC__ 4 Do you have a suggestion? Otherwise I'll revert to the #if we used in Jumbo before, and add an __INTEL_COMPILER check to solve the icc problem. Maybe like this (untested): #ifdef __GNUC__ #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 7) || defined(__INTEL_COMPILER) #define MAYBE_INLINE __attribute__((always_inline)) inline #elif __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1) #define MAYBE_INLINE __attribute__((always_inline)) #else #define MAYBE_INLINE __inline__ #endif #elif __STDC_VERSION__ >= 199901L #define MAYBE_INLINE inline #else #define MAYBE_INLINE #endif magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.