ck_pr: Implicit compiler barrier ck_pr_fence.

I accidentally removed ck_pr_fence implicit compiler
barrier semantics in re-structure of ck_pr_fence.
This does affect the correctness of any data structures
in ck_pr_fence or the correctness of consumers of ck_pr
operations where ck_pr serves as linearization points.
The reason it does not affect any CK data structures is
that explicit compiler barriers (whether they are store/load
operations or atomic ready-modify-write operations) always
serve as linearization points.

However, if consumers are doing tricky things like using
these barriers to serialize aliased locations for correctness,
then it is possible for compiler re-ordering to bite them in
the ass.

include/ck_pr.h

@@ -57,11 +57,13 @@
 	ck_pr_fence_##T(void)			\
 	{					\
 		ck_pr_fence_strict_##T();	\
+		return;				\
 	}
 #define CK_PR_FENCE_NOOP(T)			\
 	CK_CC_INLINE static void		\
 	ck_pr_fence_##T(void)			\
 	{					\
+		ck_pr_barrier();		\
 		return;				\
 	}