[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

From: Robert Dewar
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Mon, 01 Jan 2007 08:53:28 -0500
User-agent: Thunderbird (Windows/20061207)

Richard Kenner wrote:
the seemingly prevalent attitude "but it is undefined; but it is not
C" is the opinion of the majority of middle-end maintainers.

Does anybody DISAGREE with that "attitude"?  It isn't valid C to assume that
signed overflow wraps.  I've heard nobody argue that it is.  The question
is how far we go in supporting existing code that's broken in this way.

Well we all understand that the official language definition of C,
starting with K&R first edition, and continuing into the successive
C standards, says that overflow is undefined or machine dependent.

That's not in doubt

However, I am not willing to agree with the notion that code that
does not follow this rule is "broken". It is that attitude which
can lead to inappropriate decisions, instead we should simply say,
in a less judgmental mode, that the code is not strictly standard.
We should also recognize that many (most? nearly all?) large C
programs are in practice in this non-standard category.

In practice, ANY compiler has to go beyond what the standard says
to produce a usable product. The objective of a C compiler is not
simply to conform to the standard, but rather to be a useful tool
for use by C programmers.

With C (and in fact with any language, even a language perceived
to be fiercely standardized like Ada), it is the case that these
two things are not quite the same. For instance in Ada, the set
of representation clauses that must be accepted according to the
standard is fairly small. Tight packing of 3-bit element arrays
for example is not required. But in practice many Ada programs
require support beyond this minimal subset (and indeed we have
users who depend on 3-bit tight packing). Sure we can lecture
them on standard requirements, but GNAT is more useful to them
if we support this optional feature, even if it results in far
less efficient code for some cases (the standard would allow
such components to use 4-bits resulting in much more efficien

When it comes to erroneous and bounded error cases, a compiler
could be maximally unfriendly. For example, in the GNAT binder
there is an option -p (for pessimistic), that says "choose the
worst possible elaboration order, consistent with the standard
requirements". It is a useful option for checking portability
of your code. It would be 100% standards conforming to make
the -p switch the default and only setting, but it would make
GNAT much less useful, since many large programs end up making
assumptions about elaboration order (basically they set things
up to work with some particular compiler).

Again in the Ada context, there are cases where efficiency and
usability conflict. For example, suppose you use an address
clause to position a variable at a specified address, and this
address is misaligned. That's erroneous (undefined in C-speak).
We are allowed to do anything, e.g. delete the system disk,
and the user cannot officially complain. Unofficially that
user is going to be hopping mad. In practice we find that only
a very small number of our users are maximum efficiency oriented
(some of them are happy to consider moving to Java even if it
costs them a factor of 10 in efficiency as an extreme case).
So in the address clause case, we by default generate checking
code that raises Program_Error if the address is misaligned.
That's inefficient, and unnecessary. It can be turned off, but
by default it's on even at the highest optimization level.

By using the word "broken", you are implicitly criticizing
the code, and contributing to an environment where compiler
writers are a little too ready in my view to write off the
programmers of such "broken" code as incompetent, and not
worth worrying about. That can lead to the wrong balance
of decisions in tricky trade off cases.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]