Lines Matching refs:compiler

23 	compiler from deducing the resulting pointer value.  Please see
25 	for an example where the compiler can in fact deduce the exact
28 o	Do not use single-element RCU-protected arrays.  The compiler
30 	such an array must necessarily evaluate to zero.  The compiler
34 	on rcu_dereference(), then both the compiler and the CPU
43 	The compiler is within its rights to substitute zero for all of
55 	If the compiler is able to deduce the value of such operands,
62 	be dangerous.  At this point, the compiler knows that the
65 	allow the compiler to deduce the exact value, which again can
114 	explained, if the two pointers are equal, the compiler could
122 	Because the compiler now knows that the value of "p" is exactly
137 		compiler knows that the pointer is NULL, you had better
139 		non-equal, the compiler is none the wiser.  Therefore,
144 		Since there are no subsequent dereferences, the compiler
191 	o	The pointers are not equal -and- the compiler does
194 		will normally prevent the compiler from knowing too much.
196 o	Disable any value-speculation optimizations that your compiler
204 	ordered systems (such as ARM or Power).  Choose your compiler
251 			/* The compiler decides that q->c is same as p->c. */
261 to some reordering from the compiler and CPUs is beside the point.
309 			/* The compiler decides that q->c is same as p->c. */
322 other pointer, the compiler normally has no clue what the value of the
323 first pointer might be.  This lack of knowledge prevents the compiler
326 should prevent the compiler from guessing the value.
328 But without rcu_dereference(), the compiler knows more than you might
361 Because the compiler can see all stores to "gp", it knows that the only
363 on the other.  The comparison in reader() therefore tells the compiler
365 compiler to make the return values independent of the load from "gp",