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

Re: c/7661: gcc-3.0 optimization bug on debian GNULinux on x86 with very simple program



On Wed, Aug 21, 2002 at 11:28:47PM -0400, Carlos O'Donell wrote:
> On Wed, Aug 21, 2002 at 11:55:27AM +0300, Alexei Khlebnikov wrote:
> > > I think this program should not terminate at all because i will
> > > always be one greater than oldi.
> > > I think gcc3.0 has a problem with no optimization then but since
> > > there is later version that works gcc 3.1.1, upgrade.
> > 
> > With no optimization the program runs correctly by the rules of integers
> > representation in memory. See the explanation below.
> > 
> 
> Changed my mind. After a posting from Linus on dri-devel and a discussion
> about integer overflow (undefined) in C the following came out:
> 
> ---
> unsigned int i = 0;
> unsigned int oldi = 0;
> while ((int) ++i > (int) oldi) oldi = i;
> return oldi;
> ---
> 
> Looks good... incrementing unsigned (defined overflow) and doing an
> unsigned check (both operands).

Huh?  No.  This is not defined as far as I can see.  Casting to int
does not have defined meaning if the value of the unsigned int doesn't
fit in int.

       [#3] Otherwise, the new type is signed and the value  cannot
       be  represented  in it; either the result is implementation-
       defined or an implementation-defined signal is raised.

Excuse me, it's implementation-defined.  That means that GCC must
choose a consistent behaviour; it is allowed to choose one such that
your loop disappears, as I understand it.  (int) [unsigned] may be
assumed to be non-negative and thus oldi+1 > oldi.

> Anyone care to jump in? :)

Don't take my uneducated word for it.  Ask comp.lang.c; they know these
things.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



Reply to: