Lines Matching refs:compiler
40 compiler from deducing the resulting pointer value. Please see
42 for an example where the compiler can in fact deduce the exact
52 The compiler simply knows too much about integral values to
70 "(x-(uintptr_t)x)" for char* pointers. The compiler is within its
109 explained, if the two pointers are equal, the compiler could
117 Because the compiler now knows that the value of "p" is exactly
132 compiler knows that the pointer is NULL, you had better
134 non-equal, the compiler is none the wiser. Therefore,
139 Since there are no subsequent dereferences, the compiler
197 - The pointers are not equal *and* the compiler does
200 will normally prevent the compiler from knowing too much.
202 However, please note that if the compiler knows that the
205 compiler needs to deduce the value of the pointer.
207 - Disable any value-speculation optimizations that your compiler
215 ordered systems (such as ARM or Power). Choose your compiler
264 /* The compiler decides that q->c is same as p->c. */
277 to some reordering from the compiler and CPUs is beside the point.
326 /* The compiler decides that q->c is same as p->c. */
345 other pointer, the compiler normally has no clue what the value of the
346 first pointer might be. This lack of knowledge prevents the compiler
349 should prevent the compiler from guessing the value.
351 But without rcu_dereference(), the compiler knows more than you might
384 Because the compiler can see all stores to "gp", it knows that the only
386 on the other. The comparison in reader() therefore tells the compiler
388 compiler to make the return values independent of the load from "gp",
461 pointers, which can result in "interesting" bugs due to compiler
469 If register pressure is high, the compiler might optimize "p" out