Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| From: | "Tim Rentsch" <txr@alumni.caltech.edu> |
| Newsgroups: | comp.compilers |
| Date: | 6 Apr 2018 01:01:36 -0700 |
| Organization: | A noiseless patient Spider |
| References: | <0d4dc7f8-1819-43e5-8082-6ff7aee5f41b@googlegroups.com> <p9l0cs$p2r$1@gioia.aioe.org> <p9l9bs$am7$1@dont-email.me> <p9ldok$1h9j$1@gioia.aioe.org> <p9li4d$4mn$1@dont-email.me> <p9lvbt$fn0$1@gioia.aioe.org> <2018Mar31.160556@mips.complang.tuwien.ac.at> <p9o96c$1r72$1@gioia.aioe.org> <p9ohgc$vdl$1@dont-email.me> <2018Mar31.195714@mips.complang.tuwien.ac.at> <kfnzi2mkjos.fsf@x-alumni2.alumni.caltech.edu> <p9r2lm$278$1@gioia.aioe.org> |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="52463"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | standards |
| Posted-Date: | 10 Apr 2018 11:08:27 EDT |
[[ this string is copied from comp.arch because your moderation found it interesting ]]
Walter Banks <walter@bytecraft.com> writes:
> As someone who has done a significant amount of compiler development
> there really never enough testing. Once past sanity tests and
> detailed test suites a lot can be gained just by running regression
> tests even if the tests are not executed. Detailed metrics alone
> can be a very revealing indication of significant compiler problems.
>
> This can be especially true while developing optimization a
> surprising number of new optimizations do not have the intended
> effect on old functioning programs.
I think what I meant didn't come across the way I meant it. I
agree with what (I think) you are saying: it's hard to test
compilers effectively, and it is much harder to test heavily
optimizing compilers effectively. In fact this raises an
interesting question, namely, what is a good methodology for
testing compilers in the presence of heavy optimization and
programs that may be "broken" in the sense of having undefined
behavior. That strikes me as a topic worth pursuing (along
with all the other topics on that list, which wasn't short to
begin with).
However all that is orthogonal to what I was trying to say in my
previous comments. My comments are not about verifying how a
compiler behaves but about validating the requirements for how
the compiler should behave. More specifically, in what cases do
we /want/ a compiler to take advantage, or be allowed to take
advantage, of the freedom that "undefined behavior" provides? I
am convinced that in some cases compilers take greater advantage
than is helpful, in the sense of total cost of ownership. Let me
emphasize here: not greater advantage than the Standard allows,
but greater advantage than is helpful when considering the whole
picture. I don't know what is the solution to this problem, but
I have no doubt that there is a problem, and one that needs to
be addressed at a high level rather than a patchwork quilt of
local fixes.
Did that make things any clearer? I hope it did.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.