Update on Overleaf.

1 files changed, 2 insertions, 2 deletions

diff --git a/intro.tex b/intro.tex
index 09befdc..7523885 100644
--- a/intro.tex
+++ b/intro.tex
@@ -44,7 +44,7 @@ Fuzzing has been used extensively to test conventional compilers; for example, Y
 \paragraph{An example of a compiler bug found by fuzzing}
 Figure~\ref{fig:vivado_bug1} shows a program that produces the wrong result during RTL simulation in Xilinx Vivado HLS. The bug was initially revealed by a large, randomly generated program, which we reduced to the minimal example shown in the figure.
 The program repeatedly shifts a large integer value \code{b} right by the values stored in array \code{a}.
-Vivado HLS returns \code{0x006535FF}, but the result returned by GCC (and subsequently manually confirmed to be the correct one) is \code{0x046535FF}.
+Vivado HLS returns \code{0x006535FF}, but the result returned by GCC (and subsequently confirmed manually to be the correct one) is \code{0x046535FF}.
 
 The circumstances in which we found this bug illustrate some of the challenges in testing HLS tools.
 For instance, without the for-loop, the bug goes away. 
@@ -53,7 +53,7 @@ And -- particularly curiously -- even though the for-loop only has two iteration
 Even the seemingly random value of \code{b} could not be changed without masking the bug. 
 It seems unlikely that a manually generated test program would bring together all of the components necessary for exposing this bug. 
 In contrast, producing counter-intuitive, complex but valid C programs is the cornerstone of fuzzing tools. 
-For this reason, we found it natural to adopt fuzzing for our HLS testing campaign. 
+For this reason, we find it natural to adopt fuzzing for our HLS testing campaign. 
 % \NR{Yann, please double check my claims about the bug. I hope I accurately described what we discussed. }\YH{Yes I agree with all that, I think that is a good description of it}
 
 \paragraph{Our contribution}