From: Paul Winalski <paul.winalski@gmail.com>
To: Win Treese <treese@acm.org>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] DEC Compilers (was: Re: SDB debugger
Date: Tue, 5 May 2020 13:36:40 -0400 [thread overview]
Message-ID: <CABH=_VRSyg_FXokkhXa0SPwg2o8wVTy2XtOm9+RRJwVm8ft=gw@mail.gmail.com> (raw)
In-Reply-To: <8D548BBE-AB7A-457E-87F8-F3718A9AC4B7@acm.org>
On 5/4/20, Win Treese <treese@acm.org> wrote:
>
> Andy Payne, a recent hire at the lab, had been an intern in DEC’s
> semiconductor group, where he had worked on randomized testing for hardware
> verification. With all the compilers available, he decided to hack up a
> program to generate random small C programs with computable expected
> outputs. His program then compiled the random code with each compiler and
> tested the result. After finding a number of bugs this way, he got tired of
> submitting the bug reports, and changed his program to write and submit the
> bug reports automatically.
>
> This caused a little bit of consternation with some of the compiler teams at
> first.
I remember that very well. IIRC it was called fuzz testing, and
indeed it was controversial, for the reasons Bill McKeeman discusses
in his paper. [1] On the one hand, compiler developers said, "nobody
would ever write something like that--we can't waste our time on these
issues when there are real bugs waiting to be fixed." On the other
hand, some of the bugs that fuzz testing turned up provoked reactions
such as, "OMG! THAT caused the compiler to crash?" I think the
turning point was when fixing one of the fuzz testing bugs also fixed
an obscure and hard-to-debug customer problem. Intel's C and Fortran
compiler team has also used random testing technology.
> [1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf
-Paul W.
next prev parent reply other threads:[~2020-05-05 17:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-01 20:48 [TUHS] " Paul Ruizendaal
2020-05-01 21:57 ` Clem Cole
2020-05-02 9:10 ` Paul Ruizendaal
2020-05-02 16:04 ` Clem Cole
2020-05-01 23:05 ` Jeremy C. Reed
2020-05-02 0:49 ` Noel Hunt
2020-05-02 1:22 ` Rob Pike
2020-05-02 3:49 ` Noel Hunt
2020-05-02 20:16 ` Paul Ruizendaal
2020-05-03 6:58 ` arnold
2020-05-03 16:13 ` Clem Cole
2020-05-03 16:53 ` Henry Bent
2020-05-03 17:06 ` Henry Bent
2020-05-03 17:13 ` Henry Bent
2020-05-03 20:26 ` Clem Cole
2020-05-05 0:22 ` [TUHS] DEC Compilers (was: " Win Treese
2020-05-05 17:36 ` Paul Winalski [this message]
2020-05-05 18:53 ` Dr Iain Maoileoin
2020-05-05 21:59 ` Dan Cross
2020-05-05 21:49 ` Henry Bent
2020-05-03 17:35 ` [TUHS] " Paul Winalski
2020-05-03 21:27 ` Paul Ruizendaal
2020-05-12 4:15 ` Dave Horsfall
2020-05-06 2:52 [TUHS] DEC Compilers (was: " Doug McIlroy
2020-05-06 15:53 Doug McIlroy
2020-05-06 20:21 ` Tim Rylance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABH=_VRSyg_FXokkhXa0SPwg2o8wVTy2XtOm9+RRJwVm8ft=gw@mail.gmail.com' \
--to=paul.winalski@gmail.com \
--cc=treese@acm.org \
--cc=tuhs@minnie.tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).