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

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

Return to the comp.compilers page.
Search the comp.compilers archives again.