Re: [testsuite] loop failure

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jun 20, 2000 at 10:41:05PM -0700, Geoff Keating wrote:
> 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.

Thanks, I've fixed ash then.

> 
> 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().

Do you mean that

main()
{
  char c, d;
  int nbits;
  if (sizeof(int) < 4)
    exit(0);
  c = -1;
  for (nbits = 1 ; nbits < 10; nbits++) {
    d = (1 << nbits) - 1;
    if (d == c)
      break;
  }
  if (nbits != 10)
    abort();
  exit(0);
}

should have defined behaviour and never call abort()?
It aborts on sparc with -O0, -O1, works with -O2 and above.

Similarly,

main()
{
  char c;
  unsigned char d;
  int nbits;
  if (sizeof(int) < 4)
    exit(0);
  c = -1;
  for (nbits = 1 ; nbits < 10; nbits++) {
    d = (1 << nbits) - 1;
    if (d == c)
      break;
  }
  if (nbits == 10)
    abort();
  exit(0);
}

aborts on sparc with -O0, -O1 and works with -O2 and above.
(note unsigned char and == instead of !=).
Unless all of this is undefined behaviour, there is some bug in gcc related
to it.

	Jakub