[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: Richard Sandiford
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Thu, 04 Jan 2007 12:48:49 +0000
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

"Richard Guenther" <address@hidden> writes:
> On 1/4/07, Richard Sandiford <address@hidden> wrote:
>> Paul Eggert <address@hidden> writes:
>> > Mark Mitchell <address@hidden> writes:
>> >> it sounds like that would eliminate most of the problem.  Certainly,
>> >> making -INT_MIN evaluate to INT_MIN, when expressed like that, is an
>> >> easy thing to do; that's just a guarantee about constant folding.
>> >
>> > Well, no, just to clarify: the GCC code in question actually computed
>> > "- x", and relied on the fact that the result was INT_MIN if x (an
>> > unknown integer) happened to be INT_MIN.  Also, now that I'm thinking
>> > about it, some the Unix v7 atoi() implementation relied on "x + 8"
>> > evaluating to INT_MIN when x happened to be (INT_MAX - 7).  These are
>> > the usual kind of assumptions in this area.
>> I don't know if you're implicitly only looking for certain types of
>> signed overflow, or if this has been mentioned elsewhere (I admit I had
>> to skim-read some of the thread) but the assumption that signed overflow
>> is defined is _very_ pervasive in gcc at the rtl level.  The operand to
>> a CONST_INT is a signed HOST_WIDE_INT, and its accessor macro -- INTVAL
>> -- returns a value of that type.  Most arithmetic related to CONST_INTs
>> is therefore done on signed HOST_WIDE_INTs.  This means that many parts
>> of gcc would produce wrong code if signed arithmetic saturated, for
>> example.  (FWIW, this is why I suggested adding a UINTVAL, which Stuart
>> has since done -- thanks.  However, most of gcc still uses INTVAL.)
> I thought all ints are unsigned in the RTL world as there is I believe no way
> to express "signedness" of a mode.  This would have to change of course
> if we ever support non two's-complement arithmetic.

I'm not sure what you mean.  Yes, "all ints are unsigned in the RTL world"
in the sense that we must use two's complement arithmetic for them --
we have no way of distinguishing what was originally signed from
what was originally unsigned.  But my point was that gcc _stores_ the
integers as _signed_ HOST_WIDE_INTs, and operates on them as such,
even though these signed HOST_WIDE_INTs may actually represent unsigned
integers.  Thus a lot of the arithmetic that gcc does at the rtl level
would be wrong for certain inputs if the _compiler used to build gcc_
assumed that signed overflow didn't wrap.

In other words, it sounds like you took my message to mean that gcc's
rtl code treated signed overflow _in the input files_ as undefined.
I didn't mean that.  I meant that gcc's own code relies on signed
overflow being defined.  I think it was instances of the latter
that Paul was trying to find.


reply via email to

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