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

Groups > comp.compilers > #2043

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 ]]

On 2018-04-01 11:52 AM, Tim Rentsch wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>> A responsible software maintainer does not change behaviour that
>> users make use of.  See, e.g.,
>> <https://felipec.wordpress.com/2013/10/07/the-linux-way/>.
>
> Interesting article.  Thank you for posting it.
>
>> Unfortunately, there's an epidemic of irresponsibility among C
>> compiler maintainers.
>
> I can't completely agree with this reaction.  In some ways, sure, but
> for choices that are allowed because of undefined behavior the
> question is not so black-and-white.  Some of the responsibility
> belongs to the ISO C standard (and the people who produce it).
> Unfortunately it's a difficult problem;  I know there is interest in
> the ISO C group to find a middle ground, somewhere between
> unspecified behavior and undefined behavior, but it isn't easy to
> find that.  For example, consider this reasonable-sounding rule: no
> library interface should ever result in undefined behavior, not
> counting things like bad pointer inputs (and null pointers should
> never be in the set of bad inputs).  But what about printf()?  In
> printf() we have an interface with large parts of the input domain
> that give undefined behavior.  POSIX takes advantage of this to
> define the behavior of positional format specifications, which are
> quite useful in some contexts.  But, and here is the important part,
> formats other than those allowed in the POSIX spec /are still
> undefined behavior/.  Moreover that freedom is important, to allow
> further extensions to be added at some later date.
>
> I should add that I am mostly on your side.  I think what compiler
> writers are doing with so-called "aggressive optimization" belongs
> more to the problem set than the solution set.  But solving the
> problem has to include getting changes made to the ISO C standard, so
> that compiler writers have no choice if they want their stuff to be
> conforming.  I know doing that is not an easy task; ultimately though
> it seems unavoidable if we are to get things to improve.
>

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.

w..

Back to comp.compilers | Previous | Next — Next in thread | Find similar

Thread

Language standards vs. implementation, was Re: A right alternative to IEEE-754's format "Walter Banks" <walter@bytecraft.com> - 2018-04-10 11:07 -0400
  Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format Gene Wirchenko <genew@telus.net> - 2018-04-10 11:07 -0700
    Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format Martin Ward <martin@gkc.org.uk> - 2018-04-12 09:52 +0100
      Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2018-05-05 20:28 +0200

csiph-web