memorder: Fix wrong variable citation

index 183c525..2da7b98 100644
@@ -704,8 +704,8 @@ as Y0, the store to \co{x1} on line~19 as Y1, and the load from
 Applying the if-then rule step by step, we know that the store to
 \co{x1} on line~19 happens after the load from \co{x1} on line~11 if
 \co{P0()}'s local variable \co{r2} is set to the value zero.
-The if-then rule would then state that the load from \co{x1} on
-line~21 happens after the store to \co{x1} on line~9.
+The if-then rule would then state that the load from \co{x0} on
+line~21 happens after the store to \co{x0} on line~9.
 In other words,
 \co{P1()}'s local variable \co{r2} is guaranteed
 to end up with the value two \emph{only if}

index 2da7b98..8511c3a 100644
@@ -1103,7 +1103,7 @@ exists (1:r2=2 /\ 0:r2=2)
 
 \subsubsection{Load Followed By Store}
 Listing~\ref{lst:memorder:Load-Buffering Litmus Test (No Ordering)}
-(\path{C-LB+o-o+o-o.litmus}),
+(\path{C-LB+o-o+o-o.litmus})
 shows the classic \emph{load-buffering} litmus test.
 Although relatively strongly ordered systems such as x86
 or the IBM Mainframe do not reorder prior loads with subsequent stores,

index 3b01a56..e5ff74e 100644
@@ -1016,7 +1016,7 @@ Grover's algorithm.
 	and $O(n \log_2 n)$ for classic-computing search?
 	Hash tables do $O(n)$ and $O(1)$ respectively!!!
 \QuickQuizAnswer{
-	Fixed-size hash table lookup lookups are $O(n)$, not $O(1)$.
+	Fixed-size hash table lookups are $O(n)$, not $O(1)$.
 	And for a resizing hash table, fairness dictates that the overhead
 	of resizing be properly accounted for.