Re: Portability: common-src/amcrc32chw.c & config/amanda/amanda_configure.m4

Jean-Louis Martineau writes:
- amanda detect at run time if the sse4.2 instruction are available and=20
- use them only if they are available.
- different code is used if the sse4.2 instruction are not available.
- What's wrong with that?

Backing up.

The original code *assumed* that if you were using GCC and it
was at least 4.3 on any x86 processor architecture, the
__builtin_ia32_* functions would be available.

However, as you've stated, that is only true if the compliler is
called with the ``-msse4.2'' (or other -msse* flags?).

And amanda *assumed* it was being compiled with the ``-msse4.2''
(or similar) flag.

pkgsrc explicitly strips such flags from compile tests for
maximal portability for it's binary builds across systems.

Given that gcc wasn't given ``-msse4.2'' on the complile/load
command line, the __builtin_ia32_* functions were unable to be
resolved at link time.

Summary: amanda was blindly using (builtin) library routines
with out insuring that they were resolvable at compile/link
time.  My original patch at least tested for their existence and
didn't try to use that code path if a compile test for the
functions failed.

- If I understand, you want an option to completely disable sse4.2?
- You do not want newer CPU to use sse4.2
- I don't understand since amanda detect sse4.2 at run time.

See above about amanda in pkgsrc not getting the compile time
compiler flag detection.

Effectively, pkgsrc isn't allowing the ``-msse4.2'' flag through
to the test cases to expose the associated builtins.

- On 03/01/17 02:45 PM, Eric Schnoebelen wrote:
- > Jean-Louis Martineau writes:
- > - I think I can replace the #ifdef line with:
- > - #ifdef __SSE_4_2_
- > -
- > - Because if __SSE_4_2_ is defined then the __builtin_ia32_crc32* function
- > - must be defined
- >
- > Depending on a compiler specific internal macro definition seems
- > fraught with danger.  Imagine the case of xycc (random non-gcc
- > compiler) defining __SSE_4_2_ for some purpose, but not
- > providing these particular functions.  Feature testing for the
- > functions used is almost always a better idea.

- If the xycc compiler define __SSE4_2__ for a different meaning then that
- compiler is broken.
-
- Both gcc and clang define it

While I would hope that the developers of xycc would look to
existing practice in defining a __SSE4_2__ macro today.  Of course,
xycc's definition of __SSE4_2__ may predate Intel's definition of
the sse4.2 instruction set, and GCC's addition of said macro to
their compiler.

Hoever, being prefixed with a double underscore, it is a macro in
the compiler implementation name space, and is not guarenteed to
be unique across all compilers, or have the same meaning on all
compilers.  (at least that is my memory of reading the ANSI C
standard back when I was implementing an ANSI C/POSIX.1 libc circa
1991.)

If you want to use __SSE4_2__ in a more robust, portable fashion,
I would recommend testing it along with the macro describing the
compiler that is known to support it, eg

  #if defined __GNUC__ && GCC_VERSION > 40300 && defined __SSE4_2__
  #endif

or

  #if (defined __GNUC__ || defined __CLANG__ ) && defined __SSE4_2__
  #endif

(assuming __CLANG__ is the macro clang defines to describe itself,
and that gcc before 4.3 wouldn't ever define __SSE4_2__ )