Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 04 Nov 2013 23:45:36 +0100
From: magnum <>


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
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 
make[1]: *** [../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/ 
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) || 
#define MAYBE_INLINE __attribute__((always_inline)) inline
#elif __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
#define MAYBE_INLINE __attribute__((always_inline))
#define MAYBE_INLINE __inline__
#elif __STDC_VERSION__ >= 199901L
#define MAYBE_INLINE inline


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.