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

[Joe Buck]

Mark Mitchell <address@hidden> writes:
> > let's disable the assumption about signed overflow not wrapping for
> > VRP, but leave it in place for loop analysis.

On Mon, Jan 01, 2007 at 06:09:41PM -0800, Paul Eggert wrote:
> As far as I know this will work for all the wrapv-assuming code that
> we've found, so it should be an improvement.  Thanks to all for
> helping to think it through.

I agree with Mark's proposal as well.

> > I don't even necessarily think we need to change our user documentation.
> 
> Here I'd like to demur, since I think it's useful to document
> something that users can rely on.

I would want to be cautious here, since anything that is documented
could be seen to be a promise that would hold indefinitely.  We want
to keep legacy code building, but we don't want to encourage people
to write more bad code.

> I'm not asking that we document every possible wrapv-assuming code
> that happens to work.  I'm only asking for enough so that users can
> easily write code that tests for signed integer overflow,
> compute sums, products, etc. that would apply if -fwrapv were in
> effect.

inline int
fwrapv_sum(int a, int b) 
{
  return (int)((unsigned)a + (unsigned)b);
}

On any machine with two's complement signed integers, the above gives
you the -fwrapv sum, even if the user turned on -ftrapv.  Same deal
for products.

I think that we should follow the IETF dictum: be liberal in what you
accept (hence gcc is going to have to make the sloppy code work), but
by conservative in what you send (so we should be teaching users how
to write correct code as well as do so ourselves).  I think that gcc
should be patched to fix the violations that have been pointed out.
Patches that assume two's complement integer representation are fine
because all gcc hosts meet that criterion (and I'd be surprised if
a one's complement or sign-magnitude port would work).