[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <164b2f331a7dd92be94061fb947ce12a@smtp.hushmail.com>
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[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/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.
