From 697a751b8a0499becede4cb550b1d4e08cd591c7 Mon Sep 17 00:00:00 2001 From: John Wickerson Date: Tue, 15 Sep 2020 10:00:14 +0000 Subject: Update on Overleaf. --- conclusion.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conclusion.tex b/conclusion.tex index 4521155..7181bf0 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -5,7 +5,7 @@ One can always question how much bugs found by fuzzers really \emph{matter}, giv Further work could be done on supporting more HLS tools, especially ones that claim to prove that their output is correct before terminating. This could give an indication on how effective these proofs are, and how often they are actually able to complete their equivalence proofs during compilation in a feasible timescale. -Conventional compilers have become quite resilient to fuzzing over the last decade, so recent work on fuzzing compilers has had to employ increasingly imaginative techniques to keep finding new bugs~\cite{karine+20}. In comparison, we have found that the HLS tools we tested can be made to exhibit bugs even with relatively basic fuzzing techniques that we employed +Conventional compilers have become quite resilient to fuzzing over the last decade, so recent work on fuzzing compilers has had to employ increasingly imaginative techniques to keep finding new bugs~\cite{karine+20}. In comparison, we have found that the HLS tools we tested can be made to exhibit bugs even with the relatively basic fuzzing techniques that we employed in As HLS is becoming increasingly relied upon, it is important to make sure that HLS tools are also reliable. We hope that this work further motivates the need for rigorous engineering of HLS tools, either by validating that each output the tool produces is correct or by proving the HLS tool itself correct once and for all. -- cgit