This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [testsuite] loop failure


Jakub Jelinek <jakub@redhat.com> writes:

> On Tue, Jun 20, 2000 at 05:31:55PM -0700, Geoff Keating wrote:
> > Bernd Schmidt <bernds@masala.cygnus.co.uk> writes:
> > 
> > > On Thu, 15 Jun 2000, Jakub Jelinek wrote:
> > 
> > > > +  int nbits;
> > > > +  c = -1;
> > > > +  for (nbits = 1 ; nbits < 100; nbits++) {
> > > > +    d = (1 << nbits) - 1;
> > > > +    if (d == c)
> > > > +      break;
> > > > +  }
> > > 
> > > That's not valid C, is it?  The shift count will get >= the width
> > > of the type eventually.
> > 
> > You are right.  This is undefined behavior.
> > 
> > Jakub, can you fix or revert the testcase?
> 
> As I asked Bernd privately already, is it valid with s/100/32/ or even
> s/100/10/? The test would have to be conditionalized on 8bit char platforms
> then.

If you just change the value '100' to '32', it's still undefined behaviour
because 1 << 31 doesn't fit in a 32-bit signed int.

If you change the value '100' to '10', then the test has defined
behaviour.  Unfortunately, unless you also change the initial value of
'c', the defined behaviour is to always call abort().

There's no way to get a value of -1 by starting with a nonzero value,
shifting it left any number of bits, and subtracting one, without
triggering an overflow first.

In general, any computation in C which is done in signed integers and
overflows triggers undefined behavior.
-- 
- Geoffrey Keating <geoffk@cygnus.com>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]