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
32 	The compiler is within its rights to substitute zero for all of
44 	If the compiler is able to deduce the value of such operands,
51 	be dangerous.  At this point, the compiler knows that the
54 	allow the compiler to deduce the exact value, which again can
105 	explained, if the two pointers are equal, the compiler could
113 	Because the compiler now knows that the value of "p" is exactly
128 		compiler knows that the pointer is NULL, you had better
130 		non-equal, the compiler is none the wiser.  Therefore,
135 		Since there are no subsequent dereferences, the compiler
182 	o	The pointers are not equal -and- the compiler does
185 		will normally prevent the compiler from knowing too much.
187 		However, please note that if the compiler knows that the
190 		compiler needs to deduce the value of the pointer.
192 o	Disable any value-speculation optimizations that your compiler
200 	ordered systems (such as ARM or Power).  Choose your compiler
247 			/* The compiler decides that q->c is same as p->c. */
257 to some reordering from the compiler and CPUs is beside the point.
305 			/* The compiler decides that q->c is same as p->c. */
318 other pointer, the compiler normally has no clue what the value of the
319 first pointer might be.  This lack of knowledge prevents the compiler
322 should prevent the compiler from guessing the value.
324 But without rcu_dereference(), the compiler knows more than you might
357 Because the compiler can see all stores to "gp", it knows that the only
359 on the other.  The comparison in reader() therefore tells the compiler
361 compiler to make the return values independent of the load from "gp",