compiler (reference) in projects: Linux-v6.6

Project(s)

Full Search
Definition
Symbol
File Path
History
Type

Searched refs:compiler (Results 1 – 25 of 171) sorted by relevance

12 3 4 5 6 7

/Linux-v6.6/tools/memory-model/Documentation/
D	control-dependencies.txt	6 help you prevent your compiler from breaking your code. However, 9 your own code, even in the absence of help from your compiler. 41 WRITE_ONCE() are optional. Without the READ_ONCE(), the compiler might 43 the compiler might fuse the store to "b" with other stores. Worse yet, 44 the compiler might convert the store into a load and a check followed 45 by a store, and this compiler-generated load would not be ordered by 48 Furthermore, if the compiler is able to prove that the value of variable 56 In particular, although READ_ONCE() does force the compiler to emit a 57 load, it does not force the compiler to actually use the loaded value. 90 assembly code, after all of the compiler and link-time optimizations [all …]
D	access-marking.txt	34 any sort of constraint on the compiler's choice of optimizations [2]. 36 compiler's use of code-motion and common-subexpression optimizations. 41 data_race(READ_ONCE(a)), which will both restrict compiler optimizations 91 If it is necessary to both restrict compiler optimizations and disable 115 that provides the compiler much less scope for mischievous optimizations. 152 due to compiler-mangled reads, it can also tolerate the occasional 153 compiler-mangled write, at least assuming that the proper value is in 216 of how the compiler has been prevented from optimizing those accesses 237 As noted earlier, the goal is to prevent the compiler from destroying 278 The reader-writer lock prevents the compiler from introducing concurrency [all …]
D	ordering.txt	190 compiler might then reasonably decide to transform "x = 1" and "y = 1" 222 The Linux kernel's compiler barrier is barrier(). This primitive 223 prohibits compiler code-motion optimizations that might move memory 226 used to prevent to compiler from moving code across an infinite loop: 233 Without the barrier(), the compiler would be within its rights to move the 432 However, control dependencies are easily destroyed by compiler 460 primitives required the compiler to emit the corresponding store 468 primitives required the compiler to emit the corresponding load 501 and further do not guarantee "atomic" access. For example, the compiler 508 any number of compiler optimizations, many of which can break your [all …]
D	README	`28 o You would like a detailed understanding of what your compiler can 54 Guide to preventing compiler optimizations from destroying`
D	simple.txt	`58 locking functions must carefully prevent both the CPU and the compiler 224 no ordering, but they do prevent the compiler from carrying out a number 237 Don't let the compiler trip you up 243 surprising amount of analysis, care, and knowledge about the compiler. 244 Yes, some decades ago it was not unfair to consider a C compiler to be 252 understanding of both the C standard and your compiler. Here are some 255 Who's afraid of a big bad optimizing compiler?`
/Linux-v6.6/scripts/coccinelle/misc/
D	uninitialized_var.cocci	`7 /// For any compiler warnings about uninitialized variables, just add 10 /// compiler warnings (e.g. "unused variable"). If the compiler thinks it 11 /// is uninitialized, either simply initialize the variable or make compiler 13 /// obviously redundant, the compiler's dead-store elimination pass will make`
/Linux-v6.6/Documentation/RCU/
D	rcu_dereference.rst	27 compiler from deducing the resulting pointer value. Please see 29 for an example where the compiler can in fact deduce the exact 39 The compiler simply knows too much about integral values to 57 "(x-(uintptr_t)x)" for char* pointers. The compiler is within its 96 explained, if the two pointers are equal, the compiler could 104 Because the compiler now knows that the value of "p" is exactly 119 compiler knows that the pointer is NULL, you had better 121 non-equal, the compiler is none the wiser. Therefore, 126 Since there are no subsequent dereferences, the compiler 184 - The pointers are not equal and the compiler does [all …]
/Linux-v6.6/scripts/
D	Kconfig.include	`27 # Return y if the compiler supports <flag>, n otherwise 39 $(error-if,$(failure,command -v $(CC)),C compiler '$(CC)' not found) 42 # Get the C compiler name, version, and error out if it is not supported. 44 $(error-if,$(success,test -z "$(cc-info)"),Sorry$(comma) this C compiler is not supported.) 61 # $(m32-flag): -m32 if the compiler supports it, or an empty string otherwise. 62 # $(m64-flag): -m64 if the compiler supports it, or an empty string otherwise.`
/Linux-v6.6/include/linux/
D	compiler_types.h	`443 #define __diag_ignore(compiler, version, option, comment) \ argument 444 __diag_ ## compiler(version, ignore, option) 445 #define __diag_warn(compiler, version, option, comment) \ argument 446 __diag_ ## compiler(version, warn, option) 447 #define __diag_error(compiler, version, option, comment) \ argument 448 __diag_ ## compiler(version, error, option)`
/Linux-v6.6/Documentation/arch/ia64/
D	ia64.rst	`21 compiler. And various software packages also compiled with an 22 IA-64 compliant GCC compiler. 35 compliant GCC compiler.`
/Linux-v6.6/arch/nios2/platform/
D	Kconfig.platform	`67 instruction. This will enable the -mhw-mul compiler flag. 73 instruction. Enables the -mhw-mulx compiler flag. 79 instruction. Enables the -mhw-div compiler flag. 87 the -mbmx compiler flag. 95 the -mcdx compiler flag. 100 Enables the -mcustom-fpu-cfg=60-1 compiler flag.`
/Linux-v6.6/Documentation/kbuild/
D	gcc-plugins.rst	`10 compiler [1]_. They are useful for runtime instrumentation and static analysis. 16 Plugin source files have to be compilable by a C++ compiler. 39 compiler features that are neither in GCC nor Clang upstream. Once 45 upstream compiler support (in either GCC or Clang). 106 Run gcc (native or cross-compiler) to ensure plugin headers are detected::`
/Linux-v6.6/Documentation/
D	memory-barriers.txt	139 appears to be maintained. Similarly, the compiler may also arrange the 244 Whether on DEC Alpha or not, the READ_ONCE() also prevents compiler 269 (*) It _must_not_ be assumed that the compiler will do what you want 271 WRITE_ONCE(). Without them, the compiler is within its rights to 319 in a given bitfield are protected by different locks, the compiler's 361 What is required is some way of intervening to instruct the compiler and the 634 Documentation/RCU/rcu_dereference.rst file: The compiler can and does break 678 the compiler's ignorance from breaking your code. 713 are optional! Without the READ_ONCE(), the compiler might combine the 715 the compiler might combine the store to 'b' with other stores to 'b'. [all …]
/Linux-v6.6/Documentation/ABI/testing/
D	configfs-acpi	`49 - ASCII ASL compiler vendor ID 52 - ASL compiler version`
/Linux-v6.6/kernel/bpf/
D	Kconfig	`7 # Used by archs to tell that they support BPF JIT compiler plus which 19 # Used by archs to tell that they want the BPF JIT compiler enabled by 42 bool "Enable BPF Just In Time compiler"`
/Linux-v6.6/Documentation/dev-tools/
D	kmsan.rst	9 values. It is based on compiler instrumentation, and is quite similar to the 90 it, which can be helpful if we do not want the compiler to interfere with some 117 the only compiler that has KMSAN support. The kernel instrumentation pass is 135 instrumentation code inserted by the compiler (unless it is a stack variable 147 that takes one or more values the compiler generates code that calculates the 229 For every memory access the compiler emits a call to a function that returns a 243 The compiler makes sure that for every loaded value its shadow and origin 283 ``-fsanitize-memory-param-retval``, which makes the compiler check function 297 The compiler replaces calls to ``memcpy()``/``memmove()``/``memset()`` with the 309 For each use of a value the compiler emits a shadow check that calls
/Linux-v6.6/Documentation/core-api/
D	unaligned-memory-access.rst	83 Fortunately things are not too complex, as in most cases, the compiler 100 Fortunately, the compiler understands the alignment constraints, so in the 102 Therefore, for standard structure types you can always rely on the compiler 106 Similarly, you can also rely on the compiler to align variables and function 126 For a natural alignment scheme, the compiler would only have to add a single 131 structure type. This GCC-specific attribute tells the compiler never to 137 architectural alignment requirements. However, again, the compiler is aware
/Linux-v6.6/lib/
D	Kconfig.kmsan	`20 uninitialized values in the kernel. It is based on compiler 41 If the compiler supports -fsanitize-memory-param-retval, KMSAN will`
D	Kconfig.kasan	`56 # this variable to decide how the compiler should treat builtins. 59 The compiler is able to prefix memintrinsics with __asan or __hwasan. 142 Makes the compiler insert function calls that check whether the memory 150 Makes the compiler directly insert memory accessibility checks before`
/Linux-v6.6/Documentation/process/
D	volatile-considered-harmful.rst	`40 compiler might think it knows what will be in shared_data, but the 46 necessary. But the compiler would also be prevented from optimizing access 54 by locks, but one also does not want the compiler "optimizing" register 69 hyperthreaded twin processor; it also happens to serve as a compiler`
/Linux-v6.6/include/xen/interface/
D	version.h	`29 char compiler[64]; member`
/Linux-v6.6/Documentation/features/debug/stackprotector/
D	arch-support.txt	`4 # description: arch supports compiler driven stack overflow protection`
/Linux-v6.6/Documentation/arch/x86/x86_64/
D	fsgs.rst	`31 thread and the compiler emits the FS: address prefix for accesses to these 125 FSGSBASE instructions compiler support 139 code and the compiler option -mfsgsbase has to be added. 192 In case the compiler does not support address spaces, inline assembly can`
/Linux-v6.6/tools/testing/selftests/arm64/mte/
D	Makefile	`32 $(warning compiler "$(CC)" does not support the ARMv8.5 MTE extension.)`
/Linux-v6.6/Documentation/networking/
D	filter.rst	51 internal compiler that generates a structure that can eventually be loaded 172 filters use Linux extensions that are not supported by libpcap's compiler, 174 libpcap's compiler, or iv) particular filter codes should be optimized 175 differently than libpcap's internal compiler does; then in such cases 512 JIT compiler 515 The Linux kernel has a built-in BPF JIT compiler for x86_64, SPARC, 517 CONFIG_BPF_JIT. The JIT compiler is transparently invoked for each 547 70 bytes emitted from JIT compiler (pass:3, flen:6) 574 70 bytes emitted from JIT compiler (pass:3, flen:6) 618 toolchain for developing and testing the kernel's JIT compiler. [all …]

12 3 4 5 6 7