user/sven/linux.git/include/linux/compiler-intel.h, branch v3.10.49

x86, build, icc: Remove uninitialized_var() from compiler-intel.h

2013-12-20T15:45:10Z

commit 503cf95c061a0551eb684da364509297efbe55d9 upstream. When compiling with icc, ends up included because the icc environment defines __GNUC__. Thus, we neither need nor want to have this macro defined in both compiler-gcc.h and compiler-intel.h, and the fact that they are inconsistent just makes the compiler spew warnings. Reported-by: Sunil K. Pandey Cc: Kevin B. Smith Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/n/tip-0mbwou1zt7pafij09b897lg3@git.kernel.org Signed-off-by: Greg Kroah-Hartman

byteorder: allow arch to opt to use GCC intrinsics for byteswapping

2012-12-06T01:22:31Z

Since GCC 4.4, there have been __builtin_bswap32() and __builtin_bswap16() intrinsics. A __builtin_bswap16() came a little later (4.6 for PowerPC, 48 for other platforms). By using these instead of the inline assembler that most architectures have in their __arch_swabXX() macros, we let the compiler see what's actually happening. The resulting code should be at least as good, and much *better* in the cases where it can be combined with a nearby load or store, using a load-and-byteswap or store-and-byteswap instruction (e.g. lwbrx/stwbrx on PowerPC, movbe on Atom). When GCC is sufficiently recent *and* the architecture opts in to using the intrinsics by setting CONFIG_ARCH_USE_BUILTIN_BSWAP, they will be used in preference to the __arch_swabXX() macros. An architecture which does not set ARCH_USE_BUILTIN_BSWAP will continue to use its own hand-crafted macros. Signed-off-by: David Woodhouse Acked-by: H. Peter Anvin

Force erroneous inclusions of compiler-*.h files to be errors

2007-10-17T15:42:47Z

Replace worthless comments with actual preprocessor errors when including the wrong versions of the compiler.h files. [akpm@linux-foundation.org: make it work] Signed-off-by: Robert P. J. Day Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

ARRAY_SIZE: check for type

2007-05-07T19:13:00Z

We can use a gcc extension to ensure that ARRAY_SIZE() is handed an array, not a pointer. This is especially important when code is changed from a fixed array to a pointer. I assume the Intel compiler doesn't support __builtin_types_compatible_p. [jdike@addtoit.com: uml: update UML definition of ARRAY_SIZE] Signed-off-by: Rusty Russell Signed-off-by: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Add unitialized_var() macro for suppressing gcc warnings

2007-05-07T19:12:52Z

Introduce a macro for suppressing gcc from generating a warning about a probable uninitialized state of a variable. Example: - spinlock_t *ptl; + spinlock_t *uninitialized_var(ptl); Not a happy solution, but those warnings are obnoxious. - Using the usual pointlessly-set-it-to-zero approach wastes several bytes of text. - Using a macro means we can (hopefully) do something else if gcc changes cause the `x = x' hack to stop working - Using a macro means that people who are worried about hiding true bugs can easily turn it off. Signed-off-by: Borislav Petkov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ECC support

2003-09-21T08:36:53Z

From: "Nakajima, Jun" Split the increasingly messy compiler.h file into per-compiler files and also add support for non-gcc compilers. With the current implementation: include/linux/compiler.h defines the compiler-dependent abstractions which can be overwritten by per-compiler definitions. include/linux/compiler-gcc.h contains the common definitions for all gcc versions. include/linux/compiler-gcc[2,3,+].h contains gcc major version specific definitions. include/linux/compiler-intel.h contains intel compiler specific definitions."