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

[Robert Dewar]

Andrew Pinski wrote:

> Look at Fortran argument aliasing, we get almost no bugs about that
> undefinedness.  We have an option to change the way argument aliasing
> works, in the same way we have an option for signed overflow.  I don't
> see why overflow will be any different from argument aliasing.

Well you should see :-)

The point is that in practice many C compilers have implemented wrapping
in the past, and large bodies of C code and the C knowledge base have
developed assuming (correctly in practice) that wrapping could be relied
on. I don't think you can begin to make the same statement for Fortran
argument aliasing (and I speak as someone who developed hundreds of
thousands of lines of Fortran in the early days -- late 60's and early
70's).
> Maybe the problem is that C (and C++) developers don't know the language
> they writing in and expect anything to work they wrote. 

That's not right, and I worry that this attitud stands in the way of
getting the right compromise approach. In fact a lot of competent C
programmers know the language pretty well, but they know the language
that is used and works (quite portably even) in practice, not the
language of the standard (which in this case, if you take undefined
at its worse literally) is a difficult language to write in, when
it comes to checking for overflow, as has been clear from the discussion 
in this thread.

> I think this is
> a problem with the teaching of C (and C++) today and it is hard for us
> to fix that issue.  We can try educate people by adding we treat signed
> overflow as undefined in the documentation in more obvious place but
> this is not going to help in general as developers don't read the docs.

Education won't help deal with large bodies of legacy C that are written
with wrapping assumed (including as we have seen, gcc itself, and other
components of the gnu system). Over time such code can be "fixed", but
it is more likely that people will just resort to fwrapv in practice,
which seems non-optimal to me (I am pretty sure that a moderated
intermediate position between overflow-always-undefined and
overflow-always-wraps can be devised which will in practice
work out fine on the efficiency and portability sides).

In terms of reading the documents, warning messages (and error messages
where possible) are probably more help in teaching the fine details of
the language, and I think everyone agrees that where possible, it would
be a good thing if gcc could warn that it was taking advantage of
"knowing" that signed overflow cannot occur (i.e. should not occur) in
a given situation.
> The problem with the current signed overflow undefined optimizations is
> that conflict in some are wrapping, others are saturation (most of the
> VRP and a-'0'>9) and then more are extending (a*10/5).

Yes, and you can't paint them all with a broadbrush. If you look at the
last one for instance (a*10/5) it's a perfectly reasonable optimization
to optimize this to a*2, and indeed Ada introduces a special rule for
intermediate results which allow them to be "correct" instead of
overflowing precisely to allow this optimization (and to allow the more
general use of double precision intermediate result for computing 
a*b/c). Interestingly, this special Ada rule does introduce some
degree of non-portability, but there is often a trade-off between
portability and efficiency.
> Thanks,
> Andrew Pinski