Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 Oct 2013 18:31:09 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: MAYBE_INLINE

magnum, all -

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

That is, the combination of both directives is enabled for versions of
gcc recent enough to support __attribute__((always_inline)), including
for versions that don't also require the inline keyword.  This simply
does not hurt for any version of gcc, and I think it won't hurt for 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.

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.

Of course, it is also possible to add even more complexity by checking
for clang or icc explicitly, but I'd rather not.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ