aboutsummaryrefslogtreecommitdiff
path: root/include/linux/compiler-gcc4.h
AgeCommit message (Collapse)AuthorFilesLines
2012-01-10kernel.h: add BUILD_BUG() macroDavid Daney1-0/+1
We can place this in definitions that we expect the compiler to remove by dead code elimination. If this assertion fails, we get a nice error message at build time. The GCC function attribute error("message") was added in version 4.3, so we define a new macro __linktime_error(message) to expand to this for GCC-4.3 and later. This will give us an error diagnostic from the compiler on the line that fails. For other compilers __linktime_error(message) expands to nothing, and we have to be content with a link time error, but at least we will still get a build error. BUILD_BUG() expands to the undefined function __build_bug_failed() and will fail at link time if the compiler ever emits code for it. On GCC-4.3 and later, attribute((error())) is used so that the failure will be noted at compile time instead. Signed-off-by: David Daney <[email protected]> Acked-by: David Rientjes <[email protected]> Cc: DM <[email protected]> Cc: Ralf Baechle <[email protected]> Acked-by: David Howells <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2011-05-25sparse: Undef __compiletime_{warning,error} if __CHECKER__ is definedKOSAKI Motohiro1-1/+1
sparse can't parse warning and error attribute. then they should be hidden from sparse. Signed-off-by: KOSAKI Motohiro <[email protected]> Cc: Arjan van de Ven <[email protected]> Cc: Dave Hansen <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2011-03-22include/linux/compiler-gcc*.h: unify macro definitionsBorislav Petkov1-8/+0
Unify identical gcc3.x and gcc4.x macros. Signed-off-by: Borislav Petkov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2010-06-29compiler-gcc.h: gcc-4.5 needs noclone and noinline on __naked functionsMikael Pettersson1-0/+4
A __naked function is defined in C but with a body completely implemented by asm(), including any prologue and epilogue. These asm() bodies expect standard calling conventions for parameter passing. Older GCCs implement that correctly, but 4.[56] currently do not, see GCC PR44290. In the Linux kernel this breaks ARM, causing most arch/arm/mm/copypage-*.c modules to get miscompiled, resulting in kernel crashes during bootup. Part of the kernel fix is to augment the __naked function attribute to also imply noinline and noclone. This patch implements that, and has been verified to fix boot failures with gcc-4.5 compiled 2.6.34 and 2.6.35-rc1 kernels. The patch is a no-op with older GCCs. Signed-off-by: Mikael Pettersson <[email protected]> Signed-off-by: Khem Raj <[email protected]> Cc: Russell King <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2009-12-05Merge branch 'x86-asm-for-linus' of ↵Linus Torvalds1-0/+8
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: include/linux/compiler-gcc4.h: Fix build bug - gcc-4.0.2 doesn't understand __builtin_object_size x86/alternatives: No need for alternatives-asm.h to re-invent stuff already in asm.h x86/alternatives: Check replacementlen <= instrlen at build time x86, 64-bit: Set data segments to null after switching to 64-bit mode x86: Clean up the loadsegment() macro x86: Optimize loadsegment() x86: Add missing might_fault() checks to copy_{to,from}_user() x86-64: __copy_from_user_inatomic() adjustments x86: Remove unused thread_return label from switch_to() x86, 64-bit: Fix bstep_iret jump x86: Don't use the strict copy checks when branch profiling is in use x86, 64-bit: Move K8 B step iret fixup to fault entry asm x86: Generate cmpxchg build failures x86: Add a Kconfig option to turn the copy_from_user warnings into errors x86: Turn the copy_from_user check into an (optional) compile time warning x86: Use __builtin_memset and __builtin_memcpy for memset/memcpy x86: Use __builtin_object_size() to validate the buffer size for copy_from_user()
2009-12-05Add support for GCC-4.5's __builtin_unreachable() to compiler.h (v2)David Daney1-0/+14
Starting with version 4.5, GCC has a new built-in function __builtin_unreachable() that can be used in places like the kernel's BUG() where inline assembly is used to transfer control flow. This eliminated the need for an endless loop in these places. The patch adds a new macro 'unreachable()' that will expand to either __builtin_unreachable() or an endless loop depending on the compiler version. Change from v1: Simplify unreachable() for non-GCC 4.5 case. Signed-off-by: David Daney <[email protected]> Acked-by: Ralf Baechle <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2009-12-03include/linux/compiler-gcc4.h: Fix build bug - gcc-4.0.2 doesn't understand ↵Andrew Morton1-0/+2
__builtin_object_size Maybe 4.1.0 doesn't too, but this fixed it for me. Caused by: 4a31276: x86: Turn the copy_from_user check into an (optional) compile time warning 9f0cf4a: x86: Use __builtin_object_size() to validate the buffer size for copy_from_user() Signed-off-by: Andrew Morton <[email protected]> Cc: Arjan van de Ven <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2009-10-02x86: Add a Kconfig option to turn the copy_from_user warnings into errorsArjan van de Ven1-0/+1
For automated testing it is useful to have the option to turn the warnings on copy_from_user() etc checks into errors: In function ‘copy_from_user’, inlined from ‘fd_copyin’ at drivers/block/floppy.c:3080, inlined from ‘fd_ioctl’ at drivers/block/floppy.c:3503: linux/arch/x86/include/asm/uaccess_32.h:213: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user buffer size is not provably correct Signed-off-by: Arjan van de Ven <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2009-10-01x86: Turn the copy_from_user check into an (optional) compile time warningArjan van de Ven1-0/+3
A previous patch added the buffer size check to copy_from_user(). One of the things learned from analyzing the result of the previous patch is that in general, gcc is really good at proving that the code contains sufficient security checks to not need to do a runtime check. But that for those cases where gcc could not prove this, there was a relatively high percentage of real security issues. This patch turns the case of "gcc cannot prove" into a compile time warning, as long as a sufficiently new gcc is in use that supports this. The objective is that these warnings will trigger developers checking new cases out before a security hole enters a linux kernel release. Signed-off-by: Arjan van de Ven <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: James Morris <[email protected]> Cc: Jan Beulich <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2009-09-26x86: Use __builtin_object_size() to validate the buffer size for ↵Arjan van de Ven1-0/+2
copy_from_user() gcc (4.x) supports the __builtin_object_size() builtin, which reports the size of an object that a pointer point to, when known at compile time. If the buffer size is not known at compile time, a constant -1 is returned. This patch uses this feature to add a sanity check to copy_from_user(); if the target buffer is known to be smaller than the copy size, the copy is aborted and a WARNing is emitted in memory debug mode. These extra checks compile away when the object size is not known, or if both the buffer size and the copy length are constants. Signed-off-by: Arjan van de Ven <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2009-03-26compiler-gcc4: conditionalize #error on __KERNEL__H. Peter Anvin1-2/+4
Impact: Fix for exported headers We only want to error out on specific gcc versions if we are actually building the kernel, so conditionalize the #if...#error on __KERNEL__. Based on a patchset by Arnd Bergmann <[email protected]>. Cc: Arnd Bergmann <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2009-01-02Disallow gcc versions 4.1.{0,1}Linus Torvalds1-0/+5
These compiler versions are known to miscompile __weak functions and thus generate kernels that don't necessarily work correctly. If a weak function is int he same compilation unit as a caller, gcc may end up inlining it, and thus binding the weak function too early. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781 for details. Cc: Adrian Bunk <[email protected]> Cc: Helge Deller <[email protected]> Cc: Rusty Russell <[email protected]> Cc: Ingo Molnar <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2009-01-02Sanitize gcc version header includesLinus Torvalds1-4/+1
- include the gcc version-dependent header files from the generic gcc header file, rather than the other way around (iow: don't make the non-gcc header file have to know about gcc versions) - don't include compiler-gcc4.h for gcc 5 (for whenever it gets released). That's just confusing and made us do odd things in the gcc4 header file (testing that we really had version 4!) - generate the name from the __GNUC__ version directly, rather than having a mess of #if conditionals. Signed-off-by: Linus Torvalds <[email protected]>
2008-02-09x86, core: remove CONFIG_FORCED_INLININGHarvey Harrison1-9/+0
Other than the defconfigs, remove the entry in compiler-gcc4.h, Kconfig.debug and feature-removal-schedule.txt. Signed-off-by: Harvey Harrison <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2008-01-28remove __attribute_used__Adrian Bunk1-1/+0
Remove the deprecated __attribute_used__. [Introduce __section in a few places to silence checkpatch /sam] Signed-off-by: Adrian Bunk <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]>
2007-10-17Force erroneous inclusions of compiler-*.h files to be errorsRobert P. J. Day1-1/+3
Replace worthless comments with actual preprocessor errors when including the wrong versions of the compiler.h files. [[email protected]: make it work] Signed-off-by: Robert P. J. Day <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2007-07-21x86: Support __attribute__((__cold__)) in gcc 4.3Andi Kleen1-0/+18
gcc 4.3 supports a new __attribute__((__cold__)) to mark functions cold. Any path directly leading to a call of this function will be unlikely. And gcc will try to generate smaller code for the function itself. Please use with care. The code generation advantage isn't large and in most cases it is not worth uglifying code with this. This patch marks some common error functions like panic(), printk() as cold. This will longer term make many unlikely()s unnecessary, although we can keep them for now for older compilers. BUG is not marked cold because there is currently no way to tell gcc to mark a inline function told. Also all __init and __exit functions are marked cold. With a non -Os build this will tell the compiler to generate slightly smaller code for them. I think it currently only uses less alignments for labels, but that might change in the future. One disadvantage over *likely() is that they cannot be easily instrumented to verify them. Another drawback is that only the latest gcc 4.3 snapshots support this. Unfortunately we cannot detect this using the preprocessor. This means older snapshots will fail now. I don't think that's a problem because they are unreleased compilers that nobody should be using. gcc also has a __hot__ attribute, but I don't see any sense in using this in the kernel right now. But someday I hope gcc will be able to use more aggressive optimizing for hot functions even in -Os, if that happens it should be added. Includes compile fix from Thomas Gleixner. Cc: Jan Hubicka <[email protected]> Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2007-05-09compiler: introduce __used and __maybe_unusedDavid Rientjes1-1/+2
__used is defined to be __attribute__((unused)) for all pre-3.3 gcc compilers to suppress warnings for unused functions because perhaps they are referenced only in inline assembly. It is defined to be __attribute__((used)) for gcc 3.3 and later so that the code is still emitted for such functions. __maybe_unused is defined to be __attribute__((unused)) for both function and variable use if it could possibly be unreferenced due to the evaluation of preprocessor macros. Function prototypes shall be marked with __maybe_unused if the actual definition of the function is dependant on preprocessor macros. No update to compiler-intel.h is necessary because ICC supports both __attribute__((used)) and __attribute__((unused)) as specified by the gcc manual. __attribute_used__ is deprecated and will be removed once all current code is converted to using __used. Cc: Rusty Russell <[email protected]> Cc: Adrian Bunk <[email protected]> Signed-off-by: David Rientjes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2007-05-07Add unitialized_var() macro for suppressing gcc warningsBorislav Petkov1-0/+6
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 <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-01-14[PATCH] When CONFIG_CC_OPTIMIZE_FOR_SIZE, allow gcc4 to control inliningIngo Molnar1-0/+9
If optimizing for size (CONFIG_CC_OPTIMIZE_FOR_SIZE), allow gcc4 compilers to decide what to inline and what not - instead of the kernel forcing gcc to inline all the time. This requires several places that require to be inlined to be marked as such, previous patches in this series do that. Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Arjan van de Ven <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-01-14[PATCH] Make __always_inline actually force always inliningIngo Molnar1-1/+1
This patch is the first in a series that tries to optimize the kernel in terms of size (and thus cache behavior, both cpu and pagecache). This first patch changes __always_inline to be a forced inline instead of the "regular" inline it was on everything except alpha. This forced inline matches the intention of the define better as a matter of documentation. There is no change in behavior by this patch, since "inline" currently is mapped to a forced inline anyway. Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Arjan van de Ven <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-01-08[PATCH] remove gcc-2 checksAndrew Morton1-7/+0
Remove various things which were checking for gcc-1.x and gcc-2.x compilers. From: Adrian Bunk <[email protected]> Some documentation updates and removes some code paths for gcc < 3.2. Acked-by: Russell King <[email protected]> Signed-off-by: Adrian Bunk <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!