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

[Paul Eggert]

Andrew Pinski <address@hidden> writes:

> You are just giving up on the undefined issue

No, I'm taking a multiple-phase approach.  I'm not giving up at all.
Please don't confuse the first phase with the whole thing.

The first phase is to keep existing GNU software working with GCC 4.2
and later, using a short-term strategy.  This shouldn't take much
work: just use -fwrapv (or perhaps a better strategy, but -fwrapv
seems to be the best proposal so far).

Later phases will worry about how to analyze the existing software so
that it's easier to port overflow-checking code without the
performance drawbacks of -fwrapv.  The later phases will be harder,
and will take a longer time, and will benefit from careful thought to
minimize the development effort.

> I gave a way how to do this loop in a portable way and I have not
> got comments back from you

If you're talking about the proposal in
<http://gcc.gnu.org/ml/gcc/2006-12/msg00707.html>, then I'm afraid I
didn't really understand it -- it wasn't very coherent, and it doesn't
seem to address all the problems of the original patch.  But even if
your proposal worked and I understood it, it'd be proposing a
nontrivial sort of change to the original software.  Such changes
can't be made lightly in production code.  We're not talking about a
two-minute change here: two hours is more like it, at least.  And this
is just for one small instance of the problem.

> I don't see why we are getting away from the real issue of autoconf
> depending on undefined behavior code that might be miscompiled with
> any compiler, might not be GCC but could any?

I'm having trouble following your wording, but let's say right out
front that Autoconf test programs are deliberately on the edge of what
compilers support.  After all, that's Autoconf's job: to generate
scripts that find out what breaks compilers, and what does not.  So in
that sense, Autoconf-generated scripts depend on undefined behavior
all the time, and I'm not that worried about these little test
programs.  (And in that same sense, the original problem is a red
herring.)

What I'm mostly worried about is the mainline code in ordinary C
applications, such as the example I mentioned in the GCC source, or
the half-dozen similar examples that I suspect are in the mktime
module of glibc, or the dozens or hundreds of similar examples I
expect are scattered around the other programs I help maintain.  Like
it or not, lots of real C code assumes wrapv semantics.  We cannot
merely wish this away.

> What about XYZCC?

We can cross the bridges with the other compilers when we get to them.
The other compilers will have to address the same basic problems, and
presumably will have similar solutions.  If we can handle the vast
majority of compilations in practical use now, that's good enough to
start with.