Update on Overleaf.fccm21

2 files changed, 3 insertions, 2 deletions

diff --git a/eval.tex b/eval.tex
index 46b58a0..e17d955 100644
--- a/eval.tex
+++ b/eval.tex
@@ -53,7 +53,7 @@ We see that 918 (13.7\%), 167 (2.5\%), 83 (1.2\%) and 26 (0.4\%) test-cases fail
 Despite i++ having the lowest failure rate, it has the highest time-out rate (540 test-cases), because of its remarkably long compilation time.
 % We remark that although the Intel HLS Compiler had the smallest number of confirmed test-case failures, it had the most time-outs (which could be masking additional failures)  
 Note that the absolute numbers here do not necessarily correspond to the number of bugs in the tools, because a single bug in a language feature that appears frequently in our test suite could cause many programs to crash or fail.
-Hence, we reduce many of the failing test-cases in an effort to identify unique bugs; these are summarised in the table below.
+Hence, we reduce many of the failing test-cases in an effort to identify unique bugs; these are summarised in the table below.\footnote{Link to detailed bug reports available from PC Chair.}
 
 \begin{table}[h]
 \centering
diff --git a/intro.tex b/intro.tex
index c269b8e..29f09d1 100644
--- a/intro.tex
+++ b/intro.tex
@@ -30,7 +30,8 @@ In this paper, we bring fuzzing to the HLS context.
 
 \begin{example}[A miscompilation bug in Vivado HLS]
 \label{ex:vivado_miscomp}
-Figure~\ref{fig:vivado_bug1} shows a program that produces the wrong result during RTL simulation in Xilinx Vivado HLS v2018.3, v2019.1 and v2019.2.\footnote{This program, like all the others in this paper, includes a \code{main} function, which means that it compiles straightforwardly with GCC. To compile it with an HLS tool, we rename \code{main} to \code{result}, synthesise that function, and then add a new \code{main} function as a testbench that calls \code{result}.} The bug was initially revealed by a randomly generated program of around 113 lines, which we were able to reduce to the minimal example shown in the figure.  This bug was also reported to Xilinx and confirmed to be a bug.\footnote{Link to Xilinx bug report redacted for review.}% \footnote{https://bit.ly/3mzfzgA}
+Figure~\ref{fig:vivado_bug1} shows a program that produces the wrong result during RTL simulation in Xilinx Vivado HLS v2018.3, v2019.1 and v2019.2.\footnote{This program, like all the others in this paper, includes a \code{main} function, which means that it compiles straightforwardly with GCC. To compile it with an HLS tool, we rename \code{main} to \code{result}, synthesise that function, and then add a new \code{main} function as a testbench that calls \code{result}.} The bug was initially revealed by a randomly generated program of around 113 lines, which we were able to reduce to the minimal example shown in the figure.  We reported this issue to Xilinx, who confirmed it to be a bug.\footnote{Link to Xilinx bug report redacted for review.}
+% \footnote{https://bit.ly/3mzfzgA}
 The program repeatedly shifts a large integer value \code{x} right by the values stored in array \code{arr}.
 Vivado HLS returns \code{0x006535FF}, but the result returned by GCC (and subsequently confirmed manually to be the correct one) is \code{0x046535FF}.
 \end{example}