<div dir="ltr">Ok this is the kind of stuff im looking for. This is great. Many thanks for the insight.<br></div><br><div class="gmail_quote"><div dir="ltr">Em seg, 3 de set de 2018 às 04:08, Emil Axelsson <<a href="mailto:78emil@gmail.com">78emil@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have a look at Michal Palka's Ph.D. thesis:<br>
<br>
<a href="https://research.chalmers.se/publication/195849" rel="noreferrer" target="_blank">https://research.chalmers.se/publication/195849</a><br>
<br>
IIRC, his testing revealed several strictness bugs in GHC when compiling <br>
with optimization.<br>
<br>
/ Emil<br>
<br>
Den 2018-09-03 kl. 03:40, skrev Rodrigo Stevaux:<br>
> Thanks for the clarification.<br>
><br>
> What I am hinting at is, the Csmith project caught many bugs in C <br>
> compilers by using random testing -- feeding random programs and <br>
> testing if the optimizations preserved program behavior.<br>
><br>
> Haskell, having tens of optimizations, could be a potential <br>
> application of the same technique.<br>
><br>
> I have no familiarity with the GHC or with any compilers in general; I <br>
> am just looking for something to study.<br>
><br>
> My questions in its most direct form is, as in your view, could GHC <br>
> optimizations hide bugs that could be potentially be revealed by <br>
> exploring program spaces?<br>
><br>
> Em dom, 2 de set de 2018 às 16:58, Sven Panne <<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a> <br>
> <mailto:<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>>> escreveu:<br>
><br>
>     Am So., 2. Sep. 2018 um 20:05 Uhr schrieb Rodrigo Stevaux<br>
>     <<a href="mailto:roehst@gmail.com" target="_blank">roehst@gmail.com</a> <mailto:<a href="mailto:roehst@gmail.com" target="_blank">roehst@gmail.com</a>>>:<br>
><br>
>         Hi Omer, thanks for the reply. The tests you run are for<br>
>         regression testing, that is, non-functional aspects, is my<br>
>         understanding right? [...]<br>
><br>
><br>
>     Quite the opposite, the usual steps are:<br>
><br>
>        * A bug is reported.<br>
>        * A regression test is added to GHC's test suite, reproducing<br>
>     the bug<br>
>     (<a href="https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding</a>).<br>
>        * The bug is fixed.<br>
><br>
>     This way it is made sure that the bug doesn't come back later. Do<br>
>     this for a few decades, and you have a very comprehensive test<br>
>     suite for functional aspects. :-) The reasoning behind this:<br>
>     Blindly adding tests is wasted effort most of time, because this<br>
>     way you often test things which only very rarely break: Bugs OTOH<br>
>     hint you very concretely at problematic/tricky/complicated parts<br>
>     of your SW.<br>
><br>
>     Catching increases in runtime/memory consumption is a slightly<br>
>     different story, because you have to come up with "typical"<br>
>     scenarios to make useful comparisons. You can have synthetic<br>
>     scenarios for very specific parts of the compiler, too, like<br>
>     pattern matching with tons of constructors, or using gigantic<br>
>     literals, or type checking deeply nested tricky things, etc., but<br>
>     I am not sure if such things are usually called "regression tests".<br>
><br>
>     Cheers,<br>
>        S.<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
<br>
</blockquote></div>