Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2044

Language standards vs. implementation, was Re: A right alternative to IEEE-754's format

Show key headers only | View raw

 [[ 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.

Back to comp.compilers | Previous | Next | Find similar

Thread

Language standards vs. implementation, was Re: A right alternative to IEEE-754's format "Tim Rentsch" <txr@alumni.caltech.edu> - 2018-04-06 01:01 -0700

csiph-web